From owner-ietf-ldup@mail.imc.org Fri Mar 1 08:34:48 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23650 for ; Fri, 1 Mar 2002 08:34:48 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g21DAtf18900 for ietf-ldup-bks; Fri, 1 Mar 2002 05:10:55 -0800 (PST) Received: from smtp.oncalldba.com (roc-24-169-98-155.rochester.rr.com [24.169.98.155]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g21DAsi18895 for ; Fri, 1 Mar 2002 05:10:54 -0800 (PST) Received: from RMINC_DOM-MTA by smtp.oncalldba.com with Novell_GroupWise; Fri, 01 Mar 2002 08:08:04 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Fri, 01 Mar 2002 08:07:52 -0700 From: "Ed Reed" To: Cc: , Subject: RE: Basic Access Control for LDAP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g21DAti18897 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Thanks for that clarification, Steven - that's different from some directories I know that force ACI subjects to be of one of a few classes known to represent security principals. Ed >>> "Steven Legg" 02/28/02 09:36PM >>> Ed, Ed Reed wrote: > Actually, my question is a bit more basic - > > Does allUsers include entries of any and all object classes, or only > object classes derived from "person", or only "person"s with, say, > a password attribute present, or some other definition? As far as Basic Access Control is concerned, an identified user (i.e. a requestor) is just a distinguished name. The distinguished name doesn't even have to refer to a real entry, so the object class of the user's entry, if such an entry exists, is completely irrelevant. The allUsers case includes not only any identified user, but also completely anonymous requestors for which no associated distinguished name was able to be established at bind time. Regards, Steven > > Ed > > ================= > Ed Reed > Reed-Matthews, Inc. > +1 585 624 2402 > http://www.Reed-Matthews.COM > Note: Area code is 585 > > >>> "Steven Legg" 02/28/02 01:16AM >>> > > Ed, > > Ed Reed wrote: > > One question from reading the drafts (for now) - > > > > What constitutes a "user" for the purpose of ACI UserClasses > > value allUsers? > > In the first instance it is anyone/anything who manages to bind in, > regardless of their authorization identity, but it is qualified by > the AuthenticationLevel and whether a permission is being granted > or denied. > > For a permission being granted: > > 1) If the AuthenticationLevel is "none" then allUsers > includes everyone, > regardless of authorization identity, anonymous included. > > 2) If the AuthenticationLevel is "simple" then allUsers includes all > users who have authenticated with at least a user name and password. > Anonymous users and users who have not been authenticated are > excluded. > > 3) If the AuthenticationLevel is "strong" then allUsers includes all > users who have authenticated with strong credentials, e.g digital > signatures. Anonymous users, unauthenticated users and password > authenticated users are excluded. > > For a permission being denied, allUsers includes everyone, > regardless of authorization identity and authentication level. > > Regards, > Steven > > > From owner-ietf-ldup@mail.imc.org Fri Mar 1 16:12:26 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28224 for ; Fri, 1 Mar 2002 16:12:25 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g21KehT09684 for ietf-ldup-bks; Fri, 1 Mar 2002 12:40:43 -0800 (PST) Received: from smtp.oncalldba.com (roc-24-169-98-155.rochester.rr.com [24.169.98.155]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g21KeeG09678 for ; Fri, 1 Mar 2002 12:40:40 -0800 (PST) Received: from RMINC_DOM-MTA by smtp.oncalldba.com with Novell_GroupWise; Fri, 01 Mar 2002 15:37:49 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Fri, 01 Mar 2002 15:37:36 -0700 From: "Ed Reed" To: Cc: , "Ed Reed" , Subject: draft-ietf-ldup-model-07.txt Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_7B26CAAD.96F799F3" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_7B26CAAD.96F799F3 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Please publish the attached updated internet draft. Abstract: This architectural document outlines a suite of schema and protocol=20 extensions to LDAPv3 that enables the robust, reliable, server-to- server exchange of directory content and changes.=20 Thank you, Ed Reed =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D To the working group: This version of the document includes notes addressed to other document authors and raises issues to the LDUP working group. Changes include: converted document to (yet another) ms word template-based document, sort = of. changed "Updateable Replica" to "Master Replica" dropped some non-objectives (!) of the document 8.5 added Rick Huber's description of major replication states and state = changes (as needed by MRM) document. It is added to the "Update Protocol = Framework" sub section 8.5. 3.2: =20 Cleaned up "document objectives" so that all of them have a similar tone. = Items retained are those bullets that spell out issues this document is = meant to address and what purpose it is to serve for other design = documents. Added another line about how some prevalant concepts and their intent in = current commercial products are outlined as a way to allow the reader to = relate the LDUP protocol design choices, even if the LDUP protocols do not = support these concepts (e-g primary replica, state-based replication, = fractional replica etc.) 3.3: =20 Cleaned up non-objectives to be about architectural issues not addressed 3.4: =20 Added that architecture draft does not dictate either state or log based = approach 3.5: =20 a.. Minor changes in definitions (to remove references to primary = replica)=20 b.. pruned all references to primary replica 4 & 5:=20 Reorganized and cleaned up these two sections: Section 4 used to have a combination of schema element defintions such as = CSN, subentry etc., It also had replica type definitions and theory of = operation w.r.t usage of CSN. a.. Section 4 just defines the replica types b.. Moved the schema elements into the section 5 (information model = section)=20 c.. Pruned any detailed descriptions regarding state based replication = from both sections=20 d.. Made the discussion of how CSN is used neutral w.r.t log-based vs = state based and moved it to a new section # 7 called "Change Representation= and Update Resolution". It now flows well, comes after information model = discussion and is presented like a theory of operation. G6 Action Item:=20 We reviewd it and believe that there is no need to add any additional = caution w.r.t DOS. Because faster purging won't really address DOS = attack. What is generally useful is the knowledge that log based systems = accumulate logs at a larger rate than state based and so purging rate has = to be carefully tuned. G10 Action Item: Added necessary verbiage information model under sections titled "Root DSE = attributes". AM2 Action Item: Added need for audit logging capability under securuity discussion. AM6 Actions item: Did nothing, since it is not a problem in log based system where things = are applied in order of CSN (from within a node). =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ed Reed Reed-Matthews, Inc. +1 585 624 2402 http://www.Reed-Matthews.COM Note: Area code is 585 --=_7B26CAAD.96F799F3 Content-Type: text/plain Content-Disposition: attachment; filename="draft-ietf-ldup-model-07.txt" Ed Reed Reed-Matthews, Inc. Internet Draft Uppili Srinivasan Document: draft-ietf-ldup-model-07.txt Oracle, Inc. Expires: September 2002 March 2002 LDAP Replication Architecture Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This draft, file name draft-ietf-ldup-model-07.txt, is intended to be become a Proposed Standard RFC, to be published by the IETF Working Group LDUP. Distribution of this document is unlimited. Comments should be sent to the LDUP Replication mailing list or to the authors. This Internet-Draft expires September 2002 1 Abstract This architectural document outlines a suite of schema and protocol extensions to LDAPv3 that enables the robust, reliable, server-to- server exchange of directory content and changes. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. The sections below reiterate these definitions and include some additional ones. Page 1 LDAP Replication Architecture Model March 2002 2 Table of Contents Status of this Memo................................................1 1 Abstract.......................................................1 2 Table of Contents..............................................2 3 Introduction...................................................2 4 Replication Environment........................................7 5 Information Model..............................................9 6 Replication of Directory Administrative Policy Information....14 7 Change Representation and Update Resolution...................15 8 LDUP Update Transfer Protocol Framework.......................17 9 LDUP Update Protocols.........................................20 10 LDUP Full Update Transfer Protocol............................20 11 LDUP Incremental Update Transfer Protocol.....................21 12 Purging State Information.....................................26 13 Replication Configuration and Management......................27 14 Security Considerations.......................................29 15 Acknowledgements..............................................29 16 References....................................................30 17 Intellectual Property Notice..................................30 18 Copyright Notice..............................................31 19 Authors' Address..............................................31 20 Appendix A _ LDAP Constraints.................................32 3 Introduction 3.1 Scope This architectural document provides an outline of an LDAP based replication scheme. Further detailed design documents will draw guidance from here. The design proceeds from prior work in the industry, including concepts from the ITU-T Recommendation X.525 (1993, 1997) Directory Information Shadowing Protocol (DISP) [X525], experience with widely deployed distributed directories in network operating systems, electronic mail address books, and other database technologies. The emphasis of the design is on: a) Simplicity of operation. b) Flexibility of configuration. c) Manageability of replica operations among mixed heterogeneous vendor LDAP servers under common administration. d) Security of content and configuration information when LDAP servers from more than one administrative authority are interconnected. Reed, Srinivasan September 2002 Page 2 LDAP Replication Architecture Model March 2002 A range of deployment scenarios is supported, including multi-master and single-master topologies. Replication networks may include transitive and redundant relationships between LDAP servers. The controlling framework used to define the relationships, types, and state of replicas of the directory content is defined. In this way the directory content can itself be used to monitor and control the replication network. The directory schema is extended to define object classes, auxiliary classes, and attributes that describe areas of the namespace which are replicated, LDAP servers which hold replicas of various types for the various partitions (_Replication Contexts_) of the namespace, LDAP Access Points (network addresses) where such LDAP servers may be contacted, which namespace replicas are held on given LDAP servers, and the progress of replication operations. Among other things, this knowledge of where directory content is located could serve as the basis for dynamic generation of LDAP referrals. An update transfer protocol, which actually brings a replica up to date with respect to changes in directory content at another replica, is defined using LDAPv3 protocol extensions. The representation of directory content and changes will be defined by the LDAP Replication Update Transfer Protocol sub-team. Incremental and full update transfer mechanisms are described. Replication protocols are required to include initial population, change updates, and removal of directory content. Security information, including access control policy will be treated as directory content by the replication protocols. Confidentiality and integrity of replication information is required to be provided by lower-level transport/session protocols such as IPSEC and/or TLS. 3.2 Document Objectives The objectives of this document are: a) To present the architecture and theory of operation for LDUP so that it provides a consistent basis for all detailed design documents associated with this LDAP replication service. The Information Model, Update Transfer Protocol, and Update Resolution Procedure documents are among the targeted LDUP design documents. b) To provide an architectural solution for each clause of the requirements document [LDUP Requirements]. c) To collect and summarize LDAP Data Model and Operational Behavior constraints defined for LDAP in RFC 2251 [See Appendix A], that are to be preserved in LDAP replication. d) Where possible, to derive and present appropriate information from other ongoing IETF work (to the extent necessary to further Reed, Srinivasan September 2002 Page 3 LDAP Replication Architecture Model March 2002 define LDUP). The purpose such an exercise would be to avoid tying the LDUP working group to the schedule of any other working group. e) Present some useful concepts and their utility that are supported in existing commercial directory products. Even if these concepts were not adopted by subsequent LDUP protocol standards, it would still be useful to relate the LDUP design choices and alternatives. In addition to the above objectives document has to address, it should do so without infringing upon known registered intellectual property rights. 3.3 Document Non-Objectives This document does not address the following issues, as they are considered beyond the scope of the Working Group. A) How LDAP becomes a distributed directory. There are many issues beyond replication that should be considered. Such as, support for external references, algorithms for computing referrals from the distributed directory knowledge, etc. B) Specifying management protocols to create Replication Contexts or new Replicas. LDAP may be sufficient for this. The document describes how new Replication Contexts and Replicas are represented, in the directory, as entries, attributes, and attribute values. C) How transactions will be replicated. However, the architecture should not knowingly prevent or impede them, given the Working Group's incomplete understanding of the issues at this time. D) The problems of replication between implementations without a common schema representation, and hence require information mapping to achieve synchronization between them. 3.4 Existing Implementations In order to define a standard replication scheme that may be readily implemented we must consider the architectures of current LDAP server implementations. Existing systems currently support proprietary replication schemes based on one of two general approaches: log-based or state-based. The approach chosen in subsequent LDUP protocol design is neither stipulated nor assumed in this architecture draft, although certain sections of this document contain discussions of issues in the above approaches. Implementations based on the original University of Michigan LDAP server code record LDAP operations to a operation log. During a replication session operations are replayed from this log to bring the Consumer replica up to date. Example implementations of this type at this time are the IBM SecureWay, Innosoft, Netscape, Open LDAP and Oracle directory servers. Reed, Srinivasan September 2002 Page 4 LDAP Replication Architecture Model March 2002 3.5 Terms and Definitions The definitions from the Replication Requirements document have been copied here and extended. For brevity, an LDAP server implementation is referred to throughout as 'the server'. The LDAP update operations; Add, Delete, Modify, Modify RDN (LDAPv2) and Modify DN (LDAPv3), are collectively referred to as LDAP Update Operations. A Naming Context is a subtree of entries in the Directory Information Tree (DIT). There may be multiple Naming Contexts stored on a single server. Naming Contexts are defined in section 17 of [X501]. A _Replication Context_ represents a section of DIT defining a unit of administration for replication. A Replication Context is based at an entry identified as its root and includes all its subordinate entries down the tree to its leaves, or until another Replication Context is encountered. A Naming Context held by a server may be made up of one or more non-overlapping Replication Contexts. Non- replicated portions of a Naming Context may not be explicitly identified as a Replication Context.. A Replica is a replicated instance of a _Replication Context. A _Replication Context_ is said to be single-mastered if there is only one Replica where it may be updated, and multi-mastered if there is more than one Replica where it may be updated. A Replication Relationship is established between two or more Replicas that are hosted on servers that cooperate to service a common area (the Replication Context) of the DIT. A Replication Agreement is defined between two parties of a Replication Relationship. A Replication Agreement is associated with a set of replicas and defines properties such as the Update Transfer Protocol to be used, and the Replication Schedule of a Replication Session. A Replication Session is an LDAP session between the two servers identified by a replication agreement. Interactions occur between the two servers, resulting in the transfer of updates from the supplier replica to the consumer replica. The Initiator of a Replication Session is the initiating server. A Responder server responds to the replication initiation request from the Initiator server. A Supplier server is the source of the updates to be transferred. Reed, Srinivasan September 2002 Page 5 LDAP Replication Architecture Model March 2002 A Consumer server is the recipient of the update sequence. The Update Transfer Protocol is the means by which the Replication Session proceeds. It defines the protocol for exchanging updates between the Replication Relationship partners. A Replication Update is an LDAP Extended Operation that contains updates to be applied to the DIT. The Update Transfer Protocol carries a sequence of these messages from the Supplier to the Consumer. The Update Resolution Procedures repair constraint violations that occur when updates to a multi-mastered Replica collide. A Fractional Entry Specification is a list of entry attributes to be included, or a list of attributes to be excluded in a replica. An empty specification implies that all entry attributes are included. A Fractional Entry is an entry that contains only a subset of its original attributes. It results from the replication of changes governed by a Fractional Entry Specification. A Fractional Replica is a replica that holds Fractional Entries of its Replication Context. 3.6 Consistency Models This replication architecture supports a loose consistency model between replicas of a naming context. It does not attempt to provide the appearance of a single copy of a replica. The contents of each replica may be different, but over time they will be converging towards the same state. This architecture is not intended to support LDAP Clients that require a tight consistency model, where the state of all replicas is always equivalent. Three levels of consistency are available to LDAP Clients, which are characterized by their deployment topologies. Single-Server, where there is just the Replication Context and no replicas. Single- master, where there are replicas, but only one may be updated. And, multi-master, where there is more than one replica to which LDAP update operations may be directed. The consistency properties of each model are rooted in their serialization of read and write operations. 1) A single-server deployment of a Replication Context provides tight consistency to LDAP applications. LDAP Clients have no choice but to direct all their operations to a single server, serializing both read and write operations. 2) A single-mastered deployment of a Replication Context provides both tight and loose consistency to LDAP applications. LDAP Clients must direct all write operations to the single Master Replica, but may direct their reads to any of the replicas. A client experiences tight consistency by directing all its operations to the single Reed, Srinivasan September 2002 Page 6 LDAP Replication Architecture Model March 2002 Master Replica, and loose consistency by directing any read operations to any other replica. 3) A multi-mastered deployment of a Replication Context can provide only loose consistency to LDAP applications. Across the system writes and reads are not serialized. An LDAP Client could direct their read and write operations to a single Master Replica, but they will not receive tight consistency as interleaved writes could be occurring at another replica. Tight consistency can be achieved in a multi-master deployment for a particular LDAP application if and only if all instances of its client are directed towards the same Master Replica, and the application data is not updated by any other LDAP application. Introducing these constraints to an application ensures that writes are serialized providing tight consistency for the application. Future work could make use of the architecture proposed in this document as a basis for allowing clients to request session guarantees from a server when establishing a connection. 3.7 LDAP Constraints The LDAP-v3 Internet RFC [LDAPv3] defines a set of Data Model and Operation Behavior constraints that a compliant LDAP server must enforce. The server must reject an LDAP Update Operation if its application to the target entry would violate any one of these LDAP Constraints. [Appendix A contains the original text clauses from RFC 2251, and also a summary.] In the case of a single-server or single-mastered Replication Context all LDAP Constraints are immediately enforced at the single Master Replica. An error result code is returned to an LDAP Client that presents an operation that would violate the constraints. In the case of a multi-mastered Replication Context not all LDAP Constraints can be immediately enforced at the Master Replica to which the LDAP Update Operation is applied. This loosely consistent replication architecture ensures that at each replica all constraints are imposed, but as updates are replicated constraint violations arise that cannot be reported to the appropriate client. Any constraint violations that occur are repaired by a set of update resolution procedures. Any LDAP client that has been implemented to expect immediate enforcement of all LDAP Constraints may not behave as expected against a multi-mastered Replication Context. 4 Replication Environment The replication environment would consist of two or more replicas, each characterized with a "replica type". The following replica types are recognized. Reed, Srinivasan September 2002 Page 7 LDAP Replication Architecture Model March 2002 Note that LDUP protocol design could choose to not support all the types defined below. 4.1 Primary Replica NOTE: The requirements document has removed discussion or reference to a primary replica. At least one of the authors of this document (hi!;-) still think one will be needed in the management of the replica topology information itself, but that remains to be seen. REQUEST: Will the authors of "Mandatory LDAP Replica Management" [MRM] please weigh in on the question and tell us whether you need a Primary replica or not. The Primary Replica is a full copy of the Replica, to which all applications that require tight consistency should direct their LDAP Operations. There can be only one Primary Replica within the set of Replicas of a given Replication Context. It is also permissible for none of the Replicas to be designated the Primary. The Primary Replica MUST NOT be a Fractional Replica. [NOTE: The following paragraph makes assertions about assumptions of what who does to whom that should be cleaned up. Some commercial products use primaries, but don't indicate in schema or elsewhere the some attributes are to be managed at the Primary, but rather rely on the applications to know and enforce the rule. Such a flag could be useful, but let's not assert that it's an essential part of how Primary replicas have been implemented.] Some commercial directory products support the notion of a primary replica. This would mean that one of the replicas can be configured to be the "primary" (at any point in time) and certain attributes could be marked as "critical", meaning that they could only be altered on a primary. This configuration would cause all other replicas to deny alterations to these critical attributes and to direct such modifications transparently (via referrals) to the designated primary. To remain simple, LDUP Update Protocol is NOT REQUIRED to support "Primary Replica". Where necessary, it may be possible for administrators to implement appropriate access policies and other means of operation redirection to enforce the "primary replica" conventions. 4.2 Master Replica [NOTE: Previous drafts of this document called this the Updateable Replica. The name is changed here to correspond with the term used in the requirements document.] A Master Replica is a Replica that accepts all the LDAP Update Operations, but is not the Primary Replica. There could be none, Reed, Srinivasan September 2002 Page 8 LDAP Replication Architecture Model March 2002 one, or many Master Replicas within the set of Replicas of a given Replication Context. A Master Replica MUST NOT be a Fractional Replica for this version of LDUP. 4.3 Read-Only Replica A Read-Only Replica will accept only non-modifying LDAP operations against data subject to replication. Modifications to DSA-operation attributes, which are not replicated, may of course still be allowed. All other modification operations shall be referred to a Master Replica. The server referred to may be a Supplier of this Replica. NOTE: May a R-O Replica be a supplier of changes to another replica, either updateable or R-O? 4.4 Fractional Replicas Fractional Replicas must always be Read-Only. All LDAP Update Operations must be referred to a Master Replica in this version of LDUP. The server referred to may be a Supplier of this Fractional Replica. 5 Information Model [NOTE: This must be closely realigned with the INFOMOD document, and with whatever administrative model we're using...In particular, the abandonment of the ldapSubentry proposal from Reed leaves open the question of whether hierarchical subentries will be used or not.] This section describes the schema elements that represent the replication topology and replication run time information. The operational information for replication is administered through these entries. The LDUP Working Group will work towards defining an Internet standard to fully detail all these schema elements. 5.1 Sub-Entries Replication management entries are to be stored at the base of the Replication Context. They will be of a `ldapSubentry' objectclass to exclude them from regular searches. Entries with the objectclass ldapSubentry are not returned as the result of a search unless a control is included in the request to make them visible. 5.2 Glue Entries A glue entry is an entry that contains knowledge of its name only. No other information is held with it. Such glue entries will be distinguished through a special object class defined for that purpose. Glue entries may be created during a replication session to repair a constraint violation. Reed, Srinivasan September 2002 Page 9 LDAP Replication Architecture Model March 2002 5.3 Unique Identifiers Distinguished names can change, so are therefore unreliable as identifiers. A Unique Identifier must therefore be assigned to each entry as it is created. This identifier will be stored as an operational attribute of the entry, named `entryUUID'. The entryUUID attribute is single valued. A consistent algorithm for generating such unique identifiers should be defined for use in the LDUP standards documents that detail the LDUP information model and LDUP protocols. 5.4 Change Sequence Number Change Sequence Numbers (CSNs) are used to impose a total ordering upon the causal sequence of updates applied to all the replicas of a Replication Context. Every LDAP Update Operation is assigned at least one CSN. A Modify operation MUST be assigned one CSN per modification. 5.4.1 CSN Composition A CSN is formed of four components. In order of significance they are; the time, a change count, a Replica Identifier, and a modification number. The CSN is composed thus to ensure the uniqueness of every generated CSN. When CSNs are compared to determine their ordering they are compared component by component: first the time, then the change count, then the replica identifier, and finally the modification number. The time component is a year-2000-safe (year 9999-safe, really) representation of the real world time, with a granularity of one second. Because many LDAP Update Operations, at a single replica, may be applied to the same data in a single second, the change count component of the CSN is provided to further order the changes. Each replica maintains a count of LDAP update operations applied against it. It is reset to zero at the start of each second, and is monotonically increasing within that second, incremented for each and every update operation. Should LDAP Update Operations occur at different replicas, to the same data, within the same single second, and happen to be assigned the same change count number, then the Replica Identifier is used to further order the changes. The Replica Identifier is the value of the RDN attribute on the Replica Subentry that represents the Replica. The Replica Identifier could be assigned programmatically or administratively, in either case short values are advised to minimize resource usage. The IA5CaseIgnoreString syntax is used to compare and order Replica Identifier values. The fourth and final CSN component, the modification number, is used for ordering the modifications within an LDAP Modify operation. Reed, Srinivasan September 2002 Page 10 LDAP Replication Architecture Model March 2002 5.4.2 CSN Representation The preferred CSN representation is: yyyy mm dd hh:mi:ssz # 0xSSSS # replica id # 0xssss The `z' in the time stipulates that the time is expressed in GMT without any daylight savings time offsets permitted, and the 0xssss represents the hexadecimal representation of an unsigned integer. Implementations must support 16 bit change counts and should support longer ones (32, 64, or 128 bits). An example CSN would be " 1998081018:44:31z#0x000F#1#0x0000 ". The update assigned this CSN would have been applied at time 1998081018:44:31z happened to be the 16th operation which was applied in that second, was made against the replica with identifier `1', and was the first modification of the operation that caused the change. 5.4.3 CSN Generation Because Change Sequence Numbers are primarily based on timestamps, clock differences between servers can cause unexpected change ordering. The synchronization of server clocks is not required, though it is preferable that clocks are accurate. If timestamps are not accurate, and a server consistently produces timestamps that are significantly older than those of other servers, its updates will not have effect and the real world time ordering of updates will not be maintained. However, an implementation may choose to require clock synchronization. The Network Time Protocol [NTP] [SNTP] offers a protocol means by which heterogeneous server hosts may be time synchronized. The modifications that made up an LDAP Modify operation are presented in a sequence. This must be preserved when the resultant changes of this operation are replicated. 5.5 Entries, Semantics and Relationships This section defines the organization of operational data for directory replication in terms of the relative placement of the entries that represent Replication Contexts, its Replicas, and their associated Replication agreements. This section also describes the purpose of these objects and abstractly describes their content. A Replication Context defines an area of DIT with independent replication policies. There are many mechanisms available to identify the set of Replication Contexts in a Directory, including through special auxiliary classes or through operational attributes in root DSE pointing to such entries. The LDUP information model standards will detail an appropriate mechanism. Reed, Srinivasan September 2002 Page 11 LDAP Replication Architecture Model March 2002 Entries representing the set of Replicas associated with a Replication Context are created immediately below (children) the Replication Context entries. Replica entries are defined as subentries and are intended to hold attributes that identify the Replica's LDAP Access Point, its Replica Type, and if it is a Fractional Replica, the attributes it does or does not hold. The attribute value of the entry's Relative Distinguished Name (RDN) is termed the Replica Identifier and is used as a component of each CSN associated with the replica. Immediately subordinate to each Replica Subentry are the entries representing the Replication Agreements between this replica and another replica on some other server in the network. A Replication Agreement entry is associated with exactly one remote replica. These entries are defined to hold attributes identifying the remote Replica associated with this agreement, the scheduling policy for replication operations, including times when replication is to be performed, when it is not to be performed, or the policies governing event-driven replication initiation another Replica, the scheduling policy for replication operations, including times when replication is to be performed, when it is not to be performed, or the policies governing event-driven replication initiation. 5.6 Root DSE Attributes The Root DSE attributes carry information that is essential to the operation of the local DSA itself. Each node has its own independent copy of such attributes and hence these are not to be replicated to other nodes. In general this is true for all operational attributes of type "DsaOperation". LDUP information model itself will define Root DSE attributes to identify the set of Replication Contexts and replicas present in an LDAP server. 5.7 Replication Context Auxiliary Object Class and Entries Each Replication Context contains attributes that hold common configuration and policy information for all replicas of the Replication Context. A Replication Context Creation attribute records when and where the Replication Context was created. The Replication Context is based at the entry given the auxiliary class, and continues down the tree until leaf entries or another Replication Context is encountered. 5.8 Replica Object Class and Entries Reed, Srinivasan September 2002 Page 12 LDAP Replication Architecture Model March 2002 A replica type characterizes each Replica. This may be Primary, Updateable, or Read-Only. The Replica entry will also include a Fractional Entry Specification for a Fractional Replica. There is a need to represent network addresses of servers holding replicas involved in Replication Agreements. For this, the LDUP information model will define an attribute with an appropriate syntax to represent an LDAP server addresses with which to contact replicas. An Update Vector describes the point to which the Replica has been updated, in respect to all the other Replicas of the Replication Context. The vector is used at the initiation of a replication session to determine the sequence of updates that should be transferred. Enabling LDAP to be a fully distributed service is not an objective for the design of LDUP information model, though the information stored in replica entries could facilitate certain distributed operations. 5.9 Lost and Found Entry When replicating operations between servers, conflicts may arise that cause a parent entry to be removed causing its child entries to become orphaned. In this case the Update Resolution Procedures will make the Lost and Found Entry the child's new superior. Each Replica Entry names its Lost and Found Entry, which would usually be an entry below the Replica Entry itself. This well-known place allows administrators, and their tools, to find and repair abandoned entries. 5.10 Replication Agreement Object Class and Entries The Replication Agreement defines: 1. The schedule for Replication Sessions initiation. 2. The server that initiates the Replication Session, either the Consumer or the Supplier. 3. The authentication credentials that will be presented between servers. 4. The network/transport security scheme that will be employed in order to ensure data confidentiality and integrity. 5. The replication protocols and relevant protocol parameters to be used for Full and Incremental updates. An OID is used to identify the update transfer protocol, thus allowing for future extensions or bilaterally agreed upon alternatives. Reed, Srinivasan September 2002 Page 13 LDAP Replication Architecture Model March 2002 6. If the Replica is Fractional, the Fractional Entry Specification, for the attributes to be included or excluded Permission to participate in replication sessions will be controlled, at least in part, by the presence and content of replica agreements. The Supplier must be subject to the access control policy enforced by the Consumer. Since the access control policy information is stored and replicated as directory content, the access control imposed on the Supplier by the Consumer must be stored in the Consumer's Replication Agreement. 5.10.1 Replication Schedule There are two broad mechanisms for initiating replication sessions: (1) scheduled event driven and (2) change event driven. The mechanism used to schedule replication operations between two servers is determined by the Schedule information that is part of the Replication Agreement governing the Replicas on those two servers. Because each Replication Agreement describes the policy for one direction of the relationship, it is possible that events propagate via scheduled events in one direction, and by change events in the other. Change event driven replication sessions are, by their nature, initiated by suppliers of change information. The server that the change is made against schedules a replication session in response to the change itself, so that notification of the change is passed on to other Replicas. Either consumers or suppliers of change information can initiate scheduled event driven replication sessions. The schedule defines a calendar of time periods during which Replication Sessions should be initiated. Schedule information may include both scheduled and change event driven mechanisms. For instance, one such policy may be to begin replication within 15 seconds of any change event, or every 30 minutes if no change events are received. 6 Replication of Directory Administrative Policy Information Administrative policy information governs the behavior of the directory server. Schema, access control, and replication, all involve administrative policy information. This policy information (irrespective of how it is represented in the directory- as sub- entries, attributes, or attribute values) should be consistently known and enforced by servers managing any replica. Normally, policy information present within a Replication Context is replicated in the same manner as any other directory information. But applicable policy information could reside outside a Replication Context. Reed, Srinivasan September 2002 Page 14 LDAP Replication Architecture Model March 2002 Administrative policy information associated with directory replication lies within the replication context to which it applies. Hence, fortunately, any replica will also contain (include) all of its applicable replication policy data. On the other hand, some administrative boundaries (administrative areas) for other services might extend to subordinate Replication Contexts. For instance, some prescriptive access control policy applicable to entries in a Replication Context could be represented by an entry that is an ancestor of the root of the Replication Context. For access control policies to be faithfully enforced by a server hosting a replica of such a Replication Context, all applicable prescriptive policy information must also be available within that server. But policy propagation is not an issue for replicated directories only. These same issues are also relevant to distributed directories. Many possible protocols could be conceived to ensure that anywhere in the directory network, all applicable policies are available so that these are enforced appropriately. To support flexible and dependable deployments, DSAs supporting LDUP should also implement IETF standard protocols for policy propagation. It is expected that such an IETF standard protocol will be defined in a way relevant for any LDAP directory deployment, be it distributed, replicated or a combination of both. But defining such a protocol is outside the scope of LDUP architecture. 6.1 Schema Replication Given the strict ordering of replication events, schema modifications will normally be replicated prior to entry operations that use them, and subsequent to data deletions that eliminate references to schema elements to be deleted. In a multi-master environment with multiple suppliers, the order of arrival at a consumer node of such changes cannot be guaranteed. The LDUP standards for reconciliation should define procedures for handling such scenarios. 7 Change Representation and Update Resolution The state changes in a replica can be introduced via either LDAP Update Operations or via Replication Updates. A CSN is included with all changes made to an entry, its attributes, and attribute values. This state information must be recorded for the entry to enable a total ordering of updates. When an update is performed, the CSN recorded is the CSN assigned at the server where the change was first made. In other words, CSNs are only assigned to changes performed by LDAP client updates and are propagated with other change information. When Replication update is performed at the target replica node the CSN associated with the replicated change being processed is recorded. Each of the LDAP Update operations changes their target entry in different ways, and records the CSN of the change differently. The state information for the resultant state changes is recorded at Reed, Srinivasan September 2002 Page 15 LDAP Replication Architecture Model March 2002 three levels: the entry level, attribute level, and attribute value level. 7.1 Entry Creation and Deletion When an entry is created the CSN of the change is added to the entry as an operational attribute. Deleted entries are marked as deleted through some means such as addition of an object class denoting this sate. Deleted entries are not visible to LDAP clients - they may not be read, they don't appear in lists or search results, and they may not be changed once deleted. Names of deleted entries are available for reuse by new entries immediately after the deleted entry is so marked. It may be desirable to allow deleted entries to be accessed and manipulated by management and data recovery applications, but that is outside the scope of this document. A CSN is recorded for both the RDN, and the Superior DN of the entry. 7.2 Attribute Creation and Deletion When all values of an attribute have been deleted, the attribute is marked as deleted and the CSN of the deletion is recorded. The deleted state and CSN are represented and stored by the server in an implementation dependent way and hence may not be accessible by search operations. This state information must be stored to enable the Update Resolution Procedures to be performed. It may be desirable to allow the deleted state and CSN information to be accessed and manipulated by management and data recovery applications, but that is outside the scope of this document. 7.3 Attribute Value Changes The Modification CSN for each value is to be set by the server when it accepts a modification request to the value, or when a new value with a later Modification CSN is received via Replication. The modified value and the Modification CSN changes are required to be atomic, so that the value and its Modification CSN cannot be out of synch on a given server. The server stores the state information, but it has no representation on the entry, and may not be the subject of a search operation. It may be desirable to allow the state information to be accessed and manipulated by management and data recovery applications, but that is outside the scope of this document. When the value of an attribute is deleted the state of its deletion must be recorded, with the CSN of the modifying change. It must be stored to enable the Update Resolution Procedures to be performed. 7.4 Update Inconsistency Reed, Srinivasan September 2002 Page 16 LDAP Replication Architecture Model March 2002 The server must reject LDAP client update operations with a CSN that is older than the state information that would be replaced if the operation were performed. This could occur in a replication topology where the difference between the clocks of Master Replicas was too large. 8 LDUP Update Transfer Protocol Framework A Replication Session occurs between a Supplier server and Consumer server over an LDAP connection. This section describes the process by which a Replication Session is initiated, started and stopped. The session initiator, termed the Initiator, could be either the Supplier or Consumer. The Initiator sends an LDAP extended operation to the Responder identifying the replication agreement being acted on. The Supplier then sends a sequence of updates to the Consumer. All transfers are in one direction only. A two-way exchange requires two replication sessions - one session in each direction. 8.1 Replication Session Initiation The Initiator starts the Replication Session by opening an LDAP connection to its Responder. The Initiator binds using the authentication credentials provided in the Replication Agreement. The LDUP Update Transfer Protocol will define the LDAP extended operation the Initiator should perform to initialize an LDUP session. For the sake of convenience, this extended LDAP operation for initializing a replication session is referred to as the _Start Replication_ operation. Among other things, this operation will identify the role each server will perform, and what type of replication is to be performed. One server is to be the Consumer, the other the Supplier, and the replication may be either Full or Incremental. LDUP Update Transfer protocol could define additional protocol primitives that allow the replicating nodes to reverse their "supplier/consumer" role without having to reinitiate a new replication cycle. 8.1.1 Authentication The initiation of a Replication Session is to be restricted to privileged clients. The identity and the credentials for the client eligible for initiating a replication session will be specified as attributes within Replication Agreements. 8.1.2 Consumer Initiated The Consumer binds to the Supplier using the authentication credentials specified in the Replication Agreement. The Consumer sends the Start Replication extended request to begin the Replication Session. The Supplier returns a Start Replication extended response containing a response code. The Consumer then disconnects from the Supplier. If the Supplier has agreed to the Reed, Srinivasan September 2002 Page 17 LDAP Replication Architecture Model March 2002 replication session initiation, it binds to the Consumer and behaves just as if the Supplier initiated the replication. 8.1.3 Supplier Initiated The Supplier binds to the Consumer using the authentication credentials provided in the Replication Agreement. The Supplier sends the _Start Replication_ extended request to begin the Replication Session. The Consumer returns a _Start Replication_ extended response containing a response code, and possibly its Update Vector. If the Consumer has agreed to the Replication Session initiation, then the transfer protocol begins. 8.2 Start Replication Session 8.2.1 Start Replication Request The LDUP Update Transfer Protocol will define an LDAP Extended Request, referred to in this document as _Start Replication Request, which is sent from the Initiator to Responder. The parameters of the _Start Replication Request_ would identify the Replication Agreement associated with the session, the Update Transfer Protocol associated with the replication session, and other state information necessary to initiate a replication session between the two servers. 8.2.2 Start Replication Response The LDUP Update Transfer Protocol will define an LDAP Extended Response, _Start Replication Response_, sent in reply to a Start Replication Request, from the Responder to the Initiator. The parameters of the Start Replication Response include a response code, and an optional Update Vector. 8.3 Update Transfer Each Update Transfer Protocol is identified by an OID. An LDUP conformant server implementation must support those update protocols that are defined as mandatory in the Update Transfer Protocol standard, and may support many others. A server will advertise its protocols in the Root DSE multi- valued attribute 'supportedReplicationProtocols'. The Update Transfer Protocol would define the mechanisms for a Consumer to receive a complete (full) update or incremental update based on the current state of replication represented in the Update Vector. A full update is necessary for initializing a consumer replica upon establishment of replication agreements. 8.4 End Replication Session The _End Replication Request_ initiated by the supplier terminates a Replication Session. The purpose of this request and response is to secure the state of the Update Vector associated with the two Reed, Srinivasan September 2002 Page 18 LDAP Replication Architecture Model March 2002 replicas that participated in replication. This is necessary for proper resumption of replication during subsequent LDUP sessions. 8.5 Major States of Replicas The state of a Replica controls the activities of the DSA that holds the replica as well as that of other replicas with which it has a replication agreement. This state represents whether a DSA is available for replication with another DSA or not. The following states of replica are envisioned. 1) A particular instance of a directory is NOT PARTICIPATING in replication for a given area of replication and a given second instance. In this state the instance need not record change information for changes made in the context. 2) A particular instance of a directory is PARTICIPATING but NOT ONLINE for a given area of replication and second instance. In this case changes are recorded and will be sent when the instance goes ONLINE. 3) A particular instance is PARTICIPATING and ONLINE for a given area of replication and second instance. In this case changes are being exchanged (subject to replication schedules, etc.). It is possible for a given server to be ONLINE with some of the other servers in the replica group and NOT ONLINE with others. The fourth case (ONLINE and NOT PARTICIPATING) cannot occur. 8.5.1 Replica State Changes Replica state changes are expected to trigger as a result of administrative actions such as creation of a new replica instance, removal of a replica, and creation of a replication-agreement referring to a set of replicas. LDUP information model defines a Replica "subentry". The state of a replica is represented within attributes in this Replica subentry. Some of these attributes are of significance and specific to the local DSA (attributes of type "dsaOperation") and hence are not replicated to any other node. Others, however, may be useful to clients and other DSAs (for instance, whether the replica is "ONLINE", it's update vector, or the result of the last replication session for each replica agreement). Each Replica would contain a Replica subentry, one representing itself and one each for all other replicas (associated with the same Replication Context) in the network. A DSA’s actions w.r.t to another replica (based on a binding replication agreement) would depend on the replicas own state, as well as that of the state of the latter. These states can be manually set to maintain control over the DSA behavior. Hence, in addition to automatically Reed, Srinivasan September 2002 Page 19 LDAP Replication Architecture Model March 2002 triggered state changes, it should be possible to manually set these attributes as well. 8.6 Integrity & Confidentiality Data integrity (i.e., protection from unintended changes) and confidentiality (i.e., protection from unintended disclosure to eavesdroppers) SHOULD be provided by appropriate selection of underlying transports, for instance TLS, or IPSEC. Replication MUST be supported across TLS LDAP connections. Servers MAY be configured to refuse replication connections over unprotected TCP connections. 9 LDUP Update Protocols This Internet-Draft defines two transfer protocols for the supplier to push changes to the consumer. Other protocols could be defined to transfer changes, including those that pull changes from the supplier to the consumer, but those are left for future work. 9.1 Replication Updates and Update Primitives LDUP Update Protocol defines how Replication Updates are transferred from the Supplier to the Consumer. Each Replication Update consists of a set of Update Primitives that describe the state changes that have been made to a single entry. Each Replication Update is associated with a single entry identified by its UUID. The Update Transfer Protocol would define a set of Update Primitives each of which codifies an assertion about the state change of an entry that resulted from a directory update operation. The primitives will include sufficient data to allow recreation of corresponding state changes on the consumer's replica. An assertion- based approach has been chosen in such a way that the Primitives are idempotent, meaning that re-application of a Primitive to an Entry will cause no change to the entry. This is desirable as it provides some resilience against some kinds of system failures. Each Update Primitive contains a CSN that represents an ordering among all such primitives generated anywhere in the network. The consumer uses this ordering information to reconcile among those primitives that lead to consistency violation. 9.2 Fractional Updates When fully populating or incrementally bringing up to date a Fractional Replica each of the Replication Updates must only contain updates to the attributes in the Fractional Entry Specification. 10 LDUP Full Update Transfer Protocol 10.1 Full Update Transfer This Full Update Protocol provides a bulk transfer of the replica contents for the initial population of new replicas, and the Reed, Srinivasan September 2002 Page 20 LDAP Replication Architecture Model March 2002 refreshing of existing replicas. The LDUP Update Transfer protocol standard will define the ways for this transfer is initiated. The Consumer must replace its entire replica contents with that sent from the Supplier. The Consumer MUST NOT service any requests for this Naming Context whilst the full update is being applied. The Consumer should instead return a referral to another replica, possibly the supplier. [REF] 10.2 Replication Update Generation The entire state of a Replicated Area can be mapped onto a sequence of Replication Updates, each of which contains a sequence of Update Primitives that describe the entire state of a single entry. The sequence of Replication Updates must be ordered such that no entry is created before its parent. 10.3 Replication Update Consumption A Consumer will receive the Replication Updates, extract the sequence of Update Primitives, and must apply them to the DIB in the order provided. 10.4 Full Update, End Replication Session A Full Update should also result in the replication of all appropriate LDUP meta-data (which are part of the Replication Context), such as the sub-entry representing the Replica being updated and the Update Vector associated with it. The Supplier could be accepting updates whilst the update is in progress. Once the Full Update has completed, an Incremental Update should be performed to transfer these changes. 10.5 Interrupted Transmission If the Replication Session terminates before the End Replication Request is sent, then the Replica could be in an inconsistent state. Until the replica is restored to a consistent state, the consumer MUST NOT permit LDAP Clients to access the incomplete replica. The Consumer could refer the Client to the Supplier Replica, or return an error result code. 11 LDUP Incremental Update Transfer Protocol For efficiency, the Incremental Update Protocol transmits only those changes that have been made to the Supplier replica that the Consumer has not already received. In a replication topology with transitive redundant replication agreements, changes may propagate through the replica network via different routes. The Consumer must not support multiple concurrent replication sessions with more than one Supplier for the same Replication Context. A Supplier that attempts to initiate a Replication Session Reed, Srinivasan September 2002 Page 21 LDAP Replication Architecture Model March 2002 with a Consumer already participating as a Consumer in another Replication Session should receive an appropriate error. 11.1 Update Vector The Supplier uses the Consumer's Update Vector to determine the sequence of updates that should be sent to the Consumer. Each Replica entry includes an Update Vector to record the point to which the replica has been updated. The vector is a set of CSN values, one value for each known Master Replica. Each CSN value in the vector corresponds to the most recent change known locally that occurred in the Master Replica that this Update Vector value represents. For example, consider two Master Replicas of a Replication Context, one is assigned replica identifier `1', the other replica identifier `2'. Each is responsible for maintaining its own update vector, which will contain two CSNs, one for each replica. So, if both replicas are identical they will have equivalent update vectors. Both Update Vectors = {1998081018:44:31z#0x000F#1#0x0000, 1998081018:51:20z#0x0001#2#0x0000} Subsequently, at 7pm, an update is applied to replica `2', so its update vector is updated. Replica `1' Update Vector = {1998081018:44:31z#0x000F#1#0x0000, 1998081018:51:20z#0x0001#2#0x0000} Replica `2' Update Vector = {1998081018:44:31z#0x000F#1#0x0000, 1998081019:00:00z#0x0000#2#0x0000} Since the Update Vector records the state to which the replica has been updated, a supplier server, during Replication Session initiation, can determine the sequence of updates that should be sent to the consumer. From the example above no updates need to be sent from replica `1' to replica `2', but there is at least one update pending from replica `2' to replica `1'. Because the Update Vector embodies knowledge of updates made at all known replicas it supports replication topologies that include transitive and redundant connections between replicas. It ensures that changes are not transferred to a consumer multiple times even though redundant replication agreements may exist. It also ensures that updates are passed across the replication network between replicas that are not directly linked to each other. Reed, Srinivasan September 2002 Page 22 LDAP Replication Architecture Model March 2002 It may be the case that a CSN for a given replica is absent from the update vector, for one of two reasons. 1. CSNs for Read-Only replicas might be absent because no changes will have ever been applied to that Replica, so there are no changes to replicate. 2. CSNs for newly created replicas may be absent because no changes from that replica have yet been propagated. An Update Vector might also contain a CSN for a replica that no longer exists. The replica may have been temporarily taken out of service, or may have been removed from the replication topology permanently. An implementation may choose to retire a CSN after some configurable time period. 11.2 Supplier Initiated, Incremental Update, Start Replication Session The Consumer Responder must return its Update Vector to the Supplier Initiator. The Supplier uses this to determine the sequence of Replication Updates that need to be sent to the Consumer. 11.3 Replication Update Generation The Supplier generates a sequence of Replication Updates to be sent to the consumer. To enforce LDAP Constraint LDAP Constraints Clauses.6, that the LDAP Modify must be applied atomically, each Replication Update must contain the entire sequence of Update Primitives for all the LDAP Operations for which the Replication Update contains Update Primitives. Stated less formally, for each primitive the update contains, it must also contain all the other primitives that came from the same operation. A log-based implementation might take the approach of mapping LDAP Operations onto an equivalent sequence of Update Primitives. A systematic procedure for achieving this will be fully described in the standard document defining Update Reconciliation Procedures. The Consumer Update Vector is used to determine the sequence of LDAP Operations in the operation log that the Consumer has not yet seen. 11.4 Replication Update Consumption A Consumer will receive Replication Updates, extract the sequence of Update Primitives, and must apply them to the DIB in the order provided. LDAP Constraint LDAP Constraints Clauses.6 states that the modifications within an LDAP Modify operation must be applied in the sequence provided. Those Update Primitives must be reconciled with the current replica contents and any previously received updates. In short, updates are compared to the state information associated with the item being Reed, Srinivasan September 2002 Page 23 LDAP Replication Architecture Model March 2002 operated on. If the change has a more recent CSN, then it is applied to the directory contents. If the change has an older CSN it is no longer relevant and its change must not be effected. If the consumer acts as a supplier to other replicas then the updates are retained for forwarding. 11.5 Update Resolution Procedures The LDAP Update Operations must abide by the constraints imposed by the LDAP Data Model and LDAP Operational Behavior, Appendix A. An operation that would violate at least one of these constraints is rejected with an error result code. The loose consistency model of this replication architecture and its support for multiple Master Replicas of a Replication Context means that LDAP Update Operations could be valid at one replica, but not in another. At the time of acceptance, the accepting replica may not have received other updates that would cause a constraint to be violated, and the operation to be rejected. Replication Updates must never be rejected because of a violation of an LDAP Constraint. If the result of applying the Replication Update causes a constraint violation to occur, then some remedial action must be taken to satisfy the constraint. These Update Resolution Procedures are introduced here, and fully described in These Update Resolution Procedures are introduced here will be fully defined within LDUP Update Resolution Procedures. 11.5.1 URP: Distinguished Names LDAP Constraints 20.1.1 and 20.1.10 ensure that each entry in the replicated area has a unique DN. A Replication Update could violate this constraint producing two entries, with different unique identifiers, but with the same DN. The resolution procedure is to rename the both entries so that its RDN includes its own unique identifier. This ensures that the DN of both the entries shall be unique. 11.5.2 URP: Orphaned Entries LDAP Constraints 20.1.11 ensures that every entry must have a parent entry. A Replication Update could violate this constraint producing an entry with (as yet) no parent entry. The resolution procedure is to create a Glue Entry to take the place of the absent parent. The Glue Entry's superior will be the Lost and Found Entry. This well- known place allows administrators and their tools (including subsequent Replication Sessions) to find and repair orphaned entries. 11.5.3 URP: Schema - Single Valued Attributes LDAP Constraint 20.1.7 enforces the single-valued attribute schema restriction. A Replication Update could violate this constraint Reed, Srinivasan September 2002 Page 24 LDAP Replication Architecture Model March 2002 creating a multi-value single-valued attribute. The resolution procedure is to replace the earlier value of a single-valued attribute with the newer value. In this way the most recently added value will be retained, and the older one discarded. 11.5.4 URP: Schema - Required Attributes LDAP Constraint 20.1.7 enforces the schema objectclass definitions on an entry. A Replication Update could violate this constraint creating an entry that does not have attribute values for required attributes. The resolution procedure is to ignore the schema violation and mark the entry as a glue entry for administrative repair or correction in a subsequent replication session. 11.5.5 URP: Schema - Extra Attributes LDAP Constraint 20.1.3 and 20.1.7 enforces the schema objectclass definitions on an entry. A Replication Update could violate this constraint creating an entry that has attribute values not allowed by the objectclass values of the entry. The resolution procedure is to ignore the schema violation and mark the entry as a glue entry for administrative repair or correction in a subsequent replication session. 11.5.6 URP: Duplicate Attribute Values LDAP Constraint 20.1.5 ensures that the values of an attribute constitute a set of unique values. A Replication Update could violate this constraint. The resolution procedure is to enforce this constraint, recording the most recently assigned CSN with the value. 11.5.7 URP: Ancestry Graph Cycle LDAP Constraint 20.4.2.1 prevents against a cycle in the DIT. A Replication Update could violate this constraint causing an entry to become it's own parent, or for it to appear even higher in it's ancestry graph. The resolution procedure is to break the cycle by changing the parent of the entry closest to be the lost and found entry. 11.6 Incremental Update, End Replication Session If the Supplier sent none of its own updates to the Consumer, then the Supplier's CSN within the Supplier's update vector should be updated with the earliest possible CSN that it could generate, to record the time of the last successful replication session. The Consumer will have received the Supplier's Update Vector in the replica sub- entry it holds for the Supplier replica. The Consumer's resultant Update Vector CSN values will be at least as great as the Supplier's Update Vector. Reed, Srinivasan September 2002 Page 25 LDAP Replication Architecture Model March 2002 The Supplier may request that the Consumer return its resultant Update Vector so that the Supplier can update its replica sub-entry for the Consumer Replica. The Supplier requests this by setting a flag in the End Replication Request. The default flag value is TRUE meaning the Consumer Update Vector must be returned. 11.7 Interrupted Transmission If the Replication Session terminates before the End Replication Request is sent then the Consumer's Update Vector may or may not be updated to reflect the updates received. The Start Replication request includes a Replication Update Ordering flag that states whether the updates were sent in CSN order per replica. Since updates are sent in CSN order per replica then it is possible to update the Consumer Update Vector to reflect that some portion of the updates to have been sent have been received and successfully applied. The next Incremental Replication Session will pick up where the failed session left off. 12 Purging State Information The state information stored with each entry need not be stored indefinitely. A server implementation may choose to periodically, or continuously, remove state information that is no longer required. The mechanism is implementation- dependent, but to ensure interoperability between implementations, the state information must not be purged until all known replicas have received and acknowledged the change associated with a CSN. This is determined from the Purge Vector [Purge Vector]. All the CSNs stored that are lower than the Purge Vector may be purged, because no changes with older CSNs can be replicated to this replica. 12.1 Purge Vector The Purge Vector is an Update Vector constructed from the Update Vectors of all known replicas. Below the root of a Replication Context is one sub-entry for each known replica of that Replication Context. Each of those entries contains the last known update vector for that replica. The lowest CSN for each replica are taken from these update vectors to form the Purge Vector. The Purge Vector is used to determine when state information and updates need no longer be stored. 12.2 Purging Deleted Entries, Attributes, and Attribute Values The following conditions must hold before an item can be deleted from the Directory Information Base. 1) The LDAP delete operation has been propagated to all replication agreement partners. Reed, Srinivasan September 2002 Page 26 LDAP Replication Architecture Model March 2002 2) All the CSNs in other replica Update Vectors representing changes to be sent to the server holding the deleted entry have advanced beyond the CSN on the deletion (similarly for deleted attributes and attribute values). 3) The CSN generator of the other Replicas must have advanced beyond the deletion CSN of the deleted entry. Otherwise, it is possible for one of those Replicas to generate operations with CSNs earlier than the deleted entry. 13 Replication Configuration and Management Replication management entries, such as replica or replication agreement entries can be altered on any Master Replica. These entries are implicitly included in the directory entries governed by any agreement associated with this Replication Context. As a result, all servers with a replica of a Replication Context will have access to information about all other replicas and associated agreements. The deployment and maintenance of a replicated directory network involves the creation and management of all the replicas of a Replication Context and replication agreements among these replicas. This section outlines, through an example, the administrative actions necessary to create a new replica and establish replication agreements. Typically, administrative tools will guide the administrator and facilitate these actions. The objective of this example is to illustrate the architectural relationship among various replication related operational information. A copy of an agreement should exist on both the supplier and consumer side for the replication update transfer protocol to be able to start. For this purpose, the root of the Replication Context, replica objects and the replication agreement objects are created first on one of the servers. A copy of these objects is then manually created on the second server associated with the agreement. The scenario below starts with a server (named DSA1) that holds a Master Replica of a Replication Context, RC1. Procedures to establish a Master Replica of the Replication Context on a second server (DSA2) are outlined. Note that when entries are created on two or more separate servers in the operations described below, they need to be created with the same entry UUIDs so that they don't collide with one another when replication of their information actually occurs. This may be done through some administrative control that allows the entry UUID to be set by the create entry operation. 1. On DSA1: Add RC1's context prefix to the value of Root DSE attribute 'replicaRoot'. Reed, Srinivasan September 2002 Page 27 LDAP Replication Architecture Model March 2002 2. On DSA1: Alter the 'ObjectClass' attribute of the root entry of RC1 to include the "replicationContext" auxiliary class. 3. On DSA1: Create a replica object, RC1-R1, (as a child of the root of RC1) to represent the replica on DSA1. The attributes include replica type (updateable, read-only etc.) and DSA1 access point information. 4. On DSA2: Add RC1's context prefix to the value of Root DSE attribute 'replicaRoot'. 5. On DSA2: Create a copy of the root entry of RC1 as a copy of the one in DSA1 (including the replicationContext auxiliary class) 6. On DSA2: Create a copy of the replica object RC1-R1 7. On DSA2: Create a second replica object, RC1-R2 (as a sibling of RC1-R1) to represent the replica on DSA2. 8. On DSA1: Create a copy of the replica object RC1-R2 9. On DSA1: Create a replication agreement object, RC1-R1-R2 to represent update transfer from RC1-R1 to RC1-R2. This object is a child of RC1-R1. 10. On DSA2: Create a copy of the replication agreement, RC1- R1-R2. 11. On DSA2: Create a replication agreement, RC1-R2-R1, to represent update transfer from RC1-R2 to RC1-R1. This object is a child of RC1-R2. 12. ON-DSA1: Create a copy of the replication agreement, RC1- R2-R1. After these actions update transfer to satisfy either of the two agreements can commence. If data already existed in one of the replicas, the update transfer protocol should perform a complete update of the data associated with the agreement before normal replication begins. 13. Time The server assigns a CSN for every LDAP update operation it receives. Since the CSN is principally based on time, the CSN is susceptible to the Replica clocks drifting in relation to each other (either forwards or backwards). The server must never assign a CSN older than or equal to the last CSN it assigned. The server must reject update operations, from any source, which would result in setting a CSN on an entry or a value that is earlier than possible. The error code serverClocksOutOfSync (72) should be returned if it is clear that the update is not simply an old one that should be silently ignored. In particular, additions or Reed, Srinivasan September 2002 Page 28 LDAP Replication Architecture Model March 2002 modifications with CSNs prior to those on the servers Purge Vector should be rejected. 14 Security Considerations The preceding architecture discussion covers the server authentication, session confidentiality, and session integrity in sections Authentication and Integrity & Confidentiality. The IETF draft "Authentication Methods" for LDAP, provides a detailed LDAP security discussion. Its introductory passage is paraphrased below. [AUTH] A Replication Session can be protected with the following security mechanisms. 1) Authentication by means of the SASL mechanism set, possibly backed by the TLS credentials exchange mechanism, 2) Authorization by means of access control based on the Initiators authenticated identity, 3) Data integrity protection by means of the TLS protocol or data- integrity SASL mechanisms, 4) Protection against snooping by means of the TLS protocol or data- encrypting SASL mechanisms, The configuration entries that represent Replication Agreements may contain authentication information. This information must never be replicated between replicas. Updates to a multi-mastered entry may collide causing the Update Resolution Procedures [Update Resolution Procedures] to reject or reverse one of the changes to the entry. The URP algorithms resolve conflicts by using the total ordering of updates imposed by the assignment of CSNs for every operation. As a consequence updates originating from system administrators have no priority over updates originating from regular system users. 14.1 Audit Capabilities LDAP servers should enhance their audit capabilities to support collection and management of audit logs about replication activities. Much of replication management operations is sensitive in nature and hence should be auditable. Also important is the auditability of replication sessions by maintaining history log of replication sessions, capturing the servers a node had engaged in replication with in either direction. 15 Acknowledgements This document is a product of the LDUP Working Group of the IETF. The contribution of its members is greatly appreciated. John Reed, Srinivasan September 2002 Page 29 LDAP Replication Architecture Model March 2002 Merrells, an original editor of early drafts of the document, made many valuable contributions. 16 References [AUTH] _ M. Wahl, H. Alvestrand, J. Hodges, RL "Bob" Morgan, "Authentication Methods for LDAP", Internet Draft, draft-ietf- ldapext-authmeth-02.txt, June 1998. [BCP-11] _ R. Hovey, S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. [LDAPv3] _ M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access Protocol (v3)", RFC 2251, December1997. [LDUP Requirements] - R. Weiser, E. Stokes 'LDAP Replication Requirements', Internet Draft, draft-weiser- replica-req-02.txt, October, 1999. [NTP] _ D. L. Mills, "Network Time Protocol (Version 3)", RFC 1305, March, 1992. [RFC2119] _ S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119. [RFC2252] _ M. Wahl, A. Coulbeck, T. Howes, S. Kille, _Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions_, RFC 2252, December 1997. [SNTP] _ D. L. Mills, "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030, University of Delaware, October 1996. [TLS] _ J. Hodges, R. L. "Bob" Morgan, M. Wahl, "Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security", Internet draft, draft-ietf-ldapext-ldapv3-tls-01.txt, June 1998. [X501] _ ITU-T Recommendation X.501 (1993), ) | ISO/IEC 9594- 2:1993, Information Technology _ Open Systems Interconnection _ The Directory: Models [X680] _ ITU-T Recommendation X.680 (1994) | ISO/IEC 8824- 1:1995, Information technology _ Abstract Syntax Notation One (ASN.1): Specification of Basic Notation [X525] _ ITU-T Recommendation X.525 (1997) | ISO/IEC 9594- 9:1997, Information Technology _ Open Systems Interconnection _ The Directory: Replication 17 Intellectual Property Notice The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to Reed, Srinivasan September 2002 Page 30 LDAP Replication Architecture Model March 2002 pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. [BCP-11] Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 18 Copyright Notice Copyright (C) The Internet Society (1998,1999,2000,2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 19 Authors' Address Edwards E. Reed Reed-Matthews, Inc., Honeoye Falls, NY E-mail: eer@oncalldba.com Uppili Srinivasan Oracle, Inc., Redwood Shores, CA E-mail: Uppili.Srinivasan@oracle.com Reed, Srinivasan September 2002 Page 31 LDAP Replication Architecture Model March 2002 LDUP Working Group Mailing List: ietf-ldup@imc.org 20 Appendix A _ LDAP Constraints 20.1 LDAP Constraints Clauses This is an enumeration of the Data Model and Operation Behaviour constraint clauses defined in RFC 2251. [LDAPv3] 1) Data Model - Entries have names: one or more attribute values from the entry form its relative distinguished name (RDN), which MUST be unique among all its siblings. (p5) 2) Data Model - Attributes of Entries - Each entry MUST have an objectClass attribute. (p6) 3) Data Model - Attributes of Entries - Servers MUST NOT permit clients to add attributes to an entry unless those attributes are permitted by the object class definitions. (p6) 4) Relationship to X.500 - This document defines LDAP in terms of X.500 as an X.500 access mechanism. An LDAP server MUST act in accordance with the X.500 (1993) series of ITU recommendations when providing the service. However, it is not required that an LDAP server make use of any X.500 protocols in providing this service, e.g. LDAP can be mapped onto any other directory system so long as the X.500 data and service model as used in LDAP is not violated in the LDAP interface. (p8) 5) Elements of Protocol - Common Elements - Attribute - Each attribute value is distinct in the set (no duplicates). (p14) 6) Elements of Protocol - Modify Operation - The entire list of entry modifications MUST be performed in the order they are listed, as a single atomic operation. (p33) 7) Elements of Protocol - Modify Operation - While individual modifications may violate the directory schema, the resulting entry after the entire list of modifications is performed MUST conform to the requirements of the directory schema. (p33) 8) Elements of Protocol - Modify Operation - The Modify Operation cannot be used to remove from an entry any of its distinguished values, those values which form the entry's relative distinguished name. (p34) 9) Elements of Protocol - Add Operation - Clients MUST include distinguished values (those forming the entry's own RDN) in this list, the objectClass attribute, and values of any mandatory attributes of the listed object classes. (p35) Reed, Srinivasan September 2002 Page 32 LDAP Replication Architecture Model March 2002 10) Elements of Protocol - Add Operation - The entry named in the entry field of the AddRequest MUST NOT exist for the AddRequest to succeed. (p35) 11) Elements of Protocol - Add Operation - The parent of the entry to be added MUST exist. (p35) 12) Elements of Protocol - Delete Operation - ... only leaf entries (those with no subordinate entries) can be deleted with this operation. (p35) 13) Elements of Protocol - Modify DN Operation - If there was already an entry with that name [the new DN], the operation would fail. (p36) 14) Elements of Protocol - Modify DN Operation - The server may not perform the operation and return an error code if the setting of the deleteoldrdn parameter would cause a schema inconsistency in the entry. (p36) 20.2 LDAP Data Model Constraints The LDAP Data Model Constraint clauses as written in RFC 2251 [LDAPv3] may be summarised as follows. a) The parent of an entry must exist. (LDAP Constraint 11 & 12.) b) The RDN of an entry is unique among all its siblings. (LDAP Constraint 1.) c) The components of the RDN must appear as attribute values of the entry. (LDAP Constraint 8 & 9.) d) An entry must have an objectclass attribute. (LDAP Constraint 2 & 9.) e) An entry must conform to the schema constraints. (LDAP Constraint 3 & 7.) f) Duplicate attribute values are not permitted. (LDAP Constraint 5.) 20.3 LDAP Operation Behaviour Constraints The LDAP Operation Behaviour Constraint clauses as written in RFC 2251 [LDAPv3] may be summarized as follows. A) The Add Operation will fail if an entry with the target DN already exists. (LDAP Constraint 10.) B) The Add Operation will fail if the entry violates data constraints: Reed, Srinivasan September 2002 Page 33 LDAP Replication Architecture Model March 2002 a - The parent of the entry does not exist. (LDAP Constraint 11.) b - The entry already exists. (LDAP Constraint 10.) c - The entry RDN components do not appear as attribute values on the entry. (LDAP Constraint 9.) d - The entry does not have an objectclass attribute. (LDAP Constraint 9.) e - The entry does not conform to the schema constraints. (LDAP Constraint 9.) f - The entry has no duplicated attribute values. (LDAP Constraint 5.) C) The modifications of a Modify Operation are applied in the order presented. (LDAP Constraint 6.) D) The full set of modifications of a Modify Operation are applied as one atomic unit. (LDAP Constraint 6.) E) A Modify Operation will fail if it results in an entry that violates data constraints: c - If it attempts to remove distinguished attribute values. (LDAP Constraint 8.) d - If it removes the objectclass attribute. (LDAP Constraint 2.) e - If it violates the schema constraints. (LDAP Constraint 7.) f - If it creates duplicate attribute values. (LDAP Constraint 5.) F) The Delete Operation will fail if it would result in a DIT that violates data constraints: a - The deleted entry must not have any children. (LDAP Constraint 12.) G) The ModDN Operation will fail if it would result in a DIT or entry that violates data constraints: b - The new Superior entry must exist. (Derived LDAP Data Model Constraint A) c - An entry with the new DN must not already exist. (LDAP Constraint 13.) Reed, Srinivasan September 2002 Page 34 LDAP Replication Architecture Model March 2002 c - The new RDN components do not appear as attribute values on the entry. (LDAP Constraint 1.) d - If it removes the objectclass attribute. (LDAP Constraint 2.) e - It is permitted for the operation to result in an entry that violates the schema constraints. (LDAP Constraint 14.) 20.4 New LDAP Constraints The introduction of support for multi-mastered entries, by the replication scheme presented in this document, necessitates the imposition of new constraints upon the Data Model and LDAP Operation Behaviour. 20.4.1 New LDAP Data Model Constraints 1) Each entry shall have a unique identifier generated by the UUID algorithm available through the `entryUUID' operational attribute. The entryUUID attribute is single valued. 20.4.2 New LDAP Operation Behaviour Constraints 1) The LDAP Data Model Constraints do not prevent cycles in the ancestry graph. Existing constraints Data Model Constraint _ New LDAP Data Model Constraints _ (a) and Operation Constraint _ New LDAP Operation Behaviour Constraints _ (B) would prevent this in the single master case, but not in the presence of multiple masters. 2) The LDAP Data Model Constraints state that only the LDAP Modify Operation is atomic. All other LDAP operations, namely, ADD, DELETE and MODDN are also considered to be atomically applied to the DIB. Reed, Srinivasan September 2002 Page 35 --=_7B26CAAD.96F799F3-- From owner-ietf-ldup@mail.imc.org Fri Mar 1 16:26:13 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29245 for ; Fri, 1 Mar 2002 16:26:12 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g21Kvfb10552 for ietf-ldup-bks; Fri, 1 Mar 2002 12:57:41 -0800 (PST) Received: from smtp.oncalldba.com (roc-24-169-98-155.rochester.rr.com [24.169.98.155]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g21KveG10546 for ; Fri, 1 Mar 2002 12:57:40 -0800 (PST) Received: from RMINC_DOM-MTA by smtp.oncalldba.com with Novell_GroupWise; Fri, 01 Mar 2002 15:54:50 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Fri, 01 Mar 2002 15:54:26 -0700 From: "Ed Reed" To: Subject: Open issues / questions re: Architecture of LDUP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g21KveG10549 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hello, all. In compiling the latest version of the architecture document (draf-ietf-ldup-model-07.txt, just submitted and copied to the list), I tried to keep track of the things I don't know about what we're doing. Here's a summary... 1) what administrative model will be used for managing replica topology information? There are three offerings on the table: a retracted proposal from me with my ldapSubentry definition, Kurt's Subentry schema entry implies certain things that would come from the X.500 admin model, and Steven Legg's description of the X.500 model as adapted for LDAP for use with a Basic or Simple Access Control models. I hope we'll arrive at a concensus (quickly) to adopt the work Steven's worked on (since my own offering was shot down out of the gate). 2) Replica Context and Replicas with regard to DSAs - is it allowed to define two or more DIFFERENT Replica Contexts for the same portion of the DIT (for instance, one full and the others fractional in different ways)? Are those different Replica Contexts, or different replica configurations of the same Replica Context? 3) Depending on your answer to #2, is it permitted (in the information model, for instance) to ever have two or more Replicas of the SAME Replication Context (or more precisely, of all or part of the same subtree of the DIT sharing a common base entry) ON THE SAME DSA? If so, and if something akin to a presentation address is to be associated with each replica, there must be a way to address them separately when setting up an LDAP connection for an LDUP replication session...how would that be done? 4) Are sparse replicas in or out? right now, they're out of the architecture, but read-only franctional replicas are in. 5) Is the notion of a Primary replica type dead, or will the Mandatory Replica Management engineering team find a need for one? I confess that I don't know (yet) whether they have already decided they don't need one, or not. Comments welcome. Ed ================= Ed Reed Reed-Matthews, Inc. +1 585 624 2402 http://www.Reed-Matthews.COM Note: Area code is 585 From owner-ietf-ldup@mail.imc.org Fri Mar 1 17:24:37 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03721 for ; Fri, 1 Mar 2002 17:24:36 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g21LpBf12343 for ietf-ldup-bks; Fri, 1 Mar 2002 13:51:11 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g21LpAG12339 for ; Fri, 1 Mar 2002 13:51:10 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g21LpAC02968; Fri, 1 Mar 2002 21:51:10 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020301133450.017c3a60@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 01 Mar 2002 13:51:09 -0800 To: "Ed Reed" From: "Kurt D. Zeilenga" Subject: Re: Open issues / questions re: Architecture of LDUP Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 02:54 PM 2002-03-01, Ed Reed wrote: >In compiling the latest version of the architecture document (draf-ietf-ldup-model-07.txt, just submitted and copied to the list), I tried to keep track of the things I don't know about what we're doing. Here's a summary... > >1) what administrative model will be used for managing replica topology information? There are three offerings on the table: a retracted proposal from me with my ldapSubentry definition, Kurt's Subentry schema entry implies certain things that would come from the X.500 admin model, and Steven Legg's description of the X.500 model as adapted for LDAP for use with a Basic or Simple Access Control models. I hope we'll arrive at a concensus (quickly) to adopt the work Steven's worked on (since my own offering was shot down out of the gate). I think there are really only two (or one if your proposal is truly retracted). The description of the X.500 admin model and description of the subentry mechanism of that model together describe one approach. A subsequent revision of the subentry I-D (which Steven and I co-authored) will likely absorb the generic description of the X.500 model from Steven's X.500 models I-D. I recommend this WG to build the replication administrative model upon the framework provided by the X.500 generic administrative model. Kurt From owner-ietf-ldup@mail.imc.org Fri Mar 1 17:39:16 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04226 for ; Fri, 1 Mar 2002 17:39:16 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g21M8oG12661 for ietf-ldup-bks; Fri, 1 Mar 2002 14:08:50 -0800 (PST) Received: from smtp.oncalldba.com (roc-24-169-98-155.rochester.rr.com [24.169.98.155]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g21M8nG12657 for ; Fri, 1 Mar 2002 14:08:49 -0800 (PST) Received: from RMINC_DOM-MTA by smtp.oncalldba.com with Novell_GroupWise; Fri, 01 Mar 2002 17:05:59 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Fri, 01 Mar 2002 17:05:38 -0700 From: "Ed Reed" To: Cc: Subject: Re: Open issues / questions re: Architecture of LDUP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g21M8nG12658 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit That's what I thought. I concur. That means that the hierarchical subentry information model will need adaptation, in particular to make explicit the association between a replicationAgreement and the two (or more?) replicas which share it (since without name subordination in the hierarchical subentry scheme, the parent association doesn't exist as one of the referenced replicas). MRM and INFOMOD authors should take note, and voice objections, if any, soon. Ed >>> "Kurt D. Zeilenga" 03/01/02 04:51PM >>> At 02:54 PM 2002-03-01, Ed Reed wrote: >In compiling the latest version of the architecture document (draf-ietf-ldup-model-07.txt, just submitted and copied to the list), I tried to keep track of the things I don't know about what we're doing. Here's a summary... > >1) what administrative model will be used for managing replica topology information? There are three offerings on the table: a retracted proposal from me with my ldapSubentry definition, Kurt's Subentry schema entry implies certain things that would come from the X.500 admin model, and Steven Legg's description of the X.500 model as adapted for LDAP for use with a Basic or Simple Access Control models. I hope we'll arrive at a concensus (quickly) to adopt the work Steven's worked on (since my own offering was shot down out of the gate). I think there are really only two (or one if your proposal is truly retracted). The description of the X.500 admin model and description of the subentry mechanism of that model together describe one approach. A subsequent revision of the subentry I-D (which Steven and I co-authored) will likely absorb the generic description of the X.500 model from Steven's X.500 models I-D. I recommend this WG to build the replication administrative model upon the framework provided by the X.500 generic administrative model. Kurt ================= Ed Reed Reed-Matthews, Inc. +1 585 624 2402 http://www.Reed-Matthews.COM Note: Area code is 585 From owner-ietf-ldup@mail.imc.org Fri Mar 1 20:46:46 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09631 for ; Fri, 1 Mar 2002 20:46:45 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g221Pqj16845 for ietf-ldup-bks; Fri, 1 Mar 2002 17:25:52 -0800 (PST) Received: from tconl91223.tconl.com (tconl91223.tconl.com [204.26.91.223]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g221PoG16838 for ; Fri, 1 Mar 2002 17:25:50 -0800 (PST) Received: (from jayhawk@localhost) by tconl91223.tconl.com (8.11.6/8.11.0) id g221O4505792; Fri, 1 Mar 2002 19:24:04 -0600 Date: Fri, 1 Mar 2002 19:24:04 -0600 From: Ryan Moats To: Ed Reed Cc: ietf-ldup@imc.org Subject: Re: Open issues / questions re: Architecture of LDUP Message-ID: <20020301192404.C1435@localhost.localdomain> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from eer@OnCallDBA.COM on Fri, Mar 01, 2002 at 03:54:26PM -0700 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: | 5) Is the notion of a Primary replica type dead, or will the Mandatory | Replica Management engineering team find a need for one? I confess that | I don't know (yet) whether they have already decided they don't need one, | or not. I'll jump in here. To date, I don't think we've seen a need for one, as our discussions so far have been in terms of "updatable or primary" and not a case where there's a difference. Ryan From owner-ietf-ldup@mail.imc.org Fri Mar 1 23:05:07 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14029 for ; Fri, 1 Mar 2002 23:05:06 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g223gf119360 for ietf-ldup-bks; Fri, 1 Mar 2002 19:42:41 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g223gdG19356; Fri, 1 Mar 2002 19:42:39 -0800 (PST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.us.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id WAA56762; Fri, 1 Mar 2002 22:39:21 -0500 Received: from d27mcs01.rchland.ibm.com (d27mcs01.rchland.ibm.com [9.10.226.29]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g223gYr51150; Fri, 1 Mar 2002 22:42:34 -0500 Subject: Re: Open issues / questions re: Architecture of LDUP To: "Ed Reed" Cc: ietf-ldup@imc.org, Kurt@OpenLDAP.org, owner-ietf-ldup@mail.imc.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: From: "John McMeeking" Date: Fri, 1 Mar 2002 21:42:34 -0600 X-MIMETrack: Serialize by Router on d27mcs01/27/M/IBM(Release 5.0.9a |January 7, 2002) at 03/01/2002 09:42:36 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think that the adaptation falls into two areas: 1) a subentry entry that defines an area of replication as an administrative area with replicaSubentry containing a DN pointer to this subentry. 2) change replicaSubentry and replicaAgreementSubentry to not be subentries. Then these classes can have their existing hierarchical relationship. There would be no need for a subtreespecification matching rule -- DN match works fine. That said, I need to reread various x.500 specs to make sure my understanding of administrative area as it applies to LDUP is adequate. John McMeeking "Ed Reed" M> cc: Sent by: Subject: Re: Open issues / questions re: Architecture of LDUP owner-ietf-ldup@m ail.imc.org 03/01/2002 06:05 PM That's what I thought. I concur. That means that the hierarchical subentry information model will need adaptation, in particular to make explicit the association between a replicationAgreement and the two (or more?) replicas which share it (since without name subordination in the hierarchical subentry scheme, the parent association doesn't exist as one of the referenced replicas). MRM and INFOMOD authors should take note, and voice objections, if any, soon. Ed >>> "Kurt D. Zeilenga" 03/01/02 04:51PM >>> At 02:54 PM 2002-03-01, Ed Reed wrote: >In compiling the latest version of the architecture document (draf-ietf-ldup-model-07.txt, just submitted and copied to the list), I tried to keep track of the things I don't know about what we're doing. Here's a summary... > >1) what administrative model will be used for managing replica topology information? There are three offerings on the table: a retracted proposal from me with my ldapSubentry definition, Kurt's Subentry schema entry implies certain things that would come from the X.500 admin model, and Steven Legg's description of the X.500 model as adapted for LDAP for use with a Basic or Simple Access Control models. I hope we'll arrive at a concensus (quickly) to adopt the work Steven's worked on (since my own offering was shot down out of the gate). I think there are really only two (or one if your proposal is truly retracted). The description of the X.500 admin model and description of the subentry mechanism of that model together describe one approach. A subsequent revision of the subentry I-D (which Steven and I co-authored) will likely absorb the generic description of the X.500 model from Steven's X.500 models I-D. I recommend this WG to build the replication administrative model upon the framework provided by the X.500 generic administrative model. Kurt ================= Ed Reed Reed-Matthews, Inc. +1 585 624 2402 http://www.Reed-Matthews.COM Note: Area code is 585 From owner-ietf-ldup@mail.imc.org Sun Mar 3 19:52:42 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01755 for ; Sun, 3 Mar 2002 19:52:42 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g240UKN24214 for ietf-ldup-bks; Sun, 3 Mar 2002 16:30:20 -0800 (PST) Received: from nexus.adacel.com (shelob.adacel.com.au [203.36.26.146] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g240UI824209 for ; Sun, 3 Mar 2002 16:30:18 -0800 (PST) Received: (qmail 507 invoked from network); 4 Mar 2002 00:30:22 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 4 Mar 2002 00:30:22 -0000 Reply-To: From: "Steven Legg" To: "'Ed Reed'" Cc: , Subject: RE: Basic Access Control for LDAP Date: Mon, 4 Mar 2002 11:29:01 +1100 Message-ID: <009101c1c313$95c70e50$a518200a@osmium.mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 In-Reply-To: Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ed, Ed Reed wrote: > Thanks for that clarification, Steven - that's different from > some directories > I know that force ACI subjects to be of one of a few classes known to > represent security principals. Basic Access Control was defined to have the property that all access control decisions can be made using only the information held locally by the server making the decision. If BAC insisted that user's entries belong to specific classes then, in a distributed directory service, chained operations are potentially required while making access control decisions. BAC does allow implementations to impose additional local constraints (such as a requirement that user entries belong to specific classes), but these constraints have no standard representation so they won't necessarily be enforced by a replication partner. Regards, Steven > Ed > > >>> "Steven Legg" 02/28/02 09:36PM >>> > > Ed, > > Ed Reed wrote: > > Actually, my question is a bit more basic - > > > > Does allUsers include entries of any and all object classes, or only > > object classes derived from "person", or only "person"s with, say, > > a password attribute present, or some other definition? > > As far as Basic Access Control is concerned, an identified user > (i.e. a requestor) is just a distinguished name. The distinguished > name doesn't even have to refer to a real entry, so the object class > of the user's entry, if such an entry exists, is completely > irrelevant. > > The allUsers case includes not only any identified user, but also > completely anonymous requestors for which no associated distinguished > name was able to be established at bind time. > > Regards, > Steven > > > > > Ed > > > > ================= > > Ed Reed > > Reed-Matthews, Inc. > > +1 585 624 2402 > > http://www.Reed-Matthews.COM > > Note: Area code is 585 > > > > >>> "Steven Legg" 02/28/02 01:16AM >>> > > > > Ed, > > > > Ed Reed wrote: > > > One question from reading the drafts (for now) - > > > > > > What constitutes a "user" for the purpose of ACI UserClasses > > > value allUsers? > > > > In the first instance it is anyone/anything who manages to bind in, > > regardless of their authorization identity, but it is qualified by > > the AuthenticationLevel and whether a permission is being granted > > or denied. > > > > For a permission being granted: > > > > 1) If the AuthenticationLevel is "none" then allUsers > > includes everyone, > > regardless of authorization identity, anonymous included. > > > > 2) If the AuthenticationLevel is "simple" then allUsers includes all > > users who have authenticated with at least a user name and password. > > Anonymous users and users who have not been authenticated are > > excluded. > > > > 3) If the AuthenticationLevel is "strong" then allUsers includes all > > users who have authenticated with strong credentials, e.g digital > > signatures. Anonymous users, unauthenticated users and password > > authenticated users are excluded. > > > > For a permission being denied, allUsers includes everyone, > > regardless of authorization identity and authentication level. > > > > Regards, > > Steven > > > > > > > > > From owner-ietf-ldup@mail.imc.org Tue Mar 5 06:43:50 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24837 for ; Tue, 5 Mar 2002 06:43:50 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g25BNHO04199 for ietf-ldup-bks; Tue, 5 Mar 2002 03:23:17 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g25BNF804195 for ; Tue, 5 Mar 2002 03:23:16 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23936; Tue, 5 Mar 2002 06:23:14 -0500 (EST) Message-Id: <200203051123.GAA23936@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldup-replica-req-11.txt Date: Tue, 05 Mar 2002 06:23:14 -0500 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF. Title : LDAPv3 Replication Requirements Author(s) : E. Stokes, R. Weiser, R. Moats, R. Huber Filename : draft-ietf-ldup-replica-req-11.txt Pages : 30 Date : 04-Mar-02 This document discusses the fundamental requirements for replication of data accessible via the Lightweight Directory Access Protocol (version 3) [RFC2251]. It is intended to be a gathering place for general replication requirements needed to provide interoperability between informational directories. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica-req-11.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldup-replica-req-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldup-replica-req-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020304142610.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-replica-req-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-replica-req-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020304142610.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Tue Mar 5 06:51:53 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25076 for ; Tue, 5 Mar 2002 06:51:52 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g25BVUg04322 for ietf-ldup-bks; Tue, 5 Mar 2002 03:31:30 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g25BVT804318 for ; Tue, 5 Mar 2002 03:31:29 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24135; Tue, 5 Mar 2002 06:31:28 -0500 (EST) Message-Id: <200203051131.GAA24135@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldup-urp-06.txt Date: Tue, 05 Mar 2002 06:31:28 -0500 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF. Title : LDUP Update Reconciliation Procedures Author(s) : S. Legg, A. Payne Filename : draft-ietf-ldup-urp-06.txt Pages : 32 Date : 04-Mar-02 This document describes the procedures used by Lightweight Directory Access Protocol (LDAP) directory servers or X.500 directory servers to reconcile updates performed by autonomously operating directory servers in a distributed, replicated directory service, using the LDAP Duplication/Replication/Update protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldup-urp-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldup-urp-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020304141606.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-urp-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-urp-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020304141606.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Tue Mar 5 23:38:02 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15809 for ; Tue, 5 Mar 2002 23:38:01 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g264TBn12243 for ietf-ldup-bks; Tue, 5 Mar 2002 20:29:11 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g264TA812239 for ; Tue, 5 Mar 2002 20:29:10 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g264T5C33497 for ; Wed, 6 Mar 2002 04:29:05 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020305201539.02b4ba98@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 05 Mar 2002 20:29:00 -0800 To: ietf-ldup@imc.org From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-ldup-replica-req-11.txt In-Reply-To: <200203051123.GAA23936@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: In reviewing this latest revision to see if the changes reflect WG input, I find that the following new text in the the Security Consideration section makes no sense. Security- related and general LDAP interoperability will be significantly impacted by the degree of consistency with which LDAP implementations support the access control requirements [RFC2820]. RFC 2820 does not provide a technical specification or otherwise make requirements upon LDAP implementations. It places requirements upon LDAPext engineering work. That is, RFC 2820 has itself zero impact on LDAP interoperability. Kurt From owner-ietf-ldup@mail.imc.org Tue Mar 5 23:41:43 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15887 for ; Tue, 5 Mar 2002 23:41:43 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g264WGZ12344 for ietf-ldup-bks; Tue, 5 Mar 2002 20:32:16 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g264WE812340 for ; Tue, 5 Mar 2002 20:32:14 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g264WGC33531; Wed, 6 Mar 2002 04:32:16 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020305194521.02b41088@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 05 Mar 2002 20:32:10 -0800 To: "Ed Reed" From: "Kurt D. Zeilenga" Subject: Re: Open issues / questions re: Architecture of LDUP Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 02:54 PM 2002-03-01, Ed Reed wrote: >Hello, all. > >In compiling the latest version of the architecture document (draf-ietf-ldup-model-07.txt, just submitted and copied to the list), I tried to keep track of the things I don't know about what we're doing. Here's a summary... > >1) what administrative model will be used for managing replica topology information? There are three offerings on the table: a retracted proposal from me with my ldapSubentry definition, Kurt's Subentry schema entry implies certain things that would come from the X.500 admin model, and Steven Legg's description of the X.500 model as adapted for LDAP for use with a Basic or Simple Access Control models. I hope we'll arrive at a concensus (quickly) to adopt the work Steven's worked on (since my own offering was shot down out of the gate). > >2) Replica Context and Replicas with regard to DSAs - is it allowed to define two or more DIFFERENT Replica Contexts for the same portion of the DIT (for instance, one full and the others fractional in different ways)? Are those different Replica Contexts, or different replica configurations of the same Replica Context? I would argue that all entries within scope of a subentry define a "area of replication" or "replica context". (I would use only the term "area of replication".) Each subentry defines one replication agreement. It may be appropriate to limit the scope of that agreement to only a pair of replication peers and possibly even to one replication flow. >4) Are sparse replicas in or out? right now, they're out of the architecture, but read-only franctional replicas are in. Not to further wrapped around terminology, I'd say in. In fact, I suggest one use the subentry's subtree refinement mechanism to define a sparse set of entries to replicate. Kurt From owner-ietf-ldup@mail.imc.org Wed Mar 6 07:03:08 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03334 for ; Wed, 6 Mar 2002 07:03:07 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g26BoXJ25215 for ietf-ldup-bks; Wed, 6 Mar 2002 03:50:33 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g26BoW825210 for ; Wed, 6 Mar 2002 03:50:32 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02766; Wed, 6 Mar 2002 06:50:30 -0500 (EST) Message-Id: <200203061150.GAA02766@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldup-urp-06.txt Date: Wed, 06 Mar 2002 06:50:30 -0500 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF. Title : LDUP Update Reconciliation Procedures Author(s) : S. Legg, A. Payne Filename : draft-ietf-ldup-urp-06.txt Pages : 32 Date : 04-Mar-02 This document describes the procedures used by Lightweight Directory Access Protocol (LDAP) directory servers or X.500 directory servers to reconcile updates performed by autonomously operating directory servers in a distributed, replicated directory service, using the LDAP Duplication/Replication/Update protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldup-urp-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldup-urp-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020304141606.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-urp-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-urp-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020304141606.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Wed Mar 6 07:46:21 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04913 for ; Wed, 6 Mar 2002 07:46:21 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g26CbtG27205 for ietf-ldup-bks; Wed, 6 Mar 2002 04:37:55 -0800 (PST) Received: from smtp.oncalldba.com (roc-24-169-98-155.rochester.rr.com [24.169.98.155]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g26Cbs827201 for ; Wed, 6 Mar 2002 04:37:54 -0800 (PST) Received: from RMINC_DOM-MTA by smtp.oncalldba.com with Novell_GroupWise; Wed, 06 Mar 2002 07:34:23 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Wed, 06 Mar 2002 07:34:03 -0700 From: "Ed Reed" To: Cc: Subject: Re: Open issues / questions re: Architecture of LDUP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g26Cbt827202 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Maybe it's early in the AM, Kurt, but I'm unsure as to your meaning... In the LDUP information model, we use subentries in several places... a) as the definition of the "area of replication" associated with an LDUP administration point, b) as the specification of the contents (may be either the same set or a subset of the one defined for the "area of replication") held by a particular replica on a particular server, and c) as the set (may be either the same or a subset of the one defined for the supplier replica) of entries about which change information is to flow along a particular replication agreement between two (or possibly more, tbd) particular replicas. Which of those do you mean in your remarks?? >>> "Kurt D. Zeilenga" 03/05/02 11:32PM >>> At 02:54 PM 2002-03-01, Ed Reed wrote: >Hello, all. > >In compiling the latest version of the architecture document (draf-ietf-ldup-model-07.txt, just submitted and copied to the list), I tried to keep track of the things I don't know about what we're doing. Here's a summary... > >1) what administrative model will be used for managing replica topology information? There are three offerings on the table: a retracted proposal from me with my ldapSubentry definition, Kurt's Subentry schema entry implies certain things that would come from the X.500 admin model, and Steven Legg's description of the X.500 model as adapted for LDAP for use with a Basic or Simple Access Control models. I hope we'll arrive at a concensus (quickly) to adopt the work Steven's worked on (since my own offering was shot down out of the gate). > >2) Replica Context and Replicas with regard to DSAs - is it allowed to define two or more DIFFERENT Replica Contexts for the same portion of the DIT (for instance, one full and the others fractional in different ways)? Are those different Replica Contexts, or different replica configurations of the same Replica Context? I would argue that all entries within scope of a subentry define a "area of replication" or "replica context". (I would use only the term "area of replication".) Each subentry defines one replication agreement. It may be appropriate to limit the scope of that agreement to only a pair of replication peers and possibly even to one replication flow. >4) Are sparse replicas in or out? right now, they're out of the architecture, but read-only franctional replicas are in. Not to further wrapped around terminology, I'd say in. In fact, I suggest one use the subentry's subtree refinement mechanism to define a sparse set of entries to replicate. Kurt From owner-ietf-ldup@mail.imc.org Wed Mar 6 09:49:55 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10781 for ; Wed, 6 Mar 2002 09:49:54 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g26EfWx05349 for ietf-ldup-bks; Wed, 6 Mar 2002 06:41:32 -0800 (PST) Received: from out019.verizon.net (out019pub.verizon.net [206.46.170.98]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g26EfV805345 for ; Wed, 6 Mar 2002 06:41:31 -0800 (PST) Received: from D7ST2111 ([141.158.243.31]) by out019.verizon.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20020306144126.HFOL379.out019.verizon.net@D7ST2111> for ; Wed, 6 Mar 2002 08:41:26 -0600 Reply-To: From: "Chris Apple" To: Subject: RE: I-D ACTION:draft-ietf-ldup-replica-req-11.txt Date: Wed, 6 Mar 2002 09:41:03 -0500 Message-ID: <002f01c1c51c$f16d8fd0$0200a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0030_01C1C4F3.089787D0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <5.1.0.14.0.20020305201539.02b4ba98@127.0.0.1> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0030_01C1C4F3.089787D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I have read RFC 2820 5 times this morning and cannot find a statement in it that supports your claim. Consider the document's abstract: Abstract This document describes the fundamental requirements of an access control list (ACL) model for the Lightweight Directory Application Protocol (LDAP) directory service. It is intended to be a gathering place for access control requirements needed to provide authorized access to and interoperability between directories. Given that summary of RFC 2820, I don't follow your claim that the text from the security considerations section makes no sense. Chris Apple christopher.apple@verizon.net -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] On Behalf Of Kurt D. Zeilenga Sent: Tuesday, March 05, 2002 11:29 PM To: ietf-ldup@imc.org Subject: Re: I-D ACTION:draft-ietf-ldup-replica-req-11.txt In reviewing this latest revision to see if the changes reflect WG input, I find that the following new text in the the Security Consideration section makes no sense. Security- related and general LDAP interoperability will be significantly impacted by the degree of consistency with which LDAP implementations support the access control requirements [RFC2820]. RFC 2820 does not provide a technical specification or otherwise make requirements upon LDAP implementations. It places requirements upon LDAPext engineering work. That is, RFC 2820 has itself zero impact on LDAP interoperability. Kurt ------=_NextPart_000_0030_01C1C4F3.089787D0 Content-Type: text/x-vcard; name="Chris Apple (christopher.apple@verizon.net).vcf" Content-Disposition: attachment; filename="Chris Apple (christopher.apple@verizon.net).vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Apple;Christopher FN:Chris Apple (christopher.apple@verizon.net) TEL;HOME;VOICE:(215) 873-0850 TEL;CELL;VOICE:(610) 585-4241 ADR;WORK:;;214 New Street, Apt 4-N;Philadelphia;PA;19106;United States = of America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:214 New Street, Apt = 4-N=3D0D=3D0APhiladelphia, PA 19106=3D0D=3D0AUnited States of Am=3D erica EMAIL;PREF;INTERNET:christopher.apple@verizon.net REV:20011217T233830Z END:VCARD ------=_NextPart_000_0030_01C1C4F3.089787D0-- From owner-ietf-ldup@mail.imc.org Wed Mar 6 10:47:21 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13926 for ; Wed, 6 Mar 2002 10:47:20 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g26Fapk07968 for ietf-ldup-bks; Wed, 6 Mar 2002 07:36:51 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g26Fan807961 for ; Wed, 6 Mar 2002 07:36:49 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g26FamC36157; Wed, 6 Mar 2002 15:36:48 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020306070921.01717508@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 06 Mar 2002 07:36:42 -0800 To: From: "Kurt D. Zeilenga" Subject: RE: I-D ACTION:draft-ietf-ldup-replica-req-11.txt Cc: In-Reply-To: <002f01c1c51c$f16d8fd0$0200a8c0@D7ST2111> References: <5.1.0.14.0.20020305201539.02b4ba98@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 06:41 AM 2002-03-06, Chris Apple wrote: >I have read RFC 2820 5 times this morning and cannot find a statement >in it that supports your claim. Much like the LDUP Requirements I-D, RFC 2820 is NOT a protocol technical specification. It outlines design requirements which engineers of a technical specification should consider. The statement "LDAP implementations support the access control requirements [RFC2820]" makes no sense as RFC 2820 makes no requirements upon LDAP implementations. Now, the statement could be rewritten: Security- related and general LDAP interoperability will be significantly impacted by the degree of consistency with which LDAP implementations support a future Standard Track technical specification meeting Access Control Requirements for LDAP [RFC2820]. Kurt >Consider the document's abstract: > >Abstract > > This document describes the fundamental requirements of an access > control list (ACL) model for the Lightweight Directory Application > Protocol (LDAP) directory service. It is intended to be a gathering > place for access control requirements needed to provide authorized > access to and interoperability between directories. > >Given that summary of RFC 2820, I don't follow your claim that >the text from the security considerations section makes no sense. > >Chris Apple > >christopher.apple@verizon.net > >-----Original Message----- >From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] >On Behalf Of Kurt D. Zeilenga >Sent: Tuesday, March 05, 2002 11:29 PM >To: ietf-ldup@imc.org >Subject: Re: I-D ACTION:draft-ietf-ldup-replica-req-11.txt > > > >In reviewing this latest revision to see if the changes >reflect WG input, I find that the following new text in >the the Security Consideration section makes no sense. > > Security- related and general LDAP interoperability will > be significantly impacted by the degree of consistency > with which LDAP implementations support the access > control requirements [RFC2820]. > >RFC 2820 does not provide a technical specification or otherwise make >requirements upon LDAP implementations. It places requirements upon >LDAPext engineering work. That is, RFC 2820 has itself zero impact on >LDAP interoperability. > >Kurt > From owner-ietf-ldup@mail.imc.org Wed Mar 6 11:11:15 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15287 for ; Wed, 6 Mar 2002 11:11:15 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g26G09F08954 for ietf-ldup-bks; Wed, 6 Mar 2002 08:00:09 -0800 (PST) Received: from out006.verizon.net (out006pub.verizon.net [206.46.170.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g26G08808946 for ; Wed, 6 Mar 2002 08:00:08 -0800 (PST) Received: from D7ST2111 ([141.158.243.31]) by out006.verizon.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20020306155927.TCWW18285.out006.verizon.net@D7ST2111> for ; Wed, 6 Mar 2002 09:59:27 -0600 Reply-To: From: "Chris Apple" To: Subject: RE: I-D ACTION:draft-ietf-ldup-replica-req-11.txt Date: Wed, 6 Mar 2002 10:59:44 -0500 Message-ID: <004801c1c527$ef8c24a0$0200a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0049_01C1C4FE.06B61CA0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <5.1.0.14.0.20020306070921.01717508@127.0.0.1> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0049_01C1C4FE.06B61CA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The proposed re-write of the text in question doesn't add any value to the document in my opinion. Since the LDUP requirements document and RFC 2820 are both informational and are both requirements documents, I see no harm in one referring to the other in the Security Considerations section as currently written. The clarification that you are seeking to include is already well understood and I believe redundant with existing IETF process. As a co-chair, I don't feel inclined to add the language revision you propose to this document at this time. You are of course free to post such a comment in response to the IETF Last Call for the LDUP requirements document. As an example of how this language revision could be perceived as redundant with existing IETF process, keep this in mind: One potential output of the LDUP Access Control Design Team could be such a standards-track technical specification, albeit likely constrained to the minimal subset of those requirements needed to address access control relative to LDAP replication. Chris Apple christopher.apple@verizon.net -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Wednesday, March 06, 2002 10:37 AM To: christopher.apple@verizon.net Cc: ietf-ldup@imc.org Subject: RE: I-D ACTION:draft-ietf-ldup-replica-req-11.txt At 06:41 AM 2002-03-06, Chris Apple wrote: >I have read RFC 2820 5 times this morning and cannot find a statement >in it that supports your claim. Much like the LDUP Requirements I-D, RFC 2820 is NOT a protocol technical specification. It outlines design requirements which engineers of a technical specification should consider. The statement "LDAP implementations support the access control requirements [RFC2820]" makes no sense as RFC 2820 makes no requirements upon LDAP implementations. Now, the statement could be rewritten: Security- related and general LDAP interoperability will be significantly impacted by the degree of consistency with which LDAP implementations support a future Standard Track technical specification meeting Access Control Requirements for LDAP [RFC2820]. Kurt >Consider the document's abstract: > >Abstract > > This document describes the fundamental requirements of an access > control list (ACL) model for the Lightweight Directory Application > Protocol (LDAP) directory service. It is intended to be a gathering > place for access control requirements needed to provide authorized > access to and interoperability between directories. > >Given that summary of RFC 2820, I don't follow your claim that the text >from the security considerations section makes no sense. > >Chris Apple > >christopher.apple@verizon.net > >-----Original Message----- >From: owner-ietf-ldup@mail.imc.org >[mailto:owner-ietf-ldup@mail.imc.org] >On Behalf Of Kurt D. Zeilenga >Sent: Tuesday, March 05, 2002 11:29 PM >To: ietf-ldup@imc.org >Subject: Re: I-D ACTION:draft-ietf-ldup-replica-req-11.txt > > > >In reviewing this latest revision to see if the changes reflect WG >input, I find that the following new text in the the Security >Consideration section makes no sense. > > Security- related and general LDAP interoperability will > be significantly impacted by the degree of consistency > with which LDAP implementations support the access > control requirements [RFC2820]. > >RFC 2820 does not provide a technical specification or otherwise make >requirements upon LDAP implementations. It places requirements upon >LDAPext engineering work. That is, RFC 2820 has itself zero impact on >LDAP interoperability. > >Kurt > ------=_NextPart_000_0049_01C1C4FE.06B61CA0 Content-Type: text/x-vcard; name="Chris Apple (christopher.apple@verizon.net).vcf" Content-Disposition: attachment; filename="Chris Apple (christopher.apple@verizon.net).vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Apple;Christopher FN:Chris Apple (christopher.apple@verizon.net) TEL;HOME;VOICE:(215) 873-0850 TEL;CELL;VOICE:(610) 585-4241 ADR;WORK:;;214 New Street, Apt 4-N;Philadelphia;PA;19106;United States = of America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:214 New Street, Apt = 4-N=3D0D=3D0APhiladelphia, PA 19106=3D0D=3D0AUnited States of Am=3D erica EMAIL;PREF;INTERNET:christopher.apple@verizon.net REV:20011217T233830Z END:VCARD ------=_NextPart_000_0049_01C1C4FE.06B61CA0-- From owner-ietf-ldup@mail.imc.org Wed Mar 6 11:35:21 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16654 for ; Wed, 6 Mar 2002 11:35:20 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g26GOeA12106 for ietf-ldup-bks; Wed, 6 Mar 2002 08:24:40 -0800 (PST) Received: from out010.verizon.net (out010pub.verizon.net [206.46.170.133]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g26GOd812102 for ; Wed, 6 Mar 2002 08:24:39 -0800 (PST) Received: from D7ST2111 ([141.158.243.31]) by out010.verizon.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20020306162433.BWVG1279.out010.verizon.net@D7ST2111> for ; Wed, 6 Mar 2002 10:24:33 -0600 Reply-To: From: "Chris Apple" To: Subject: WG Meeting Agenda Date: Wed, 6 Mar 2002 11:24:11 -0500 Message-ID: <005f01c1c52b$59846900$0200a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0060_01C1C501.70AE6100" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0060_01C1C501.70AE6100 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Please send requests for WG agenda items directly to me. I've already received a request from Rick Huber. Chris Apple christopher.apple@verizon.net ------=_NextPart_000_0060_01C1C501.70AE6100 Content-Type: text/x-vcard; name="Chris Apple (christopher.apple@verizon.net).vcf" Content-Disposition: attachment; filename="Chris Apple (christopher.apple@verizon.net).vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Apple;Christopher FN:Chris Apple (christopher.apple@verizon.net) TEL;HOME;VOICE:(215) 873-0850 TEL;CELL;VOICE:(610) 585-4241 ADR;WORK:;;214 New Street, Apt 4-N;Philadelphia;PA;19106;United States = of America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:214 New Street, Apt = 4-N=3D0D=3D0APhiladelphia, PA 19106=3D0D=3D0AUnited States of Am=3D erica EMAIL;PREF;INTERNET:christopher.apple@verizon.net REV:20011217T233830Z END:VCARD ------=_NextPart_000_0060_01C1C501.70AE6100-- From owner-ietf-ldup@mail.imc.org Wed Mar 6 11:58:57 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18145 for ; Wed, 6 Mar 2002 11:58:56 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g26Gm7o13347 for ietf-ldup-bks; Wed, 6 Mar 2002 08:48:07 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g26Gm5813343 for ; Wed, 6 Mar 2002 08:48:05 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g26Gm6C36635; Wed, 6 Mar 2002 16:48:06 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020306082915.0301af50@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 06 Mar 2002 08:48:00 -0800 To: From: "Kurt D. Zeilenga" Subject: RE: I-D ACTION:draft-ietf-ldup-replica-req-11.txt Cc: In-Reply-To: <004801c1c527$ef8c24a0$0200a8c0@D7ST2111> References: <5.1.0.14.0.20020306070921.01717508@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 07:59 AM 2002-03-06, Chris Apple wrote: >The proposed re-write of the text in question doesn't add any value to >the document in my opinion. Since the LDUP requirements document and >RFC 2820 are both informational and are both requirements documents, I >see no harm in one referring to the other in the Security Considerations >section as currently written. > >The clarification that you are seeking to include is already well >understood and I believe redundant with existing IETF process. I disagree. Some will read that statement as imply that there is already an LDAP ACM technical specifications which LDAP implementations can support. As this is a security consideration, I believe it needs to be clear that it is referring to a future technical specification which meets the requirements stated in RFC 2820. >As a co-chair, I don't feel inclined to add the language revision you >propose to this document at this time. Well, I'm inclined to disagree with you. The editor has made a substantive changes to the I-D. Regardless of what they were in response to, this WG must be given an opportunity to review those changes. If the WG does not agree with the changes, the document must be changed to reflect the WG consensus. Given that the WG has yet been given an opportunity to review these changes, I think it is premature for you to declare consensus in regards to these changes. I certainly have not had time to review all the changes made, the document revision was only recently announced. I recommend you give the working group two weeks to review the recent changes and comment. >One potential output of the LDUP Access Control Design Team could be >such >a standards-track technical specification, I do not believe the LDUP Access Control Design Team is presently chartered to undertake engineering of any technical specification. If I am mistaken, please advise. Kurt From owner-ietf-ldup@mail.imc.org Wed Mar 6 12:38:22 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21022 for ; Wed, 6 Mar 2002 12:38:22 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g26HS0o14552 for ietf-ldup-bks; Wed, 6 Mar 2002 09:28:00 -0800 (PST) Received: from out016.verizon.net (out016pub.verizon.net [206.46.170.92]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g26HRx814548 for ; Wed, 6 Mar 2002 09:27:59 -0800 (PST) Received: from D7ST2111 ([141.158.243.31]) by out016.verizon.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20020306172755.OPKL28131.out016.verizon.net@D7ST2111> for ; Wed, 6 Mar 2002 11:27:55 -0600 Reply-To: From: "Chris Apple" To: Subject: RE: I-D ACTION:draft-ietf-ldup-replica-req-11.txt Date: Wed, 6 Mar 2002 12:27:30 -0500 Message-ID: <006b01c1c534$32499960$0200a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_006C_01C1C50A.49739160" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <5.1.0.14.0.20020306082915.0301af50@127.0.0.1> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_006C_01C1C50A.49739160 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit >From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] >Sent: Wednesday, March 06, 2002 11:48 AM >To: christopher.apple@verizon.net >Cc: ietf-ldup@imc.org >Subject: RE: I-D ACTION:draft-ietf-ldup-replica-req-11.txt >>At 07:59 AM 2002-03-06, Chris Apple wrote: >>The proposed re-write of the text in question doesn't add any value to >>the document in my opinion. Since the LDUP requirements document and >>RFC 2820 are both informational and are both requirements documents, I >>see no harm in one referring to the other in the Security >>Considerations section as currently written. >> >>The clarification that you are seeking to include is already well >>understood and I believe redundant with existing IETF process. >I disagree. Some will read that statement as imply that there is already an LDAP ACM technical specifications which LDAP implementations can support. As this is a security consideration, I believe it needs to be clear that it is referring to a future technical specification which meets the requirements stated in RFC 2820. >>As a co-chair, I don't feel inclined to add the language revision you >>propose to this document at this time. >Well, I'm inclined to disagree with you. The editor has made a substantive changes to the I-D. Regardless of what they were in response to, this WG must be given an opportunity to review those changes. If the WG does not agree with the changes, the document must be changed to reflect the WG consensus. >Given that the WG has yet been given an opportunity to review these changes, I think it is premature for you to declare consensus in regards to these changes. That wasn't a declaration of consensus - that was a process call on my part. I don't think its appropriate to add language to a requirements document that is redundant with IETF process. I do believe its OK to add language that *refers* to IETF Process but personally find the value in doing so to be marginal. Your language proposal appears to me to be redundant with IETF process rather than referring to it. WG members could establish a consensus otherwise - and that would indeed require discussion about the topic on the list. I'm watching... >I certainly have not had time to review all the changes made, the document revision was only recently announced. I recommend you give the working group two weeks to review the recent changes and comment. I consider WG review of changes made to the document to have started today. 2 weeks sounds like a reasonable interval to me. >>One potential output of the LDUP Access Control Design Team could be >>such a standards-track technical specification, >I do not believe the LDUP Access Control Design Team is presently chartered to undertake engineering of any technical specification. If I am mistaken, please advise. >Kurt Per my earlier postings on this topic and pending the meeting the Design Team will have this week, the "charter" for the Design Team will be presented during the LDUP WG meeting as a proposal. For now and until the WG establishes consensus on the LDUP Access Control Design Team "charter" proposal, the Design Team's "charter" is to devise a terse mission statement, draft work program, and present both to the WG. One *possible* outcome from the Design Team's presentation to the WG could be that the WG establishes consensus that certain technical specifications related to Access Control be written by the Design Team members and presented to the WG for consideration. Please note my use of the word "potential" in the original posting. The statement in my original posting on this topic is consistent with my prior postings on the topic of LDUP Access Control Design Team "charter." Chris. ------=_NextPart_000_006C_01C1C50A.49739160 Content-Type: text/x-vcard; name="Chris Apple (christopher.apple@verizon.net).vcf" Content-Disposition: attachment; filename="Chris Apple (christopher.apple@verizon.net).vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Apple;Christopher FN:Chris Apple (christopher.apple@verizon.net) TEL;HOME;VOICE:(215) 873-0850 TEL;CELL;VOICE:(610) 585-4241 ADR;WORK:;;214 New Street, Apt 4-N;Philadelphia;PA;19106;United States = of America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:214 New Street, Apt = 4-N=3D0D=3D0APhiladelphia, PA 19106=3D0D=3D0AUnited States of Am=3D erica EMAIL;PREF;INTERNET:christopher.apple@verizon.net REV:20011217T233830Z END:VCARD ------=_NextPart_000_006C_01C1C50A.49739160-- From owner-ietf-ldup@mail.imc.org Wed Mar 6 13:24:47 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24553 for ; Wed, 6 Mar 2002 13:24:46 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g26IESM17518 for ietf-ldup-bks; Wed, 6 Mar 2002 10:14:28 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g26IEQ817511 for ; Wed, 6 Mar 2002 10:14:26 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g26IENC37129; Wed, 6 Mar 2002 18:14:23 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020306101054.01717710@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 06 Mar 2002 10:14:17 -0800 To: From: "Kurt D. Zeilenga" Subject: design teams (RE: I-D ACTION:draft-ietf-ldup-replica-req-11.txt) Cc: In-Reply-To: <006b01c1c534$32499960$0200a8c0@D7ST2111> References: <5.1.0.14.0.20020306082915.0301af50@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Well, the problem I have is that you seem to have formed one design team to address multiple issues, some which are not yet relevant to the WG. I think it would be better to charter one team to address "to devise a terse mission statement, draft work program, and present both to the WG" and, if accepted by WG consensus AND approved by the IESG, form a second design team to address subsequent issues. Kurt From owner-ietf-ldup@mail.imc.org Wed Mar 6 13:46:36 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26670 for ; Wed, 6 Mar 2002 13:46:35 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g26Ia2W18316 for ietf-ldup-bks; Wed, 6 Mar 2002 10:36:02 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g26Ia1818312 for ; Wed, 6 Mar 2002 10:36:01 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g26Ia1C37259; Wed, 6 Mar 2002 18:36:01 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020306101825.0303a008@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 06 Mar 2002 10:35:55 -0800 To: From: "Kurt D. Zeilenga" Subject: RE: I-D ACTION:draft-ietf-ldup-replica-req-11.txt Cc: In-Reply-To: <006b01c1c534$32499960$0200a8c0@D7ST2111> References: <5.1.0.14.0.20020306082915.0301af50@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 09:27 AM 2002-03-06, Chris Apple wrote: >That wasn't a declaration of consensus - that was a process call on my >part. I don't think its appropriate to >add language to a requirements document that is redundant with IETF >process. I do believe its OK to add language >that *refers* to IETF Process but personally find the value in doing so >to be marginal. Your language proposal >appears to me to be redundant with IETF process rather than referring to >it. I don't see how my clarification is redundant to IETF process. My suggestion is intended to clarify the meaning of the statement. As it written, it implies that RFC 2820 is a technical specification which LDAP implementations can support and if they do so the security consideration is addressed. However, as RFC 2820 places no requirements on LDAP implementations and hence whether implementations support it or not has no impact on the underlying security consideration. With my clarification, statement would implies that the security consideration is addressed by LDAP implementations supporting a future LDAP ACM technical specification. Kurt From owner-ietf-ldup@mail.imc.org Wed Mar 6 15:36:38 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04087 for ; Wed, 6 Mar 2002 15:36:38 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g26KS3321607 for ietf-ldup-bks; Wed, 6 Mar 2002 12:28:03 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g26KS2821603 for ; Wed, 6 Mar 2002 12:28:02 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g26KRvC38011; Wed, 6 Mar 2002 20:27:57 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020306121311.02fedc90@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 06 Mar 2002 12:27:51 -0800 To: "Ed Reed" From: "Kurt D. Zeilenga" Subject: Re: Open issues / questions re: Architecture of LDUP Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 06:34 AM 2002-03-06, Ed Reed wrote: > >Maybe it's early in the AM, Kurt, but I'm unsure as to your meaning... > >In the LDUP information model, we use subentries in several places... > >a) as the definition of the "area of replication" associated with an >LDUP administration point, >b) as the specification of the contents (may be either the same >set or a subset of the one defined for the "area of replication") >held by a particular replica on a particular server, and >c) as the set (may be either the same or a subset of the one >defined for the supplier replica) of entries about >which change information is to flow along a particular replication >agreement between two (or possibly more, tbd) particular replicas. > >Which of those do you mean in your remarks?? Let me try to clarify. A set of entries can be said to be within scope of a subentry. This set is determined both by placement of the subentry and the attributes of the subentry, such as the subtreeSpecification attribute. I suggest that it this distinct set of entries which are to replicated in accordance with other attributes of this subentry. The set of entries is all those entries which form a subtree or subtree refinement. If the latter, then the set of entries can be said to be sparse. If one uses the requirements definition of an area of replication "A whole or portion of a Directory Information Tree (DIT) that makes up a distinct unit of data to be replicated." Then it can be said that the area of replication is that which is defined by the replica subentry and comprises all entries which are within scope of the subentry. I haven't had enough coca cola yet to equate this to a, b, or c. :-) Kurt From owner-ietf-ldup@mail.imc.org Wed Mar 6 16:48:40 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08485 for ; Wed, 6 Mar 2002 16:48:39 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g26LbKr23580 for ietf-ldup-bks; Wed, 6 Mar 2002 13:37:20 -0800 (PST) Received: from out001.verizon.net (out001slb.verizon.net [206.46.170.13] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g26LbJ823576 for ; Wed, 6 Mar 2002 13:37:19 -0800 (PST) Received: from D7ST2111 ([141.158.247.90]) by out001.verizon.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20020306213714.BENI27556.out001.verizon.net@D7ST2111> for ; Wed, 6 Mar 2002 15:37:14 -0600 Reply-To: From: "Chris Apple" To: Subject: RE: design teams (RE: I-D ACTION:draft-ietf-ldup-replica-req-11.txt) Date: Wed, 6 Mar 2002 16:36:47 -0500 Message-ID: <003801c1c557$0712e530$0200a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0039_01C1C52D.1E3E63D0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <5.1.0.14.0.20020306101054.01717710@127.0.0.1> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0039_01C1C52D.1E3E63D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In my postings, I've made it progressively more clear that the Design Team is chartered in the short term to do what you propose for an initial design team below. I have also made it clear that whether or not this same Design Team goes on to do additional work will be left to Working Group consensus. I suppose it is possible that the Design Team's membership will change drastically and therefore effectively become a "second design team." But I don't think it would be prudent of me to pre-judge working group consensus on this matter by explicitly stating that a second design team will be formed. I have based my strategy for addressing access control for LDUP on my own interpretation of how to use design teams as a means of addressing controversial or contentious issues. I am assuming that your text below represents your interpretation of the same. We obviously differ in opinion about how explicit we need to be about what happens after the Design Team completes their initial work - which may *or* may not turn out to be their final input to the WG. As the co-chair, I'm making a choice about being explicit about the initial deliverable to the WG. Whether that same Design Team goes on to do more work as an entity, dissolves, changes membership, etc. is a matter that, as co-chair, I would like to have the WG consider once we have a concrete proposal that we can discuss. The above is consistent with my prior postings on this topic. Chris Apple christopher.apple@verizon.net -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Wednesday, March 06, 2002 1:14 PM To: christopher.apple@verizon.net Cc: ietf-ldup@imc.org Subject: design teams (RE: I-D ACTION:draft-ietf-ldup-replica-req-11.txt) Well, the problem I have is that you seem to have formed one design team to address multiple issues, some which are not yet relevant to the WG. I think it would be better to charter one team to address "to devise a terse mission statement, draft work program, and present both to the WG" and, if accepted by WG consensus AND approved by the IESG, form a second design team to address subsequent issues. Kurt ------=_NextPart_000_0039_01C1C52D.1E3E63D0 Content-Type: text/x-vcard; name="Chris Apple (christopher.apple@verizon.net).vcf" Content-Disposition: attachment; filename="Chris Apple (christopher.apple@verizon.net).vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Apple;Christopher FN:Chris Apple (christopher.apple@verizon.net) TEL;HOME;VOICE:(215) 873-0850 TEL;CELL;VOICE:(610) 585-4241 ADR;WORK:;;214 New Street, Apt 4-N;Philadelphia;PA;19106;United States = of America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:214 New Street, Apt = 4-N=3D0D=3D0APhiladelphia, PA 19106=3D0D=3D0AUnited States of Am=3D erica EMAIL;PREF;INTERNET:christopher.apple@verizon.net REV:20011217T233830Z END:VCARD ------=_NextPart_000_0039_01C1C52D.1E3E63D0-- From owner-ietf-ldup@mail.imc.org Wed Mar 6 17:41:38 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12378 for ; Wed, 6 Mar 2002 17:41:37 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g26MXcd24983 for ietf-ldup-bks; Wed, 6 Mar 2002 14:33:38 -0800 (PST) Received: from out018.verizon.net (out018pub.verizon.net [206.46.170.96]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g26MXb824979 for ; Wed, 6 Mar 2002 14:33:37 -0800 (PST) Received: from D7ST2111 ([141.158.247.90]) by out018.verizon.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20020306223334.BJYT20881.out018.verizon.net@D7ST2111> for ; Wed, 6 Mar 2002 16:33:34 -0600 Reply-To: From: "Chris Apple" To: Subject: RE: I-D ACTION:draft-ietf-ldup-replica-req-11.txt Date: Wed, 6 Mar 2002 17:33:08 -0500 Message-ID: <004801c1c55e$e46449e0$0200a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0049_01C1C534.FB8E41E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <5.1.0.14.0.20020306101825.0303a008@127.0.0.1> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0049_01C1C534.FB8E41E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Your clarification describes the way that the IETF typically uses requirements documents - as input/design considerations for creating Standards Track specifications. To me, that's what makes it redundant. This is typically the way that the IETF uses requirements documents, so I personally see no point in expressing that explicitly in a requirements document. Your clarification also presumes that further work on LDAP Access Control will place in the IETF. Based on how contentious the topic of Access Control for LDAP and LDUP have been to date, I am not convinced that the additional technical specifications you mention will actually be developed within the IETF even if their notions are conceived here. This is precisely why I keep leaving the LDUP Access control Design Team's "charter" a little open-ended. I want to leave room for such work to take place if they can come up with a viable approach (e.g., an approach that the WG members achieve consensus on as being viable for the Design Team to execute). I will most certainly dissolve that design team if and when it becomes obvious that this is not possible. I do not agree with your statement about what the requirement implies. The requirement as worded implies that it is the consistency with which different implementations support the requirements documented in RFC 2820 that impacts the level of interoperability that you can expect between LDAP systems from both a security and a general perspective. If two implementations do claim to support those requirements, it will be the degree of consistency in supporting them that makes or breaks interoperability from a security perspective. That implication doesn't require clarification in my opinion. Whether work towards any additional required technical specifications on which those claims are based takes place in the IETF, an industry consortia group, or by private interoperability agreements/testing between LDAP/LDUP implementers, remains to be seen. And even though I'd prefer that it be handled within the IETF, I don't know how that's going to go down so to speak. That is a topic that the LDUP Access Control Design Team will have to consider during construction of its proposal to the WG. There was some discussion at the last WG meeting related to how feasible it was going to be to have a generalized LDAP ACM standard period. Largely because of that discussion, I don't want to presume what the design team will produce. They could very well produce alternate work programs for the WG to consider - one of which could be "do nothing in the IETF." As co-chair, I don't want to *prematurely* put language in a requirements document attempting to constrain that path only to have it: A) Not subsequently happen in the IETF. AND/OR B) Have to change the document should the work take place outside of the IETF, when such a change could be avoided by simply not making the clarification that you propose. And while I don't see it to be of added value to the document, I would personally support your clarification if it indeed corresponds to the LDUP Access Control Design Team proposal/recommendation on which the WG achieves consensus (in the interest of moving the document forward). I believe you and I have had our say on this matter. Its time for others to chime in... Chris Apple christopher.apple@verizon.net -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] On Behalf Of Kurt D. Zeilenga Sent: Wednesday, March 06, 2002 1:36 PM To: christopher.apple@verizon.net Cc: ietf-ldup@imc.org Subject: RE: I-D ACTION:draft-ietf-ldup-replica-req-11.txt At 09:27 AM 2002-03-06, Chris Apple wrote: >That wasn't a declaration of consensus - that was a process call on my >part. I don't think its appropriate to add language to a requirements >document that is redundant with IETF process. I do believe its OK to >add language that *refers* to IETF Process but personally find the >value in doing so to be marginal. Your language proposal >appears to me to be redundant with IETF process rather than referring to >it. I don't see how my clarification is redundant to IETF process. My suggestion is intended to clarify the meaning of the statement. As it written, it implies that RFC 2820 is a technical specification which LDAP implementations can support and if they do so the security consideration is addressed. However, as RFC 2820 places no requirements on LDAP implementations and hence whether implementations support it or not has no impact on the underlying security consideration. With my clarification, statement would implies that the security consideration is addressed by LDAP implementations supporting a future LDAP ACM technical specification. Kurt ------=_NextPart_000_0049_01C1C534.FB8E41E0 Content-Type: text/x-vcard; name="Chris Apple (christopher.apple@verizon.net).vcf" Content-Disposition: attachment; filename="Chris Apple (christopher.apple@verizon.net).vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Apple;Christopher FN:Chris Apple (christopher.apple@verizon.net) TEL;HOME;VOICE:(215) 873-0850 TEL;CELL;VOICE:(610) 585-4241 ADR;WORK:;;214 New Street, Apt 4-N;Philadelphia;PA;19106;United States = of America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:214 New Street, Apt = 4-N=3D0D=3D0APhiladelphia, PA 19106=3D0D=3D0AUnited States of Am=3D erica EMAIL;PREF;INTERNET:christopher.apple@verizon.net REV:20011217T233830Z END:VCARD ------=_NextPart_000_0049_01C1C534.FB8E41E0-- From owner-ietf-ldup@mail.imc.org Wed Mar 6 19:06:49 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16834 for ; Wed, 6 Mar 2002 19:06:49 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g26NwIb27225 for ietf-ldup-bks; Wed, 6 Mar 2002 15:58:18 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g26NwG827221 for ; Wed, 6 Mar 2002 15:58:16 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g26NwIC39153; Wed, 6 Mar 2002 23:58:18 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020306154441.030be960@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 06 Mar 2002 15:58:12 -0800 To: From: "Kurt D. Zeilenga" Subject: LDAP ACM in security considerations (RE: I-D ACTION:draft-ietf-ldup-replica-req-11.txt) Cc: In-Reply-To: <004801c1c55e$e46449e0$0200a8c0@D7ST2111> References: <5.1.0.14.0.20020306101825.0303a008@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 02:33 PM 2002-03-06, Chris Apple wrote: >As co-chair, I don't want to *prematurely* put language in a >requirements >document attempting to constrain that path only to have it: This is actually what is being done by placing a reference to RFC 2820. The statement presumed that there eventually would be a technical specification meeting RFC 2820 requirements which LDAP implementations could support just as previous revisions had presumed LDAPext would have produced an standard track LDAP ACM. A statement stating that a standard LDAP access control model is needed, without stating any requirements upon that standard LDAP access control model, would be less premature. Something like: This document includes security requirements (listed in section 4.8 above) for the replication model and protocol. As noted in Section 3, interoperability may be impacted when replicating among servers that implement non-standard extensions to basic LDAP semantics. Security- related and general LDAP interoperability will be significantly impacted by the degree of consistency with which implementations a future standard LDAP access control model. This statement should not be limited our path. That is, the statement is valid whether or not we take on this "future standard LDAP access control model" or not. From owner-ietf-ldup@mail.imc.org Thu Mar 7 07:09:28 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19097 for ; Thu, 7 Mar 2002 07:09:27 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g27BvmW17934 for ietf-ldup-bks; Thu, 7 Mar 2002 03:57:48 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g27Bvl817929 for ; Thu, 7 Mar 2002 03:57:47 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18332; Thu, 7 Mar 2002 06:57:45 -0500 (EST) Message-Id: <200203071157.GAA18332@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldup-model-07.txt Date: Thu, 07 Mar 2002 06:57:45 -0500 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF. Title : LDAP Replication Architecture Author(s) : E. Reed, U. Srinivasan Filename : draft-ietf-ldup-model-07.txt Pages : 35 Date : 06-Mar-02 This architectural document outlines a suite of schema and protocol extensions to LDAPv3 that enables the robust, reliable, server-to- server exchange of directory content and changes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldup-model-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldup-model-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020306143650.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-model-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-model-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020306143650.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Mon Mar 11 12:21:48 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15994 for ; Mon, 11 Mar 2002 12:21:48 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2BHBOr17439 for ietf-ldup-bks; Mon, 11 Mar 2002 09:11:24 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2BHBN817432 for ; Mon, 11 Mar 2002 09:11:23 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g2BHBJC68812; Mon, 11 Mar 2002 17:11:19 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020311090430.021dd3c0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 11 Mar 2002 09:11:40 -0800 To: From: "Kurt D. Zeilenga" Subject: Re: LDAP ACM in security considerations (RE: I-D ACTION:draft-ietf-ldup-replica-req-11.txt) Cc: In-Reply-To: <5.1.0.14.0.20020306154441.030be960@127.0.0.1> References: <004801c1c55e$e46449e0$0200a8c0@D7ST2111> <5.1.0.14.0.20020306101825.0303a008@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As noted in previous discussions, the access control model is only one of the security models which impacts the replication. To address this, I suggest the security consideration section be replaced with: This document includes security requirements (listed in section 4.8 above) for the replication model and protocol. As noted in Section 3, interoperability may be impacted when replicating among servers that implement non-standard extensions to basic LDAP semantics. Security- related and general LDAP interoperability will be significantly impacted by the degree of consistency with which implementations existing and future standards detailing LDAP security models, such as a future standard access control model. Other future standard security models could be listed as well, but one example is sufficient. Kurt From owner-ietf-ldup@mail.imc.org Mon Mar 11 14:08:18 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19528 for ; Mon, 11 Mar 2002 14:08:17 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2BIxhq21762 for ietf-ldup-bks; Mon, 11 Mar 2002 10:59:43 -0800 (PST) Received: from cosium01.intelliden.net (cosium01.intelliden.net [12.41.186.248]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2BIxg821758 for ; Mon, 11 Mar 2002 10:59:42 -0800 (PST) Received: by cosium01.intelliden.net with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Mar 2002 11:59:28 -0700 Message-ID: From: John Strassner To: "'Kurt D. Zeilenga'" , christopher.apple@verizon.net Cc: ietf-ldup@imc.org Subject: RE: LDAP ACM in security considerations (RE: I-D ACTION:draft-iet f-ldup-replica-req-11.txt) Date: Mon, 11 Mar 2002 11:59:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C92E.DEB420F0" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1C92E.DEB420F0 Content-Type: text/plain Kurt, The text that you changed doesn't make sense. Here it is again: Security- related and general LDAP interoperability will be significantly impacted by the degree of consistency with which implementations existing and future standards detailing LDAP security models, such as a future standard access control model. Please rewrite just this part. regards, John John Strassner Chief Strategy Officer Intelliden Corporation 90 South Cascade Avenue Colorado Springs, CO 80903 USA phone: +1.719.785.0648 FAX: +1.719.785.0644 email: john.strassner@intelliden.com -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Monday, March 11, 2002 10:12 AM To: christopher.apple@verizon.net Cc: ietf-ldup@imc.org Subject: Re: LDAP ACM in security considerations (RE: I-D ACTION:draft-ietf-ldup-replica-req-11.txt) As noted in previous discussions, the access control model is only one of the security models which impacts the replication. To address this, I suggest the security consideration section be replaced with: This document includes security requirements (listed in section 4.8 above) for the replication model and protocol. As noted in Section 3, interoperability may be impacted when replicating among servers that implement non-standard extensions to basic LDAP semantics. Security- related and general LDAP interoperability will be significantly impacted by the degree of consistency with which implementations existing and future standards detailing LDAP security models, such as a future standard access control model. Other future standard security models could be listed as well, but one example is sufficient. Kurt ------_=_NextPart_001_01C1C92E.DEB420F0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Kurt,

The text that you changed doesn't make sense. Here it is = again:

 

  = Security- related and

  = general LDAP interoperability will be = significantly impacted

  = by the degree of consistency with which = implementations

  = existing and future standards detailing LDAP = security

  = models, such as a future standard access control = model.

 

Please rewrite just this part.

 

regards,

John

 

John Strassner

Chief Strategy = Officer

Intelliden = Corporation

90 South Cascade = Avenue

Colorado Springs, CO  80903  = USA

phone: = +1.719.785.0648

  = FAX: +1.719.785.0644

email: john.strassner@intelliden.com =

 

 

-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Monday, March 11, 2002 10:12 AM
To: christopher.apple@verizon.net
Cc: ietf-ldup@imc.org
Subject: Re: LDAP ACM in security considerations (RE: I-D ACTION:draft-ietf-ldup-replica-req-11.txt)

 

 

As noted in previous discussions, the access control = model

is only one of the security models which impacts = the

replication.  To = address this, I suggest the security

consideration section be replaced = with:

 

  This document = includes security requirements (listed in

  section 4.8 = above) for the replication model and protocol. As

  noted in Section = 3, interoperability may be impacted when

  replicating = among servers that implement non-standard

  extensions to = basic LDAP semantics. Security- related and

  general LDAP = interoperability will be significantly impacted

  by the degree of = consistency with which implementations

  existing and = future standards detailing LDAP security

  models, such as = a future standard access control model.

 

Other future standard security models could be listed = as

well, but one example is = sufficient.

 

Kurt

------_=_NextPart_001_01C1C92E.DEB420F0-- From owner-ietf-ldup@mail.imc.org Mon Mar 11 14:15:09 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19748 for ; Mon, 11 Mar 2002 14:15:09 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2BJ7cD22189 for ietf-ldup-bks; Mon, 11 Mar 2002 11:07:38 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2BJ7b822185 for ; Mon, 11 Mar 2002 11:07:37 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g2BJ7cC69268; Mon, 11 Mar 2002 19:07:38 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020311110505.0222ee38@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 11 Mar 2002 11:07:59 -0800 To: From: "Kurt D. Zeilenga" Subject: Re: LDAP ACM in security considerations (RE: I-D ACTION:draft-ietf-ldup-replica-req-11.txt) Cc: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [revised to fix typos] As noted in previous discussions, the access control model is only one of the security models which impacts the replication. To address this, I suggest the security consideration section be replaced with: This document includes security requirements (listed in section 4.8 above) for the replication model and protocol. As noted in Section 3, interoperability may be impacted when replicating among servers that implement non-standard extensions to basic LDAP semantics. Security- related and general LDAP interoperability will be significantly impacted by the degree of consistency with which implementations support existing and future standards detailing LDAP security models, such as a future standard LDAP access control model. Other future standard security models could be listed as well, but one example is sufficient. Kurt From owner-ietf-ldup@mail.imc.org Mon Mar 11 14:45:18 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20544 for ; Mon, 11 Mar 2002 14:45:18 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2BJaSS24150 for ietf-ldup-bks; Mon, 11 Mar 2002 11:36:28 -0800 (PST) Received: from cosium01.intelliden.net (cosium01.intelliden.net [12.41.186.248]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2BJaR824143 for ; Mon, 11 Mar 2002 11:36:27 -0800 (PST) Received: by cosium01.intelliden.net with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Mar 2002 12:36:24 -0700 Message-ID: From: John Strassner To: "'Kurt D. Zeilenga'" , christopher.apple@verizon.net Cc: ietf-ldup@imc.org Subject: RE: LDAP ACM in security considerations (RE: I-D ACTION:draft-iet f-ldup-replica-req-11.txt) Date: Mon, 11 Mar 2002 12:36:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C934.06FE3550" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1C934.06FE3550 Content-Type: text/plain Thanks Kurt for the revised text. Replica Requirements authors, could you please talk amongst yourselves ;-) and reply with a united "Yes, we love this text" or "No, we don't" please? LDUPers, could you also please think about the suggested text and weigh in with your votes please? regards, John Strassner co-chair, LDUP -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Monday, March 11, 2002 12:08 PM To: christopher.apple@verizon.net Cc: ietf-ldup@imc.org Subject: Re: LDAP ACM in security considerations (RE: I-D ACTION:draft-ietf-ldup-replica-req-11.txt) [revised to fix typos] As noted in previous discussions, the access control model is only one of the security models which impacts the replication. To address this, I suggest the security consideration section be replaced with: This document includes security requirements (listed in section 4.8 above) for the replication model and protocol. As noted in Section 3, interoperability may be impacted when replicating among servers that implement non-standard extensions to basic LDAP semantics. Security- related and general LDAP interoperability will be significantly impacted by the degree of consistency with which implementations support existing and future standards detailing LDAP security models, such as a future standard LDAP access control model. Other future standard security models could be listed as well, but one example is sufficient. Kurt ------_=_NextPart_001_01C1C934.06FE3550 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: LDAP ACM in security considerations (RE: I-D = ACTION:draft-ietf-ldup-replica-req-11.txt)

Thanks Kurt for the revised text.
Replica Requirements authors, could you please talk = amongst yourselves ;-) and reply with a united "Yes, we love this = text" or "No, we don't" please?

LDUPers, could you also please think about the = suggested text and weigh in with your votes please?

regards,
John Strassner
co-chair, LDUP

-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Monday, March 11, 2002 12:08 PM
To: christopher.apple@verizon.net
Cc: ietf-ldup@imc.org
Subject: Re: LDAP ACM in security considerations = (RE: I-D ACTION:draft-ietf-ldup-replica-req-11.txt)


[revised to fix typos]

As noted in previous discussions, the access control = model
is only one of the security models which impacts = the
replication.  To address this, I suggest the = security
consideration section be replaced with:

  This document includes security requirements = (listed in
  section 4.8 above) for the replication model = and protocol. As
  noted in Section 3, interoperability may be = impacted when
  replicating among servers that implement = non-standard
  extensions to basic LDAP semantics. Security- = related and
  general LDAP interoperability will be = significantly impacted
  by the degree of consistency with which = implementations
  support existing and future standards = detailing LDAP security
  models, such as a future standard LDAP access = control model.

Other future standard security models could be listed = as
well, but one example is sufficient.

Kurt

------_=_NextPart_001_01C1C934.06FE3550-- From owner-ietf-ldup@mail.imc.org Mon Mar 11 16:13:12 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24657 for ; Mon, 11 Mar 2002 16:13:11 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2BL4sn27693 for ietf-ldup-bks; Mon, 11 Mar 2002 13:04:54 -0800 (PST) Received: from inet-mail1.oracle.com (inet-mail1.oracle.com [148.87.2.201]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2BL4s827689 for ; Mon, 11 Mar 2002 13:04:54 -0800 (PST) Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14]) by inet-mail1.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g2BL4sg09818; Mon, 11 Mar 2002 13:04:54 -0800 (PST) Received: from usrinivalap (dhcp-east-2op6-7-130-35-51-85.us.oracle.com [130.35.51.85]) by rgmgw5.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with SMTP id g2BL4ra10452; Mon, 11 Mar 2002 14:04:54 -0700 (MST) Message-ID: <051f01c1c93f$c9f84c20$55332382@us.oracle.com> From: "Uppili Srinivasan" To: "John Strassner" , "'Kurt D. Zeilenga'" , Cc: References: Subject: Re: LDAP ACM in security considerations (RE: I-D ACTION:draft-ietf-ldup-replica-req-11.txt) Date: Mon, 11 Mar 2002 13:00:34 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_051C_01C1C8FC.BB457650" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_051C_01C1C8FC.BB457650 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: LDAP ACM in security considerations (RE: I-D = ACTION:draft-ietf-ldup-replica-req-11.txt)"love it"=20 ----- Original Message -----=20 From: John Strassner=20 To: 'Kurt D. Zeilenga' ; christopher.apple@verizon.net=20 Cc: ietf-ldup@imc.org=20 Sent: Monday, March 11, 2002 11:36 AM Subject: RE: LDAP ACM in security considerations (RE: I-D = ACTION:draft-ietf-ldup-replica-req-11.txt) Thanks Kurt for the revised text.=20 Replica Requirements authors, could you please talk amongst yourselves = ;-) and reply with a united "Yes, we love this text" or "No, we don't" = please? LDUPers, could you also please think about the suggested text and = weigh in with your votes please?=20 regards,=20 John Strassner=20 co-chair, LDUP=20 -----Original Message-----=20 From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]=20 Sent: Monday, March 11, 2002 12:08 PM=20 To: christopher.apple@verizon.net=20 Cc: ietf-ldup@imc.org=20 Subject: Re: LDAP ACM in security considerations (RE: I-D = ACTION:draft-ietf-ldup-replica-req-11.txt)=20 [revised to fix typos]=20 As noted in previous discussions, the access control model=20 is only one of the security models which impacts the=20 replication. To address this, I suggest the security=20 consideration section be replaced with:=20 This document includes security requirements (listed in=20 section 4.8 above) for the replication model and protocol. As=20 noted in Section 3, interoperability may be impacted when=20 replicating among servers that implement non-standard=20 extensions to basic LDAP semantics. Security- related and=20 general LDAP interoperability will be significantly impacted=20 by the degree of consistency with which implementations=20 support existing and future standards detailing LDAP security=20 models, such as a future standard LDAP access control model.=20 Other future standard security models could be listed as=20 well, but one example is sufficient.=20 Kurt=20 ------=_NextPart_000_051C_01C1C8FC.BB457650 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: LDAP ACM in security considerations (RE: I-D = ACTION:draft-ietf-ldup-replica-req-11.txt)
"love it"
----- Original Message -----
From:=20 John Strassner =
To: 'Kurt D. Zeilenga' ; christopher.apple@verizon.n= et=20
Sent: Monday, March 11, 2002 = 11:36=20 AM
Subject: RE: LDAP ACM in = security=20 considerations (RE: I-D = ACTION:draft-ietf-ldup-replica-req-11.txt)

Thanks Kurt for the revised text.
Replica Requirements authors, could you please talk amongst = yourselves=20 ;-) and reply with a united "Yes, we love this text" or "No, we don't" = please?

LDUPers, could you also please think about the = suggested text=20 and weigh in with your votes please?

regards,
John = Strassner=20
co-chair, LDUP

-----Original Message-----
From: Kurt=20 D. Zeilenga [mailto:Kurt@OpenLDAP.org]=20
Sent: Monday, March 11, 2002 12:08 PM =
To: christopher.apple@verizon.n= et=20
Cc: ietf-ldup@imc.org =
Subject: Re: LDAP ACM in security considerations (RE: I-D=20 ACTION:draft-ietf-ldup-replica-req-11.txt)


[revised to fix typos]

As noted in previous discussions, the access control = model
is only one of the security models = which impacts=20 the
replication.  To address this, I = suggest the=20 security
consideration section be replaced=20 with:

  This document includes security requirements = (listed=20 in
  section 4.8 above) for the = replication model=20 and protocol. As
  noted in Section 3,=20 interoperability may be impacted when
  = replicating among servers that implement non-standard
  extensions to basic LDAP semantics. Security- related = and=20
  general LDAP interoperability will be = significantly=20 impacted
  by the degree of consistency = with=20 which implementations
  support = existing and=20 future standards detailing LDAP security
 =20 models, such as a future standard LDAP access control model. =

Other future standard security models could be = listed=20 as
well, but one example is = sufficient.

Kurt

------=_NextPart_000_051C_01C1C8FC.BB457650-- From owner-ietf-ldup@mail.imc.org Tue Mar 12 20:08:35 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14009 for ; Tue, 12 Mar 2002 20:08:34 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2D0vXl01768 for ietf-ldup-bks; Tue, 12 Mar 2002 16:57:33 -0800 (PST) Received: from out008.verizon.net (out008pub.verizon.net [206.46.170.108]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2D0vW401764 for ; Tue, 12 Mar 2002 16:57:32 -0800 (PST) Received: from D7ST2111 ([141.158.246.61]) by out008.verizon.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20020313005728.FGPC2959.out008.verizon.net@D7ST2111> for ; Tue, 12 Mar 2002 18:57:28 -0600 Reply-To: From: "Chris Apple" To: Subject: WG Agenda Date: Tue, 12 Mar 2002 19:57:19 -0500 Message-ID: <002601c1ca2a$06e913e0$0200a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0027_01C1CA00.1E130BE0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0027_01C1CA00.1E130BE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I've received no responses to the request for WG agenda items. I did receive prior request from Rick Huber for a slot. I'll line up the usual agenda with I-D names. Will also be adding items for: + Agenda Bashing + LDUP Access Control Design Team Status + WG Charter Discussion Any other items to add? Its due by 12 Noon ET Wednesday, 3/13/2002 and will be posted to the mailing list at the same time as it is sent to the Secretariat. Chris Apple christopher.apple@verizon.net ------=_NextPart_000_0027_01C1CA00.1E130BE0 Content-Type: text/x-vcard; name="Chris Apple (christopher.apple@verizon.net).vcf" Content-Disposition: attachment; filename="Chris Apple (christopher.apple@verizon.net).vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Apple;Christopher FN:Chris Apple (christopher.apple@verizon.net) TEL;HOME;VOICE:(215) 873-0850 TEL;CELL;VOICE:(610) 585-4241 ADR;WORK:;;214 New Street, Apt 4-N;Philadelphia;PA;19106;United States = of America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:214 New Street, Apt = 4-N=3D0D=3D0APhiladelphia, PA 19106=3D0D=3D0AUnited States of Am=3D erica EMAIL;PREF;INTERNET:christopher.apple@verizon.net REV:20011217T233830Z END:VCARD ------=_NextPart_000_0027_01C1CA00.1E130BE0-- From owner-ietf-ldup@mail.imc.org Thu Mar 14 08:16:26 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16586 for ; Thu, 14 Mar 2002 08:16:25 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2ED39R00168 for ietf-ldup-bks; Thu, 14 Mar 2002 05:03:09 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2ED36400164; Thu, 14 Mar 2002 05:03:06 -0800 (PST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.us.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id HAA90578; Thu, 14 Mar 2002 07:59:40 -0500 Received: from d27ml001.rchland.ibm.com (d27ml001.rchland.ibm.com [9.5.39.28]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g2ED2v0240328; Thu, 14 Mar 2002 08:02:57 -0500 From: "John McMeeking" Subject: RE: LDAP ACM in security considerations (RE: I-D ACTION:draft-iet f-ldup-replica-req-11.txt) To: John Strassner Cc: christopher.apple@verizon.net, ietf-ldup@imc.org, "'Kurt D. Zeilenga'" , owner-ietf-ldup@mail.imc.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Thu, 14 Mar 2002 07:02:56 -0600 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Build M11_11052001 Beta 4|November 05, 2001) at 03/14/2002 07:02:59 AM MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=09BBE1EFDFD43C488f9e8a93df938690918c09BBE1EFDFD43C48" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --0__=09BBE1EFDFD43C488f9e8a93df938690918c09BBE1EFDFD43C48 Content-type: multipart/alternative; Boundary="1__=09BBE1EFDFD43C488f9e8a93df938690918c09BBE1EFDFD43C48" --1__=09BBE1EFDFD43C488f9e8a93df938690918c09BBE1EFDFD43C48 Content-type: text/plain; charset=US-ASCII Tim Hahn and I decided that "Yes, we love this text" ;-). John McMeeking OS/400 Directory Services (507)253-4596 (T/L) 553-4596 John Strassner , christopher.apple@verizon.net Strassner@intelliden cc: ietf-ldup@imc.org .com> Subject: RE: LDAP ACM in security considerations (RE: I-D ACTION:draft-iet Sent by: owner-ietf- f-ldup-replica-req-11.txt) ldup@mail.imc.org 03/11/2002 01:36 PM Thanks Kurt for the revised text. Replica Requirements authors, could you please talk amongst yourselves ;-) and reply with a united "Yes, we love this text" or "No, we don't" please? LDUPers, could you also please think about the suggested text and weigh in with your votes please? regards, John Strassner co-chair, LDUP -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Monday, March 11, 2002 12:08 PM To: christopher.apple@verizon.net Cc: ietf-ldup@imc.org Subject: Re: LDAP ACM in security considerations (RE: I-D ACTION:draft- ietf-ldup-replica-req-11.txt) [revised to fix typos] As noted in previous discussions, the access control model is only one of the security models which impacts the replication. To address this, I suggest the security consideration section be replaced with: This document includes security requirements (listed in section 4.8 above) for the replication model and protocol. As noted in Section 3, interoperability may be impacted when replicating among servers that implement non-standard extensions to basic LDAP semantics. Security- related and general LDAP interoperability will be significantly impacted by the degree of consistency with which implementations support existing and future standards detailing LDAP security models, such as a future standard LDAP access control model. Other future standard security models could be listed as well, but one example is sufficient. Kurt --1__=09BBE1EFDFD43C488f9e8a93df938690918c09BBE1EFDFD43C48 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Tim Hahn and I decided that "Yes, we love this text" ;-).

John McMeeking
OS/400 Directory Services
(507)253-4596 (T/L) 553-4596

John Strassner <John.Strassner@intelliden.com>




          John Strassner <John.Strassner@intelliden.com>
          Sent by: owner-ietf-ldup@mail.imc.org

          03/11/2002 01:36 PM



To: "'Kurt D. Zeilenga'" <Kurt@OpenLDAP.org>, christopher.apple@verizon.net
cc: ietf-ldup@imc.org
Subject: RE: LDAP ACM in security considerations (RE: I-D ACTION:draft-iet f-ldup-replica-req-11.txt)


Thanks Kurt for the revised text.
Replica Requirements authors, could you please talk amongst yourselves ;-) and reply with a united "Yes, we love this text" or "No, we don't" please?

LDUPers, could you also please think about the suggested text and weigh in with your votes please?

regards,
John Strassner
co-chair, LDUP

-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Monday, March 11, 2002 12:08 PM
To: christopher.apple@verizon.net
Cc: ietf-ldup@imc.org
Subject: Re: LDAP ACM in security considerations (RE: I-D ACTION:draft-ietf-ldup-replica-req-11.txt)

[revised to fix typos]

As noted in previous discussions, the access control model
is only one of the security models which impacts the
replication. To address this, I suggest the security
consideration section be replaced with:

This document includes security requirements (listed in
section 4.8 above) for the replication model and protocol. As
noted in Section 3, interoperability may be impacted when
replicating among servers that implement non-standard
extensions to basic LDAP semantics. Security- related and
general LDAP interoperability will be significantly impacted
by the degree of consistency with which implementations
support existing and future standards detailing LDAP security
models, such as a future standard LDAP access control model.

Other future standard security models could be listed as
well, but one example is sufficient.

Kurt

--1__=09BBE1EFDFD43C488f9e8a93df938690918c09BBE1EFDFD43C48-- --0__=09BBE1EFDFD43C488f9e8a93df938690918c09BBE1EFDFD43C48 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <10__=09BBE1EFDFD43C488f9e8a93@rchland.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=09BBE1EFDFD43C488f9e8a93df938690918c09BBE1EFDFD43C48 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <20__=09BBE1EFDFD43C488f9e8a93@rchland.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=09BBE1EFDFD43C488f9e8a93df938690918c09BBE1EFDFD43C48-- From owner-ietf-ldup@mail.imc.org Fri Mar 15 10:59:24 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02428 for ; Fri, 15 Mar 2002 10:59:24 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2FFmU529688 for ietf-ldup-bks; Fri, 15 Mar 2002 07:48:30 -0800 (PST) Received: from mta010.verizon.net (mta010pub.verizon.net [206.46.170.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2FFmT429684 for ; Fri, 15 Mar 2002 07:48:29 -0800 (PST) Received: from mta010 ([192.168.129.97]) by mta010.verizon.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020315154830.ODRP26087.mta010.verizon.net@mta010>; Fri, 15 Mar 2002 09:48:30 -0600 From: Chris Apple Reply-To: christopher.apple@verizon.net To: ietf-ldup@imc.org CC: agenda@ietf.org Subject: WG Meeting Agenda Date: Fri, 15 Mar 2002 10:48:26 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20020315154830.ODRP26087.mta010.verizon.net@mta010> Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit LDAP Duplication/Replication/Update Protocols WG (ldup) Wednesday, March 20 at 0900 - 1130 =================================== Chairs: Chris Apple (christopher.apple@verizon.net) John Strassner (john.strassner@intelliden.com) Agenda: 0) Agenda Bashing 1) LDAPv3 Replication Requirements http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica-req-11.txt 2) LDAP Client Update Protocol http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-02.txt 3) LDUP Update Reconciliation Procedures http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-06.txt 4) LDAP Replication Architecture http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-07.txt 5) LDUP Replication Information Model http://www.ietf.org/internet-drafts/draft-ietf-ldup-infomod-04.txt 6) LDAP Subentry Schema http://www.ietf.org/internet-drafts/draft-ietf-ldup-subentry-08.txt 7) The LDUP Replication Update Protocol http://www.ietf.org/internet-drafts/draft-ietf-ldup-protocol-03.txt 8) General Usage Profile for LDAPv3 Replication http://www.ietf.org/internet-drafts/draft-ietf-ldup-usage-profile-02.txt 9) Profile for Framing LDAPv3 Operations http://www.ietf.org/internet-drafts/draft-ietf-ldup-framing-profile-00.txt 10) Mandatory LDAP Replica Management http://www.ietf.org/internet-drafts/draft-ietf-ldup-mrm-01.txt 11) LDUP Access Control Design Team 12) WG Charter Bashing Chris Apple christoper.apple@verizon.net From owner-ietf-ldup@mail.imc.org Mon Mar 18 08:33:15 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04868 for ; Mon, 18 Mar 2002 08:33:13 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2IDNi413433 for ietf-ldup-bks; Mon, 18 Mar 2002 05:23:44 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2IDNh413429 for ; Mon, 18 Mar 2002 05:23:43 -0800 (PST) Received: from northrelay01.pok.ibm.com (northrelay01.pok.us.ibm.com [9.117.200.21]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id IAA394148; Mon, 18 Mar 2002 08:20:14 -0500 Received: from d01mlc96.pok.ibm.com (d01mlc96.pok.ibm.com [9.117.250.33]) by northrelay01.pok.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g2IDNW875832; Mon, 18 Mar 2002 08:23:32 -0500 Subject: Re: WG Meeting Agenda To: christopher.apple@verizon.net Cc: ietf-ldup@imc.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Timothy Hahn" Date: Mon, 18 Mar 2002 08:22:39 -0500 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Build V5010_0226_dev01 SPR# RLBC582SCT |March 11, 2002) at 03/18/2002 08:23:33 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Chris, The agenda items for Update Replication Protocol and Information Model will be rather short - I don't have anything new of substance to report - I have incorporated some comments from the list but have not re-issued the drafts. See you tomorrow, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) phone: 607.752.6388 tie-line: 8/852.6388 fax: 607.752.3681 Chris Apple cc: agenda@ietf.org Sent by: Subject: WG Meeting Agenda owner-ietf-ldup@mail .imc.org 03/15/2002 10:48 AM Please respond to christopher.apple LDAP Duplication/Replication/Update Protocols WG (ldup) Wednesday, March 20 at 0900 - 1130 =================================== Chairs: Chris Apple (christopher.apple@verizon.net) John Strassner (john.strassner@intelliden.com) Agenda: 0) Agenda Bashing 1) LDAPv3 Replication Requirements http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica-req-11.txt 2) LDAP Client Update Protocol http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-02.txt 3) LDUP Update Reconciliation Procedures http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-06.txt 4) LDAP Replication Architecture http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-07.txt 5) LDUP Replication Information Model http://www.ietf.org/internet-drafts/draft-ietf-ldup-infomod-04.txt 6) LDAP Subentry Schema http://www.ietf.org/internet-drafts/draft-ietf-ldup-subentry-08.txt 7) The LDUP Replication Update Protocol http://www.ietf.org/internet-drafts/draft-ietf-ldup-protocol-03.txt 8) General Usage Profile for LDAPv3 Replication http://www.ietf.org/internet-drafts/draft-ietf-ldup-usage-profile-02.txt 9) Profile for Framing LDAPv3 Operations http://www.ietf.org/internet-drafts/draft-ietf-ldup-framing-profile-00.txt 10) Mandatory LDAP Replica Management http://www.ietf.org/internet-drafts/draft-ietf-ldup-mrm-01.txt 11) LDUP Access Control Design Team 12) WG Charter Bashing Chris Apple christoper.apple@verizon.net From owner-ietf-ldup@mail.imc.org Wed Mar 20 02:47:10 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25833 for ; Wed, 20 Mar 2002 02:47:10 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2K7ZO424625 for ietf-ldup-bks; Tue, 19 Mar 2002 23:35:24 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2K7ZN424617 for ; Tue, 19 Mar 2002 23:35:23 -0800 (PST) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 20 Mar 2002 00:34:35 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.1 Date: Wed, 20 Mar 2002 00:34:10 -0700 From: "Jim Sermersheim" To: Subject: LCUP comments Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Sorry, I've been sitting on these for some time now... - Section 4: Need to talk about server behavior regarding alias dereferencing. There is a note in the "Client Side Considerations", but it needs to be stated in the protocol section. - Section 4.4: Persistent search has the notion of changeTypes. The client specifies which type of updates will cause entries to be returned, and optionally whether the server tags each returned entry with the type of change that caused that entry to be returned. This feature is missing both from the Protocol Specification (Section 4) and Additional Features (Section 5). Client implementors use this functionality in persistent search. - Section 4.4: Descriptions of synchronizeAndPersist and persistOnly are missing the moddn operation (only mention add, mod, delete). - Section 4.4: Description of persistOnly needs to clairify "new" to reflect that it is in regard to the last sync session. - Section 4.5 states that deleted entries only contain the DN and entryUUID. There are existing persistent search applications that index or name entries using other attributes (like mail). I personally like this restriction, but I'm convinced that application writers will bristle. - Section 4.5: Description of entryDeleted states that the server MAY set this to TRUE if the entry leaves search scope. I believe this introduces interoperability problems sufficient to remove it or make it a MUST. - Section 4.6: Description of lcupClientDisconnect could be more clear if it were stated: "client requested search termination using the Stop Client Update Request". This is because the Stop Client Update Request has not yet been talked about in the draft. - Section 4.7: There is no OID or value specified for the stopClientUpdateResponse. - Section 4.7: Third to last paragraph ("If server resources become tight...") doesn't belong in this section. - Section 4.7: The last two paragraphs seem redundant. - Section 6: First consideration implies that the cookie holds the previous search criteria. May be a good thing, but should be explicitly called out. - Section 6: Second consideration calls out a scenario that can happen between sync sessions and the appropriate behavior. This same scenario can happen during a sync session, and the same behavior should be applied. Jim From owner-ietf-ldup@mail.imc.org Wed Mar 20 11:47:44 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04902 for ; Wed, 20 Mar 2002 11:47:43 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2KGavk20765 for ietf-ldup-bks; Wed, 20 Mar 2002 08:36:57 -0800 (PST) Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2KGat420757 for ; Wed, 20 Mar 2002 08:36:55 -0800 (PST) Received: from emss03g01.ems.lmco.com (emss03g01.ems.lmco.com [141.240.4.144]) by mailgw2a.lmco.com (8.11.6/8.11.6) with ESMTP id g2KGauk06410 for ; Wed, 20 Mar 2002 11:36:56 -0500 (EST) Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-33 #40646) id <0GTA00F013ZJ5Y@lmco.com> for ietf-ldup@imc.org; Wed, 20 Mar 2002 11:36:55 -0500 (EST) Received: from emss03i00.ems.lmco.com ([141.240.31.211]) by lmco.com (PMDF V5.2-33 #40646) with ESMTP id <0GTA0003V5LGSH@lmco.com> for ietf-ldup@imc.org; Wed, 20 Mar 2002 11:24:54 -0500 (EST) Received: by emss03i00.orl.lmco.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Mar 2002 11:24:51 -0500 Content-return: allowed Date: Wed, 20 Mar 2002 11:24:50 -0500 From: "Slone, Skip" Subject: Directory Access Control Summit - Paris April 9 To: "LDUP Mailing List (ietf-ldup@imc.org)" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/mixed; boundary="Boundary_(ID_Uir44vtLdvnUic80x22P+w)" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_Uir44vtLdvnUic80x22P+w) Content-type: multipart/alternative; boundary="Boundary_(ID_CRierWt1ZKpH7gHv8/8AbQ)" --Boundary_(ID_CRierWt1ZKpH7gHv8/8AbQ) Content-type: text/plain Content-Transfer-Encoding: 7BIT LDUPers... As I mentioned in the meeting moments ago, here is the pointer to the Directory Access Control Summit, which is to be held in Paris on the afternoon of April 9th as part of The Open Group meeting: http://www.opengroup.org/paris2002/directory_access.htm This is related to the non-IETF activities item mentioned during the LDUP charter discussion. -- Skip Slone --Boundary_(ID_CRierWt1ZKpH7gHv8/8AbQ) Content-type: text/html Content-Transfer-Encoding: 7BIT Message

LDUPers...  As I mentioned in the meeting moments ago, here is the pointer to the Directory Access Control Summit, which is to be held in Paris on the afternoon of April 9th as part of The Open Group meeting:
 
 
This is related to the non-IETF activities item mentioned during the LDUP charter discussion.
 
 -- Skip Slone
 
 
 
--Boundary_(ID_CRierWt1ZKpH7gHv8/8AbQ)-- --Boundary_(ID_Uir44vtLdvnUic80x22P+w) Content-type: application/octet-stream; name="Skip Slone.vcf" Content-disposition: attachment; filename="Skip Slone.vcf" Content-transfer-encoding: BASE64 Content-Transfer-Encoding: BASE64 QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpOOlNsb25lO1NraXANCkZOOlNraXAg U2xvbmUNCk9SRzpMb2NraGVlZCBNYXJ0aW47Q2hpZWYgVGVjaG5vbG9neSBPZmZp Y2UNClRJVExFOkNoaWVmIEFyY2hpdGVjdCwgRGlyZWN0b3J5IGFuZCBOYW1pbmcg U2VydmljZXMNCk5PVEU7RU5DT0RJTkc9UVVPVEVELVBSSU5UQUJMRTo9MEQ9MEEN ClRFTDtXT1JLO1ZPSUNFOisxICg0MDcpIDMwNi03MTAyDQpURUw7Q0VMTDtWT0lD RTorMSAoNDA3KSAyNTctMjQ1Mg0KVEVMO1dPUks7RkFYOisxICg0MDcpIDMwNi0x MzkyDQpURUw7SE9NRTtGQVg6KzEgKDIwOCkgNTQ1LTk2NzUNCkFEUjtXT1JLOjs7 MTI1MDYgTGFrZSBVbmRlcmhpbGwgUmQuICwgTVAgODQ1O09ybGFuZG87Rkw7MzI4 MjU7VVNBDQpMQUJFTDtXT1JLO0VOQ09ESU5HPVFVT1RFRC1QUklOVEFCTEU6MTI1 MDYgTGFrZSBVbmRlcmhpbGwgUmQuICwgTVAgODQ1PTBEPTBBT3JsYW5kbywgRkwg MzI4MjU9MEQ9MEFVU0ENCkVNQUlMO1BSRUY7SU5URVJORVQ6c2tpcC5zbG9uZUBs bWNvLmNvbQ0KUkVWOjIwMDEwNDA1VDE5MDkzM1oNCkVORDpWQ0FSRA0K --Boundary_(ID_Uir44vtLdvnUic80x22P+w)-- From owner-ietf-ldup@mail.imc.org Wed Mar 20 12:50:04 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07640 for ; Wed, 20 Mar 2002 12:50:03 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2KHdPM02190 for ietf-ldup-bks; Wed, 20 Mar 2002 09:39:25 -0800 (PST) Received: from smtp.oncalldba.com (roc-24-169-98-155.rochester.rr.com [24.169.98.155]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2KHdN402184 for ; Wed, 20 Mar 2002 09:39:23 -0800 (PST) Received: from RMINC_DOM-MTA by smtp.oncalldba.com with Novell_GroupWise; Wed, 20 Mar 2002 12:37:58 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Wed, 20 Mar 2002 09:07:17 -0700 From: "Ed Reed" To: , Cc: , , Subject: LDUP WG Meeting, Minneapolis 53rd IETF - Slides - Architecture presentation Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_2F728606.CAABC5BF" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_2F728606.CAABC5BF Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable From Ed Reed and Uppili Srinivasan --=_2F728606.CAABC5BF Content-Type: application/vnd.ms-powerpoint; name="LDUP-arch-07-changes.ppt" Content-Disposition: attachment; filename="LDUP-arch-07-changes.ppt" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAAQAAAAAAAAAA EAAAAgAAAAEAAAD+////AAAAAAAAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////9 ////RAAAAP7///8EAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAAFAAAAAwAAAANAAAADgAAAA8A AAAQAAAAEQAAABIAAAATAAAAAwAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAA AB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAA LAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6 AAAAOwAAADwAAAA9AAAAPgAAAD8AAABAAAAAQQAAAEIAAAD+////RQAAAP7///9GAAAARwAAAEgA AABJAAAASgAAAP7///////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////////1IA bwBvAHQAIABFAG4AdAByAHkAAAAAAIcAAAD+/////v///64AAACLAAAAjAAAAI0AAACOAAAAjwAA AJAAAAAWAAUA//////////8BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACaAAAAmwAAAMBVFrAc0MEB QwAAAEANAACgAAAAUABvAHcAZQByAFAAbwBpAG4AdAAgAEQAbwBjAHUAbQBlAG4AdAAAAKsAAACs AAAArQAAAP7///+vAAAAsAAAACgAAgEDAAAAAgAAAP///////////////////////////////wAA AAAAAAAAAAAAAAAAAAALAAAASn4AAP////9QAGUAcgBzAGkAcwB0AGUAbgB0AFMAdABvAHIAYQBn AGUAIABEAGkAcgBlAGMAdABvAHIAeQAAAP//////////OAACAQYAAAD///////////////////// ////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAA+AAAA/////0MAdQByAHIAZQBuAHQAIABV AHMAZQByAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIBBAAAAAUA AAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAABIAAAAAAAAA/v// //7////+////BAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAA EAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAe AAAAHwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAAP7/ //8tAAAALgAAAC8AAAAwAAAAMQAAADIAAAAzAAAANAAAAP7///////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////8AAAAA AAAAAAAANQAAAOwHAAD//wAAEAAAAC8AAADuBwAAAAAAAAAAAAAvAAAA7AcAAP//AAAQAAAAMAAA AO4HAAAAAAAAAAAAADAAAADsBwAA//8AABAAAAAxAAAA7gcAAAAAAAAAAAAAMQAAAK0PAAAAAAAA AAAAAAAAAAD3AwAAAQAAAAwAAAAAAAAAAAAAAA8QAAAAAAAA2Q8AAP//AAA4AAAAAAAAANoPAAAA AAAACAAAAAAAAAABAAAAAQAAAboPAAD//wAAAAAAAC4AAAC6DwAA//8AAAAAAAAwAAAA9AMAAP// AAA0AAAAeAAAAO8HAAAAAAAAJAAAAHgAAAAIAAAA////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ ALKysgDACwAA//8AAIAAAAAcAAAAwQsAAAAAAAAoAAAAAAAAAP3///8AAAAAAF3gAMD0//+Q9/// QAsAAHAIAAAAAAAATOkSAAAAAAC9CwAAAQAAADgAAAAAAAAAAQAAAQAAAP4AAAD+AAEAAAAAAAAA AAAAAAAABQEBAAAA/gAAAAAAAAAAAAAIOac4AAAAAAAAAAC4CwAA//8AAPAFAAAUAAAAwgsAAP// AABZAgAAEwAAAMMLAAAAAAAACAAAAAAAAAAPABIAAAAAAMELAAAAAAAAKAAAAAAAAAD9////AAAA AAAAAACg9v//gPv//8AJAABQ/v//AAAAAP3///8BABIAvQsAAAEAAAA4AAAAAAAAAAEAAAEAAAD+ AAAA/gEBAAAAAAAAAAAA/gAAAP4BAQAAAP4AAAAAAAAAAAAAADmnOAAAAAAAAAAAoQ8AAP//AACx AQAAHgAAAKAPAAAAAAAAEAAAAAAAAAA6AAAAHQAAAASABIAT5BIAog8AAP//AACBAQAAAAAAAKMP AAAAAAAAJAAAAAAAAAAGAAAABMKSMBOQ7AQAgP//AAAAANr2//+d+///hgkAADP+//+1DwAAAAAA AAQAAAAAAAAAAQAAAOAPAAD//wAAKQEAAAAAAADuBwAAAAAAAB0AAAA1AAAATERBUCBSZXBsaWNh dGlvbiBBcmNoaXRlY3R1cmXsBwAA//8AADwAAAAvAAAA7gcAAAAAAAAsAAAALwAAAB0AAADiDwAA AAAAABgAAAAvAAAAAQACACwAAAAAAAAAAAMSAAAAAAAAAAAA7AcAAP//AABYAAAAMAAAAO4HAAAA AAAASAAAADAAAAAdAAAA4w8AAAAAAAA0AAAAMAAAAABcAAAA/ZUA//8CAGQAAAAAAAAAAAAAAAAA AAABAAAAZAAAAAAAAAAAAAAAAAAAAAABAQHsBwAA//8AACgAAAAxAAAA7gcAAAAAAAAYAAAAMQAA AB0AAADhDwAAAAAAAAQAAAAxAAAA/////60PAAAAAAAAAAAAAAAAAADCCwAA//8AAHcDAAATAAAA wwsAAAAAAAAIAAAAAAAAABAAEgABAAAAwQsAAAAAAAAoAAAAAAAAAP3///8AAAAAAAAAAID4//8g /v//QAgAAND///8AAAAA/f///wEAEgC9CwAAAQAAADgAAAAAAAAAAQAAAQAAAP4AAAD+AQEAAAAA AAAAAAD+AAAA/gEBAAAA/gAAAAAAAAAAAAAAOac4AAAAAAAAAAChDwAA//8AAM8CAAAeAAAAoA8A AAAAAAAQAAAAAAAAADoAAAAdAAAABIAEgAPkEgCiDwAA//8AAJ8CAAAAAAAAow8AAAAAAAAkAAAA AAAAAAUAAAAEwpIwAzjsBACA//8AAAAAuvj//z3+//8GCAAAs////7UPAAAAAAAABAAAAAAAAAAA AAAA4A8AAP//AABHAgAAAAAAAO4HAAAAAAAANwAAADUAAABkcmFmdC1pZXRmLWxkdXAtbW9kZWwt MDcudHh0DQ1FZCBSZWVkDVVwcGlsaSBTcmluaXZhc2Fu7AcAAP//AABoAAAALwAAAO4HAAAAAAAA WAAAAC8AAAAeAAAA4g8AAAAAAAAYAAAALwAAAAEAAgAgAAAAAAAAAAABEgAAAAAAAAAAABkAAADi DwAAAAAAABgAAAAvAAAAAQACABQAAAAAAAAAAAESAAAAAAAAAAAA7AcAAP//AAAwAQAAMAAAAO4H AAAAAAAAIAEAADAAAAAdAAAA4w8AAAAAAAA0AAAAMAAAAABcAAAA/ZUA//8CAGQAAAAAAAAAAAAA AAAAAAABAAAAZAAAABQAAAAAAAAAAAAAAAABAQEBAAAA4w8AAAAAAAA0AAAAMAAAAABcAAAA/ZUA //8CAGQAAAAAAAAAAAAAAAAAAAABAAAAZAAAABQAAAAAAAAAAAAAAAABAQEIAAAA4w8AAAAAAAA0 AAAAMAAAAABcAAAA/ZUA//8CAGQAAAAAAAAAAAAAAAAAAAABAAAAZAAAABQAAAAAAAAAAAAAAAAB AQERAAAA4w8AAAAAAAA0AAAAMAAAAABcAAAA/ZUA//8CAGQAAAAAAAAAAAAAAAAAAAABAAAAZAAA ABQAAAAAAAAAAAAAAAABAQHsBwAA//8AACgAAAAxAAAA7gcAAAAAAAAYAAAAMQAAADcAAADhDwAA AAAAAAQAAAAxAAAA/////60PAAAAAAAAAAAAAAAAAADuAwAA//8AAEgOAAAQAAAA7wMAAAAAAAAI AAAAAAAAAAEBAAAAAACA7QMAAAEAAAAYAAAAAAAAAMD0//+Q9///QAsAAHAIAAABAQAAAeoSAPAD AAD//wAAoAQAACUAAADxAwAAAAAAAAQAAAAAAAAAAQEAAO0DAAABAAAAGAAAAAAAAACQ9///wPT/ /3AIAABACwAAAQEAAAHpEgDZDwAA//8AAEgAAAAAAAAA2g8AAAAAAAAIAAAAAAAAAAEAAAABAQEB ug8AAP//AAAAAAAALgAAALoPAAD//wAAAAAAAC8AAAC6DwAA//8AAAAAAAAwAAAA9AMAAP//AAA0 AAAAeAAAAO8HAAAAAAAAJAAAAHgAAAAIAAAA////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKy sgDACwAA//8AAIAAAAAcAAAAwQsAAAAAAAAoAAAAAAAAAP3///8AAAAAAF3gAJD3///A9P//cAgA AEALAAAAAAAAvOgSAAAAAAC9CwAAAQAAADgAAAAAAAAAAQAAAQAAAP4AAAD+AAEAAAAAAAAAAAAA AAAABQEBAAAA/gAAAAAAAAAAAAAIOac4AAAAAAAAAAC4CwAA//8AACgDAAAUAAAAwgsAAP//AADs AAAAEwAAAMMLAAAAAAAACAAAAAAAAAATABIAAAAAAMELAAAAAAAAKAAAAAAAAAD9////AAAAAAAA AABd+v//bfb//6MFAADj/v//AAAAAP3///8AARIAvQsAAAEAAAA4AAAAAAAAAAAAAAAAAAD+//// /gABAAAAAAAA/////v////4BAQAAAP4AAAAAAAAAAAAAADmnOAAAAAAAAAAArg8AAP//AABEAAAA HwAAAK8PAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1g8AAP//AAAUAAAAAAAAAMAPAAAA AAAABAAAAAAAAAABAQAAwgsAAP//AAAcAgAAEwAAAMMLAAAAAAAACAAAAAAAAAAOABIAAQAAAMEL AAAAAAAAKAAAAAAAAAD9////AAAAAAAAAADQ+f//cP///zAGAACQCQAAAAAAAP3///8BABIAvQsA AAEAAAA4AAAAAAAAAAEAAAEAAAD+AAAA/gEBAAAAAAAAAAAA/gAAAP4BAQAAAP4AAAAAAAAAAAAA ADmnOAAAAAAAAAAAoQ8AAP//AAB0AQAAHgAAAKAPAAAAAAAAEAAAAAAAAAA6AAAAHQAAAASABIAD 5BIAog8AAP//AABEAQAAAAAAAKMPAAAAAAAAJAAAAAAAAAACAAAABMKSMANo7AQAgP//AAAAAAr6 //+N////9gUAAHMJAAC1DwAAAAAAAAQAAAAAAAAAAAAAAOAPAAD//wAA7AAAAAAAAADjDwAAAAAA ADQAAAAyAAAAABAAAAD9lQD//wIAZAAAAAAAAAAAAAAAAAAAAAAAAABkAAAAHgAAAAAAAAAAAAAA AAEBAeIPAAAAAAAAGAAAADMAAAABAAIADAAAAAAAAAAAARIAAAAAAAAAAADuBwAAAAAAAAAAAAA1 AAAA7AcAAP//AAAQAAAALwAAAO4HAAAAAAAAAAAAAC8AAADsBwAA//8AABAAAAAwAAAA7gcAAAAA AAAAAAAAMAAAAOwHAAD//wAAEAAAADEAAADuBwAAAAAAAAAAAAAxAAAArQ8AAAAAAAAAAAAAAAAA APcDAAABAAAADAAAAAAAAAABAAAADA0AAAAAAADZDwAA//8AADgAAAAAAAAA2g8AAAAAAAAIAAAA AAAAAAEAAAABAAABug8AAP//AAAAAAAALgAAALoPAAD//wAAAAAAADAAAAD0AwAA//8AADQAAAB4 AAAA7wcAAAAAAAAkAAAAeAAAAAgAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAMAL AAD//wAAgAAAABwAAADBCwAAAAAAACgAAAAAAAAA/f///wAAAAAAXeAAwPT//5D3//9ACwAAcAgA AAAAAABM6RIAAAAAAL0LAAABAAAAOAAAAAAAAAABAAABAAAA/gAAAP4AAQAAAAAAAAAAAAAAAAAF AQEAAAD+AAAAAAAAAAAAAAg5pzgAAAAAAAAAALgLAAD//wAAEAgAABQAAADCCwAA//8AAE4CAAAT AAAAwwsAAAAAAAAIAAAAAAAAAAwAEgAAAAAAwQsAAAAAAAAoAAAAAAAAAP3///8AAAAAAAAAAJD6 //8g+P//4AQAAHD5//8AAAAA/f///wEAEgC9CwAAAQAAADgAAAAAAAAAAQAAAQAAAP4AAAD+AQEA AAAAAAAAAAD+AAAA/gEBAAAA/gAAAAAAAAAAAAAAOac4AAAAAAAAAAChDwAA//8AAKYBAAAeAAAA oA8AAAAAAAAQAAAAAAAAADoAAAAdAAAABIAEgBPkEgCiDwAA//8AAHYBAAAAAAAAow8AAAAAAAAk AAAAAAAAAAAAAAAEwpIwEyzsBACA//8AAAAAyvr//z34//+mBAAAU/n//7UPAAAAAAAABAAAAAAA AAABAAAA4A8AAP//AAAeAQAAAAAAAO4HAAAAAAAAEgAAADUAAABTdW1tYXJ5IG9mIGNoYW5nZXPs BwAA//8AADwAAAAvAAAA7gcAAAAAAAAsAAAALwAAABIAAADiDwAAAAAAABgAAAAvAAAAAQACACQA AAAAAAAAAAMSAAAAAAAAAAAA7AcAAP//AABYAAAAMAAAAO4HAAAAAAAASAAAADAAAAASAAAA4w8A AAAAAAA0AAAAMAAAAABcAAAA/ZUA//8CAGQAAAAAAAAAAAAAAAAAAAABAAAAAwAAAP//AAA6fgAA AAAAAOgDAAD//wAAEn4AAAAAAADpAwAABAAAACwAAAAAAAAAgBYAAOAQAADgEAAAgBYAAAAYAQAB ABIABQEAAADqAAAFAAAABQAAAAoAAADyAwAA//8AAO4MAAAVAAAA6wcAAP//AACIAAAAEgAAANgP AAAAAAAAAgAAAAAAAAAOAOEHAAAAAAAAAAAAAAAAAADYDwAAAAAAAAIAAAAAAAAAAADhBwAAAAAA AAAAAAABAAAA2A8AAAAAAAACAAAAAAAAAA8A4QcAAAAAAAAAAAAAAgAAANgPAAAAAAAAAgAAAAAA AAAQAOEHAAAAAAAAAAAAAAMAAADIDwAA//8AAOIAAAAGAAAA0g8AAAAAAAAEAAAAKAAAAAEAAAC6 DwAA//8AACIAAAAEAAAAgWWBZ4FpgWuBbYFvgXGBc4F1gXeBeYGPgZAkKFtce6KBkroPAAD//wAA jAAAAAUAAACBQYFCgUOBRIFFgUaBR4FIgUmBSoFLgVKBU4FUgVWBWIFbgWaBaIFqgWyBboFwgXKB dIF2gXiBeoGLgfGBjIGNgY6BkYGTgp+CoYKjgqWCp4LBguGC44LlguyDQINCg0SDRoNIg2KDg4OF g4eDjoOVg5YhJSksLjo7P119oaOkpaeoqaqrrK2ur7De39YHAAD//wAAAAAAABcAAACwDwAA//8A ABACAAAYAAAA5Q8AAP//AABUAAAACQAAALMPAAAAAAAANAAAAAAAAAAAAAAAAAAAACABAAAgAQAA QAIAAEACAABgAwAAYAMAAIAEAACABAAAAwAAAEACAAAAAAAA5g8AAAAAAAAAAAAAAAAAAMsPAAAA AAAAAAAAAAAAAADhBwAAAAAAAAAAAAAAAAAA5Q8AAP//AABUAAAACQAAALMPAAAAAAAANAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAEACAAAAAAAA5g8A AAAAAAAAAAAAAAAAAMsPAAAAAAAAAAAAAAAAAADhBwAAAAAAAAAAAAABAAAA5Q8AAP//AABUAAAA CQAAALMPAAAAAAAANAAAAAAAAADYAAAAAAAAANQBAAAgAQAA0AIAAEACAADwAwAAYAMAABAFAACA BAAAAwAAAEACAAAAAAAA5g8AAAAAAAAAAAAAAAAAAMsPAAAAAAAAAAAAAAAAAADhBwAAAAAAAAAA AAACAAAA5Q8AAP//AABUAAAACQAAALMPAAAAAAAANAAAAAAAAABQAQAAAAAAAEACAACYAQAAMAMA AIgCAAA4BAAAeAMAAFgFAACABAAAAwAAAEACAAAAAAAA5g8AAAAAAAAAAAAAAAAAAMsPAAAAAAAA AAAAAAAAAADhBwAAAAAAAAAAAAADAAAA1QcAAP//AAD4AAAAGQAAALYPAAD//wAATAAAAAkAAAC3 DwAAAAAAADwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJABAAAAAAAAAAAAIkFyaWFsAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAyg8AAAAAAAAAAAAAAAAAAOEHAAAAAAAAAAAAAAAAAAC2DwAA//8A AEwAAAAJAAAAtw8AAAAAAAA8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQAQAAAAAAAAAAABJUaW1l cyBOZXcgUm9tYW4ABgIAAIh/ZgMmBAAAAAAAAMoPAAAAAAAAAAAAAAAAAADhBwAAAAAAAAAAAAAB AAAA1QcAAP//AAAAAAAAGgAAAO8HAAAAAAAABAAAACQAAAAAAAAABAQAAP//AADSBQAAKgAAAAUE AAAAAAAACgAAAAAAAAABAQEAAAAAAAAA1A8AAAAAAADYAQAAAAAAAAEAAACEX+AAEwwAAB8AAAAB AAIALAAAAAAAAAAAAwAAAAAAAAAAAAABAAIALAAAAAAAAAAAA+AAAAAAAAAAAAABAAIALAAAAAAA AAAAA+AAAAAAAAAAAAABAAIALAAAAAAAAAAAAwAAAAAAAAAAAAABAAIALAAAAAAAAAAAAwAAAAAA AAAAAAD//wIAAAAAAAAAAAAA/uAAAAAAAAAAAAAAVAAAAP2VAP//AgBkAAAAAAAAAAAAAAAAAAAA AQAAAGQAAAAAAAAAAAAAAAAAAAAAAQEBAOgAAAD9lQD//wIAZAAAAAAAAAAAAAAAAQAAAAEAAABk AAAAAAAAAAAAAAAAAAAAAAEBAQCsAAAA/ZUA//8CAGQAAAAAAAAAAAAAAAIAAAABAAAAZAAAAAAA AAAAAAAAAAAAAAABAQEAAAAAAP2VAP//AgBkAAAAAAAAAAAAAAADAAAAAQAAAGQAAAAAAAAAAAAA AAAAAAAAAQEBAKQAAAD9lQD//wIAZAAAAAAAAAAAAAAABAAAAAEAAABkAAAAAAAAAAAAAAAAAAAA AAEBAQAAAAAA/gAA//8CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADU DwAAAAAAANgBAAAAAAAAAgAAAIRf4AADDAAAHwAAAAEAAgAgAAAAAAAAAAABAAAAAAAAAAAAAAEA AgAcAAAAAAAAAAAB4AAAAAAAAAAAAAEAAgAYAAAAAAAAAAAB4AAAAAAAAAAAAAEAAgAUAAAAAAAA AAABAAAAAAAAAAAAAAEAAgAUAAAAAAAAAAABAAAAAAAAAAAAAP//AgAAAAAAAAAAAAD+4AAAAAAA AAAAAAFUAAAA/ZUA//8CAGQAAAAAAAAAAAAAAAAAAAAAAAAAZAAAABQAAAAAAAAAAAAAAAABAQEB 6AAAAP2WAP//AgBkAAAAAAAAAAAAAAABAAAAAAAAAGQAAAAUAAAAAAAAAAAAAAAAAQEBAawAAAD9 lQD//wIAZAAAAAAAAAAAAAAAAgAAAAAAAABkAAAAFAAAAAAAAAAAAAAAAAEBAQEAAAAA/ZYA//8C AGQAAAAAAAAAAAAAAAMAAAAAAAAAZAAAABQAAAAAAAAAAAAAAAABAQEBpAAAAP27AP//AgBkAAAA AAAAAAAAAAAEAAAAAAAAAGQAAAAUAAAAAAAAAAAAAAAAAQEBAAAAAAD+AAD//wIAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANQPAAAAAAAA2AEAAAAAAAAAAAAAhF/gAAMM AAAfAAAAAQACAAwAAAAAAAAAAAEAAAAAAAAAAAAAAQACAAwAAAAAAAAAAAHgAAAAAAAAAAAAAQAC AAwAAAAAAAAAAAHgAAAAAAAAAAAAAQACAAwAAAAAAAAAAAEAAAAAAAAAAAAAAQACAAwAAAAAAAAA AAEAAAAAAAAAAAAA//8CAAAAAAAAAAAAAP7gAAAAAAAAAAAAAFQAAAD9lQD//wIAZAAAAAAAAAAA AAAAAAAAAAAAAABkAAAAHgAAAAAAAAAAAAAAAAEBAQDoAAAA/ZUA//8CAGQAAAAAAAAAAAAAAAEA AAAAAAAAZAAAAB4AAAAAAAAAAAAAAAABAQEArAAAAP2VAP//AgBkAAAAAAAAAAAAAAACAAAAAAAA AGQAAAAeAAAAAAAAAAAAAAAAAQEBAAAAAAD9lQD//wIAZAAAAAAAAAAAAAAAAwAAAAAAAABkAAAA HgAAAAAAAAAAAAAAAAEBAQCkAAAA/ZUA//8CAGQAAAAAAAAAAAAAAAQAAAAAAAAAZAAAAB4AAAAA AAAAAAAAAAABAQEAAAAAAP4AAP//AgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAxAsAAP//AAAWAgAAFgAAAMULAAAAAAAAAgAAAAAAAAAAAMELAAAAAAAAKAAAAAAAAAD9 ////AAAAAABd4AAAAAAAAAAAAAAAAAAAAAAAAAAAAP3///8BAAAAvQsAAAEAAAA4AAAAAAAAAAAA AAAAAAAB/////gABAAAAAAAAAAAABAAAAAABAQAAAP4AAAAAAAAAAAAAADmnOAAAAAAAAAAAoQ8A AP//AAB0AQAAHgAAAKAPAAAAAAAAEAAAAAAAAAA6AAAAHQAAAAAAAAET/P/+og8AAP//AABEAQAA AAAAAKMPAAAAAAAAJAAAAAAAAAAEAAAAAAAAABMAEgAAgP//AAAAAAAAAAAAAAAAAAAAAAAAAAC1 DwAAAAAAAAQAAAAAAAAAAAAAAOAPAAD//wAA7AAAAAAAAADjDwAAAAAAADQAAAAyAAAAAAAAAAD9 lQD//wIAZAAAAAAAAAAAAAAAAAAAAAAAAABkAAAAAAAAAAAAAAAAAAAAAAEBAeIPAAAAAAAAGAAA ADMAAAABAAIAGAAAAAAAAAAAAf//AAAAAAAAAADuBwAAAAAAAAAAAAA1AAAA7AcAAP//AAAQAAAA LwAAAO4HAAAAAAAAAAAAAC8AAADsBwAA//8AABAAAAAwAAAA7gcAAAAAAAAAAAAAMAAAAOwHAAD/ /wAAEAAAADEAAADuBwAAAAAAAAAAAAAxAAAArQ8AAAAAAAAAAAAAAAAAANAHAAD//wAAA0QAAAoA AADRBwAAAAAAAAQAAAAAAAAABQAAAO4DAAD//wAAKAwAABAAAADvAwAAAAAAAAgAAAAAAAAAAAEA AAAAAIDtAwAAAQAAABgAAAAAAAAAwPT//5D3//9ACwAAcAgAAAEBAAAB6hIA8AMAAP//AACgBAAA JQAAAPEDAAAAAAAABAAAAAAAAAAAAQAA7QMAAAEAAAAYAAAAAAAAAJD3///A9P//cAgAAEALAAAB AQAAAekSANkPAAD//wAASAAAAAAAAADaDwAAAAAAAAgAAAAAAAAAAQAAAAEBAQG6DwAA//8AAAAA AAAuAAAAug8AAP//AAAAAAAALwAAALoPAAD//wAAAAAAADAAAAD0AwAA//8AADQAAAB4AAAA7wcA AAAAAAAkAAAAeAAAAAgAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAMALAAD//wAA gAAAABwAAADBCwAAAAAAACgAAAAAAAAA/f///wAAAAAAXeAAkPf//8D0//9wCAAAQAsAAAAAAAC8 6BIAAAAAAL0LAAABAAAAOAAAAAAAAAABAAABAAAA/gAAAP4AAQAAAAAAAAAAAAAAAAAFAQEAAAD+ AAAAAAAAAAAAAAg5pzgAAAAAAAAAALgLAAD//wAAKAMAABQAAADCCwAA//8AAOwAAAATAAAAwwsA AAAAAAAIAAAAAAAAABMAEgAAAAAAwQsAAAAAAAAoAAAAAAAAAP3///8AAAAAAAAAAF36//9t9v// owUAAOP+//8AAAAA/f///wABEgC9CwAAAQAAADgAAAAAAAAAAAAAAAAAAP7////+AAEAAAAAAAD/ ///+/////gEBAAAA/gAAAAAAAAAAAAAAOac4AAAAAAAAAACuDwAA//8AAEQAAAAfAAAArw8AAAAA AAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADWDwAA//8AABQAAAAAAAAAwA8AAAAAAAAEAAAAAAAA AAABAADCCwAA//8AABwCAAATAAAAwwsAAAAAAAAIAAAAAAAAAA4AEgABAAAAwQsAAAAAAAAoAAAA AAAAAP3///8AAAAAAAAAAND5//9w////MAYAAJAJAAAAAAAA/f///wEAEgC9CwAAAQAAADgAAAAA AAAAAQAAAQAAAP4AAAD+AQEAAAAAAAAAAAD+AAAA/gEBAAAA/gAAAAAAAAAAAAAAOac4AAAAAAAA AAChDwAA//8AAHQBAAAeAAAAoA8AAAAAAAAQAAAAAAAAADoAAAAdAAAABIAEgAPkEgCiDwAA//8A AEQBAAAAAAAAow8AAAAAAAAkAAAAAAAAAAIAAAAEwpIwAzTsBACA//8AAAAACvr//43////2BQAA cwkAALUPAAAAAAAABAAAAAAAAAAAAAAA4A8AAP//AADsAAAAAAAAAOMPAAAAAAAANAAAADIAAAAA EAAAAP2VAP//AgBkAAAAAAAAAAAAAAAAAAAAAAAAAGQAAAAeAAAAAAAAAAAAAAAAAQEB4g8AAAAA AAAYAAAAMwAAAAEAAgAMAAAAAAAAAAABEgAAAAAAAAAAAO4HZAAAAAAAAAAAAAAAAAAAAAABAQHs BwAA//8AACgAAAAxAAAA7gcAAAAAAAAYAAAAMQAAABIAAADhDwAAAAAAAAQAAAAxAAAA/////60P AAAAAAAAAAAAAAAAAADCCwAA//8AAKIFAAATAAAAwwsAAAAAAAAIAAAAAAAAAA0AEgABAAAAwQsA AAAAAAAoAAAAAAAAAP3///8AAAAAAAAAAKD2///w+v//wAkAAAAGAAAAAAAA/f///wEAEgC9CwAA AQAAADgAAAAAAAAAAQAAAQAAAP4AAAD+AQEAAAAAAAAAAAD+AAAA/gEBAAAA/gAAAAAAAAAAAAAA Oac4AAAAAAAAAAChDwAA//8AAPoEAAAeAAAAoA8AAAAAAAAQAAAAAAAAADoAAAAdAAAABIAEgAPk EgCiDwAA//8AAMoEAAAAAAAAow8AAAAAAAAkAAAAAAAAAAEAAAAEwpIwA8zsBACA//8AAAAA2vb/ /w37//+GCQAA4wUAALUPAAAAAAAABAAAAAAAAAACAAAA4A8AAP//AAByBAAAAAAAAO4HAAAAAAAA XgEAADUAAABDb252ZXJ0ZWQgZG9jdW1lbnQgdG8gbXMgd29yZCB0ZW1wbGF0ZS1iYXNlZCBkb2N1 bWVudA1DbGFyaWZpZWQgk2RvY3VtZW50IG9iamVjdGl2ZXOUDUNsZWFuZWQgdXAgk25vbiBvYmpl Y3RpdmVzlCB0byBpZGVudGlmeSBhcmNoaXRlY3R1cmFsIGlzc3VlcyBub3QgYWRkcmVzc2VkDUZv Y3VzIGRpc2N1c3Npb25zIHRvIGhlbHAgdW5kZXJzdGFuZA1MRFVQIJN0aGVvcnkgb2Ygb3BlcmF0 aW9ulA1Db21tb24gY29uY2VwdHMgZW1wbG95ZWQgaW4gb3RoZXIgZGVzaWduIGRvY3VtZW50cw1N YWRlIGNoYW5nZXMgdG8gcmVmbGVjdCBhbmQgYWxpZ24gd2l0aCB0aGUgbGF0ZXN0IExEVVAgUmVx dWlyZW1lbnRzIGRyYWZ0IOwHAAD//wAAlAAAAC8AAADuBwAAAAAAAIQAAAAvAAAAxgAAAOIPAAAA AAAAGAAAAC8AAAABAAIAHAAAAAAAAAAAARIAAAAAAAAAAABOAAAA4g8AAAAAAAAYAAAALwAAAAEA AgAYAAAAAAAAAAABEgAAAAAAAAAAAEoAAADiDwAAAAAAABgAAAAvAAAAAQACABwAAAAAAAAAAAES AAAAAAAAAAAA7AcAAP//AAAIAgAAMAAAAO4HAAAAAAAA+AEAADAAAAA2AAAA4w8AAAAAAAA0AAAA MAAAAAFcAAAA/ZUA//8CAGQAAAAAAAAAAAAAAAAAAAAAAAAAWgAAABQAAAAAAAAAAAAAAAABAQEg AAAA4w8AAAAAAAA0AAAAMAAAAAFcAAAA/ZUA//8CAGQAAAAAAAAAAAAAAAAAAAAAAAAAWgAAABQA AAAAAAAAAAAAAAABAQFLAAAA4w8AAAAAAAA0AAAAMAAAAAFcAAAA/ZUA//8CAGQAAAAAAAAAAAAA AAAAAAAAAAAAWgAAABQAAAAAAAAAAAAAAAABAQElAAAA4w8AAAAAAAA0AAAAMAAAAAFcAAAA/ZUA //8CAGQAAAAAAAAAAAAAAAAAAAAAAAAAWgAAABQAAAAAAAAAAAAAAAABAQEbAAAA4w8AAAAAAAA0 AAAAMAAAAAFcAAAA/ZYA//8CAGQAAAAAAAAAAAAAAAEAAAAAAAAAWgAAABQAAAAAAAAAAAAAAAAB AQEzAAAA4w8AAAAAAAA0AAAAMAAAAAFcAAAA/ZYA//8CAGQAAAAAAAAAAAAAAAEAAAAAAAAAWgAA ABQAAAAAAAAAAAAAAAABAQFKAAAA4w8AAAAAAAA0AAAAMAAAAAFcAAAA/ZUA//8CAGQAAAAAAAAA AAAAAAAAAAAAAAAAWgAAABQAAAAAAAAAAAAAAAABAQHsBwAA//8AACgAAAAxAAAA7gcAAAAAAAAY AAAAMQAAAF4BAADhDwAAAAAAAAQAAAAxAAAA/////60PAAAAAAAAAAAAAAAAAADuAwAA//8AAHgN AAAQAAAA7wMAAAAAAAAIAAAAAAAAAAIBAAAAAACA7QMAAAEAAAAYAAAAAAAAAMD0//+Q9///QAsA AHAIAAABAQAAAeoSAPADAAD//wAAoAQAACUAAADxAwAAAAAAAAQAAAAAAAAAAgEAAO0DAAABAAAA GAAAAAAAAACQ9///wPT//3AIAABACwAAAQEAAAHpEgDZDwAA//8AAEgAAAAAAAAA2g8AAAAAAAAI AAAAAAAAAAEAAAABAQEBug8AAP//AAAAAAAALgAAALoPAAD//wAAAAAAAC8AAAC6DwAA//8AAAAA AAAwAAAA9AMAAP//AAA0AAAAeAAAAO8HAAAAAAAAJAAAAHgAAAAIAAAA////AAAAAACAgIAAAAAA AADMmQAzM8wAzMz/ALKysgDACwAA//8AAIAAAAAcAAAAwQsAAAAAAAAoAAAAAAAAAP3///8AAAAA AF3gAJD3///A9P//cAgAAEALAAAAAAAAvOgSAAAAAAC9CwAAAQAAADgAAAAAAAAAAQAAAQAAAP4A AAD+AAEAAAAAAAAAAAAAAAAABQEBAAAA/gAAAAAAAAAAAAAIOac4AAAAAAAAAAC4CwAA//8AACgD AAAUAAAAwgsAAP//AADsAAAAEwAAAMMLAAAAAAAACAAAAAAAAAATABIAAAAAAMELAAAAAAAAKAAA AAAAAAD9////AAAAAAAAAABd+v//bfb//6MFAADj/v//AAAAAP3///8AARIAvQsAAAEAAAA4AAAA AAAAAAAAAAAAAAD+/////gABAAAAAAAA/////v////4BAQAAAP4AAAAAAAAAAAAAADmnOAAAAAAA AAAArg8AAP//AABEAAAAHwAAAK8PAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1g8AAP// AAAUAAAAAAAAAMAPAAAAAAAABAAAAAAAAAACAQAAwgsAAP//AAAcAgAAEwAAAMMLAAAAAAAACAAA AAAAAAAOABIAAQAAAMELAAAAAAAAKAAAAAAAAAD9////AAAAAAAAAADQ+f//cP///zAGAACQCQAA AAAAAP3///8BABIAvQsAAAEAAAA4AAAAAAAAAAEAAAEAAAD+AAAA/gEBAAAAAAAAAAAA/gAAAP4B AQAAAP4AAAAAAAAAAAAAADmnOAAAAAAAAAAAoQ8AAP//AAB0AQAAHgAAAKAPAAAAAAAAEAAAAAAA AAA6AAAAHQAAAASABIAD5BIAog8AAP//AABEAQAAAAAAAKMPAAAAAAAAJAAAAAAAAAACAAAABMKS MAN47AQAgP//AAAAAAr6//+N////9gUAAHMJAAC1DwAAAAAAAAQAAAAAAAAAAAAAAOAPAAD//wAA 7AAAAAAAAADjDwAAAAAAADQAAAAyAAAAABAAAAD9lQD//wIAZAAAAAAAAAAAAAAAAAAAAAAAAABk AAAAHgAAAAAAAAAAAAAAAAEBAeIPAAAAAAAAGAAAADMAAAABAAIADAAAAAAAAAAAARIAAAAAAAAA AADuBwAAAAAAAAAAAAA1AAAA7AcAAP//AAAQAAAALwAAAO4HAAAAAAAAAAAAAC8AAADsBwAA//8A ABAAAAAwAAAA7gcAAAAAAAAAAAAAMAAAAOwHAAD//wAAEAAAADEAAADuBwAAAAAAAAAAAAAxAAAA rQ8AAAAAAAAAAAAAAAAAAPcDAAABAAAADAAAAAAAAAABAAAADA0AAAAAAADZDwAA//8AADgAAAAA AAAA2g8AAAAAAAAIAAAAAAAAAAEAAAABAAABug8AAP//AAAAAAAALgAAALoPAAD//wAAAAAAADAA AAD0AwAA//8AADQAAAB4AAAA7wcAAAAAAAAkAAAAeAAAAAgAAAD///8AAAAAAICAgAAAAAAAAMyZ ADMzzADMzP8AsrKyAMALAAD//wAAgAAAABwAAADBCwAAAAAAACgAAAAAAAAA/f///wAAAAAAXeAA wPT//5D3//9ACwAAcAgAAAAAAABM6RIAAAAAAL0LAAABAAAAOAAAAAAAAAABAAABAAAA/gAAAP4A AQAAAAAAAAAAAAAAAAAFAQEAAAD+AAAAAAAAAAAAAAg5pzgAAAAAAAAAALgLAAD//wAAQAcAABQA AADCCwAA//8AAFYCAAATAAAAwwsAAAAAAAAIAAAAAAAAAAwAEgAAAAAAwQsAAAAAAAAoAAAAAAAA AP3///8AAAAAAAAAAFD4//+w+P//IAcAAAD6//8AAAAA/f///wEAEgC9CwAAAQAAADgAAAAAAAAA AQAAAQAAAP4AAAD+AQEAAAAAAAAAAAD+AAAA/gEBAAAA/gAAAAAAAAAAAAAAOac4AAAAAAAAAACh DwAA//8AAK4BAAAeAAAAoA8AAAAAAAAQAAAAAAAAADoAAAAdAAAABIAEgBPkEgCiDwAA//8AAH4B AAAAAAAAow8AAAAAAAAkAAAAAAAAAAAAAAAEwpIwEwzsBACA//8AAAAAivj//834///mBgAA4/n/ /7UPAAAAAAAABAAAAAAAAAABAAAA4A8AAP//AAAmAQAAAAAAAO4HAAAAAAAAGgAAADUAAABTdW1t YXJ5IG9mIGNoYW5nZXMtIGNvbnRkLuwHAAD//wAAPAAAAC8AAADuBwAAAAAAACwAAAAvAAAAGgAA AOIPAAAAAAAAGAAAAC8AAAABAAIAJAAAAAAAAAAAAxIAAAAAAAAAAADsBwAA//8AAFgAAAAwAAAA 7gcAAAAAAABIAAAAMAAAABoAAADjDwAAAAAAADQAAAAwAAAAAFwAAAD9lQD//wIAZAAAAAAAAAAA AAAAAAAAAAEAAABkAAAAAAAAAAAAAAAAAAAAAAEBAewHAAD//wAAKAAAADEAAADuBwAAAAAAABgA AAAxAAAAGgAAAOEPAAAAAAAABAAAADEAAAD/////rQ8AAAAAAAAAAAAAAAAAAMILAAD//wAAygQA ABMAAADDCwAAAAAAAAgAAAAAAAAADQASAAEAAADBCwAAAAAAACgAAAAAAAAA/f///wAAAAAAAAAA cPb///D6//+QCQAAkAYAAAAAAAD9////AQASAL0LAAABAAAAOAAAAAAAAAABAAABAAAA/gAAAP4B AQAAAAAAAAAAAP4AAAD+AQEAAAD+AAAAAAAAAAAAAAA5pzgAAAAAAAAAAKEPAAD//wAAIgQAAB4A AACgDwAAAAAAABAAAAAAAAAAOgAAAB0AAAAEgASAA+QSAKIPAAD//wAA8gMAAAAAAACjDwAAAAAA ACQAAAAAAAAAAQAAAATCkjADDOwEAID//wAAAACq9v//Dfv//1YJAABzBgAAtQ8AAAAAAAAEAAAA AAAAAAIAAADgDwAA//8AAJoDAAAAAAAA7gcAAAAAAABuAQAANQAAAEFyY2hpdGVjdHVyZSBkcmFm dCBkb2VzIG5vdCBhbnltb3JlIGFzc3VtZSBlaXRoZXIgc3RhdGUgb3IgbG9nIGJhc2VkIGFwcHJv YWNoIGluIHRoZSBkZXNpZ24NY2hhbmdlZCAiVXBkYXRlYWJsZSBSZXBsaWNhIiB0byAiTWFzdGVy IFJlcGxpY2GTDWFkZGVkoCBSaWNrIEh1YmVyJ3MgZGVzY3JpcHRpb24gb2YgbWFqb3IgcmVwbGlj YXRpb24gc3RhdGVzIGFuZCBzdGF0ZSBjaGFuZ2VzIChhcyBuZWVkZWQgYnkgTVJNKSBkb2N1bWVu dC6gIA1yZW1vdmUgcmVmZXJlbmNlcyB0byBwcmltYXJ5IHJlcGxpY2EgaW4gZGVmaW5pdGlvbnMg YW5kIG90aGVyIGRpc2N1c3Npb25zDUFkZGVkIGRpc2N1c3Npb24gb24gbmVlZCBmb3IgYXVkaXQg bG9nZ2luZ+wHAAD//wAAPAAAAC8AAADuBwAAAAAAACwAAAAvAAAAbgEAAOIPAAAAAAAAGAAAAC8A AAABAAIAHAAAAAAAAAAAARIAAAAAAAAAAADsBwAA//8AAHgBAAAwAAAA7gcAAAAAAABoAQAAMAAA AFwAAADjDwAAAAAAADQAAAAwAAAAAVwAAAD9lQD//wIAZAAAAAAAAAAAAAAAAAAAAAAAAABkAAAA FAAAAAAAAAAAAAAAAAEBATEAAADjDwAAAAAAADQAAAAwAAAAAVwAAAD9lQD//wIAZAAAAAAAAAAA AAAAAAAAAAAAAABkAAAAFAAAAAAAAAAAAAAAAAEBAW0AAADjDwAAAAAAADQAAAAwAAAAAVwAAAD9 lQD//wIAZAAAAAAAAAAAAAAAAAAAAAAAAABkAAAAFAAAAAAAAAAAAAAAAAEBAUoAAADjDwAAAAAA ADQAAAAwAAAAAVwAAAD9lQD//wIAZAAAAAAAAAAAAAAAAAAAAAAAAABkAAAAFAAAAAAAAAAAAAAA AAEBASoAAADjDwAAAAAAADQAAAAwAAAAAVwAAAD9lQD//wIAZAAAAAAAAAAAAAAAAAAAAAAAAABk AAAAFAAAAAAAAAAAAAAAAAEBAewHAAD//wAAKAAAADEAAADuBwAAAAAAABgAAAAxAAAAbgEAAOEP AAAAAAAABAAAADEAAAD/////rQ8AAAAAAAAAAAAAAAAAAO4DAAD//wAA2g4AABAAAADvAwAAAAAA AAgAAAAAAAAAAwEAAAAAAIDtAwAAAQAAABgAAAAAAAAAwPT//5D3//9ACwAAcAgAAAEBAAAB6hIA 8AMAAP//AACgBAAAJQAAAPEDAAAAAAAABAAAAAAAAAADAQAA7QMAAAEAAAAYAAAAAAAAAJD3///A 9P//cAgAAEALAAABAQAAAekSANkPAAD//wAASAAAAAAAAADaDwAAAAAAAAgAAAAAAAAAAQAAAAEB AQG6DwAA//8AAAAAAAAuAAAAug8AAP//AAAAAAAALwAAALoPAAD//wAAAAAAADAAAAD0AwAA//8A ADQAAAB4AAAA7wcAAAAAAAAkAAAAeAAAAAgAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8A srKyAMALAAD//wAAgAAAABwAAADBCwAAAAAAACgAAAAAAAAA/f///wAAAAAAXeAAkPf//8D0//9w CAAAQAsAAAAAAAC86BIAAAAAAL0LAAABAAAAOAAAAAAAAAABAAABAAAA/gAAAP4AAQAAAAAAAAAA AAAAAAAFAQEAAAD+AAAAAAAAAAAAAAg5pzgAAAAAAAAAALgLAAD//wAAKAMAABQAAADCCwAA//8A AOwAAAATAAAAwwsAAAAAAAAIAAAAAAAAABMAEgAAAAAAwQsAAAAAAAAoAAAAAAAAAP3///8AAAAA AAAAAF36//9t9v//owUAAOP+//8AAAAA/f///wABEgC9CwAAAQAAADgAAAAAAAAAAAAAAAAAAP7/ ///+AAEAAAAAAAD////+/////gEBAAAA/gAAAAAAAAAAAAAAOac4AAAAAAAAAACuDwAA//8AAEQA AAAfAAAArw8AAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADWDwAA//8AABQAAAAAAAAAwA8A AAAAAAAEAAAAAAAAAAMBAADCCwAA//8AABwCAAATAAAAwwsAAAAAAAAIAAAAAAAAAA4AEgABAAAA wQsAAAAAAAAoAAAAAAAAAP3///8AAAAAAAAAAND5//9w////MAYAAJAJAAAAAAAA/f///wEAEgC9 CwAAAQAAADgAAAAAAAAAAQAAAQAAAP4AAAD+AQEAAAAAAAAAAAD+AAAA/gEBAAAA/gAAAAAAAAAA AAAAOac4AAAAAAAAAAChDwAA//8AAHQBAAAeAAAAoA8AAAAAAAAQAAAAAAAAADoAAAAdAAAABIAE gAPkEgCiDwAA//8AAEQBAAAAAAAAow8AAAAAAAAkAAAAAAAAAAIAAAAEwpIwA+TsBACA//8AAAAA Cvr//43////2BQAAcwkAALUPAAAAAAAABAAAAAAAAAAAAAAA4A8AAP//AADsAAAAAAAAAOMPAAAA AAAANAAAADIAAAAAEAAAAP2VAP//AgBkAAAAAAAAAAAAAAAAAAAAAAAAAGQAAAAeAAAAAAAAAAAA AAAAAQEB4g8AAAAAAAAYAAAAMwAAAAEAAgAMAAAAAAAAAAABEgAAAAAAAAAAAO4HAAAAAAAAAAAA ADUAAADsBwAA//8AABAAAAAvAAAA7gcAAAAAAAAAAAAALwAAAOwHAAD//wAAEAAAADAAAADuBwAA AAAAAAAAAAAwAAAA7AcAAP//AAAQAAAAMQAAAO4HAAAAAAAAAAAAADEAAACtDwAAAAAAAAAAAAAA AAAA9wMAAAEAAAAMAAAAAAAAAAEAAAAMDQAAAAAAANkPAAD//wAAOAAAAAAAAADaDwAAAAAAAAgA AAAAAAAAAQAAAAEAAAG6DwAA//8AAAAAAAAuAAAAug8AAP//AAAAAAAAMAAAAPQDAAD//wAANAAA AHgAAADvBwAAAAAAACQAAAB4AAAACAAAAP///wAAAAAAgICAAAAAAAAAzJkAMzPMAMzM/wCysrIA wAsAAP//AACAAAAAHAAAAMELAAAAAAAAKAAAAAAAAAD9////AAAAAABd4ADA9P//kPf//0ALAABw CAAAAAAAAEzpEgAAAAAAvQsAAAEAAAA4AAAAAAAAAAEAAAEAAAD+AAAA/gABAAAAAAAAAAAAAAAA AAUBAQAAAP4AAAAAAAAAAAAACDmnOAAAAAAAAAAAuAsAAP//AACiCAAAFAAAAMILAAD//wAAQgIA ABMAAADDCwAAAAAAAAgAAAAAAAAADAASAAAAAADBCwAAAAAAACgAAAAAAAAA/f///wAAAAAAAAAA kPr//yD4///wAwAAoPn//wAAAAD9////AQASAL0LAAABAAAAOAAAAAAAAAABAAABAAAA/gAAAP4B AQAAAAAAAAAAAP4AAAD+AQEAAAD+AAAAAAAAAAAAAAA5pzgAAAAAAAAAAKEPAAD//wAAmgEAAB4A AACgDwAAAAAAABAAAAAAAAAAOgAAAB0AAAAEgASAE+QSAKIPAAD//wAAagEAAAAAAACjDwAAAAAA ACQAAAAAAAAAAAAAAATCkjATGOwEAID//wAAAADK+v//Pfj//7YDAACD+f//tQ8AAAAAAAAEAAAA AAAAAAEAAADgDwAA//8AABIBAAAAAAAA7gcAAAAAAAAGAAAANQAAAFN0YXR1c+wHAAD//wAAPAAA AC8AAADuBwAAAAAAACwAAAAvAAAABgAAAOIPAAAAAAAAGAAAAC8AAAABAAIAKAAAAAAAAAAAAxIA AAAAAAAAAADsBwAA//8AAFgAAAAwAAAA7gcAAAAAAABIAAAAMAAAAAYAAADjDwAAAAAAADQAAAAw AAAAAFwAAAD9lQD//wIAZAAAAAAAAAAAAAAAAAAAAAEAAABkAAAAAAAAAAAAAAAAAAAAAAEBAewH AAD//wAAKAAAADEAAADuBwAAAAAAABgAAAAxAAAABgAAAOEPAAAAAAAABAAAADEAAAD/////rQ8A AAAAAAAAAAAAAAAAAMILAAD//wAAQAYAABMAAADDCwAAAAAAAAgAAAAAAAAADQASAAEAAADBCwAA AAAAACgAAAAAAAAA/f///wAAAAAAAAAAcPb//wD6//+QCQAAUAcAAAAAAAD9////AQASAL0LAAAB AAAAOAAAAAAAAAABAAABAAAA/gAAAP4BAQAAAAAAAAAAAP4AAAD+AQEAAAD+AAAAAAAAAAAAAAA5 pzgAAAAAAAAAAKEPAAD//wAAmAUAAB4AAACgDwAAAAAAABAAAAAAAAAAOgAAAB0AAAAEgASAA+QS AKIPAAD//wAAaAUAAAAAAACjDwAAAAAAACQAAAAAAAAAAQAAAATCkjAD4OwEAID//wAAAACq9v// Hfr//1YJAAAzBwAAtQ8AAAAAAAAEAAAAAAAAAAMAAADgDwAA//8AABAFAAAAAAAA7gcAAAAAAAD8 AQAANQAAAFJlYWR5IGZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2YgYWxpZ25tZW50IHcvIGN1cnJl bnQgc3RhdGUgb2YgTERVUCByZXF1aXJlbWVudHMgYW5kIE1STQ1MYWNrIG9mIGNvbnNlbnN1cyBv biB0aGUgbWFpbCBsaXN0IG9uIHNvbWUga2V5IGRlZmluaXRpb25zIGFuZCBESVQgcGxhY2VtZW50 IG9mIExEVVAgbWV0YS1kYXRhIC0gbWFraW5nIHRoZW9yeSBvZiBvcGVyYXRpb24gaGFyZCB0byBn ZXQgY2xvc3VyZSBvbiAtIGV4YW1wbGVzOg1SZXBsaWNhdGlvbiBjb250ZXh0IChMRFVQKSB2cy4g cmVwbGljYXRpb24gYXJlYSANTERVUCBzdWJlbnRyeTogIGluIG9yIG91dD8gDURJVCBvcmdhbml6 YXRpb24gb2YgTERVUCBtZXRhLWRhdGE6IA1BbGwgcmVwbGljYXMgYW5kIGFncmVlbWVudHMgYXJl IHNpYmxpbmdzIHVuZGVyIGEgk3JlcGxpY2F0aW9uIGNvbnRleHSUIHdpdGggRE4gcmVmZXJlbmNl cw1SZXBsaWNhcyBvcmdhbml6ZWQgdG8gcmVmbGVjdCByZXBsaWNhL2FncmVlbWVudCBoaWVyYXJj aHnsBwAA//8AAJQAAAAvAAAA7gcAAAAAAACEAAAALwAAAPcAAADiDwAAAAAAABgAAAAvAAAAAQAC ABwAAAAAAAAAAAESAAAAAAAAAAAAcgAAAOIPAAAAAAAAGAAAAC8AAAABAAIAGAAAAAAAAAAAARIA AAAAAAAAAACTAAAA4g8AAAAAAAAYAAAALwAAAAEAAgAUAAAAAAAAAAABEgAAAAAAAAAAAOwHAAD/ /wAACAIAADAAAADuBwAAAAAAAPgBAAAwAAAAWAAAAOMPAAAAAAAANAAAADAAAAABXAAAAP2VAP// AgBkAAAAAAAAAAAAAAAAAAAAAAAAAGQAAAAUAAAAAAAAAAAAAAAAAQEBnwAAAOMPAAAAAAAANAAA ADAAAAABXAAAAP2VAP//AgBkAAAAAAAAAAAAAAAAAAAAAAAAAGQAAAAUAAAAAAAAAAAAAAAAAQEB MQAAAOMPAAAAAAAANAAAADAAAAABXAAAAP2WAP//AgBkAAAAAAAAAAAAAAABAAAAAAAAAGQAAAAU AAAAAAAAAAAAAAAAAQEBHAAAAOMPAAAAAAAANAAAADAAAAABXAAAAP2WAP//AgBkAAAAAAAAAAAA AAABAAAAAAAAAGQAAAAUAAAAAAAAAAAAAAAAAQEBJQAAAOMPAAAAAAAANAAAADAAAAABXAAAAP2W AP//AgBkAAAAAAAAAAAAAAABAAAAAAAAAGQAAAAUAAAAAAAAAAAAAAAAAQEBWgAAAOMPAAAAAAAA NAAAADAAAAABXAAAAP2VAP//AgBkAAAAAAAAAAAAAAACAAAAAAAAAGQAAAAUAAAAAAAAAAAAAAAA AQEBOQAAAOMPAAAAAAAANAAAADAAAAABXAAAAP2VAP//AgBkAAAAAAAAAAAAAAACAAAAAAAAAGQA AAAUAAAAAAAAAAAAAAAAAQEB7AcAAP//AAAoAAAAMQAAAO4HAAAAAAAAGAAAADEAAAD8AQAA4Q8A AAAAAAAEAAAAMQAAAP////+tDwAAAAAAAAAAAAAAAAAA7gMAAP//AADdDAAAEAAAAO8DAAAAAAAA CAAAAAAAAAAFAQAAAAAAgO0DAAABAAAAGAAAAAAAAADA9P//kPf//0ALAABwCAAAAQEAAAHqEgDw AwAA//8AAKAEAAAlAAAA8QMAAAAAAAAEAAAAAAAAAAUBAADtAwAAAQAAABgAAAAAAAAAkPf//8D0 //9wCAAAQAsAAAEBAAAB6RIA2Q8AAP//AABIAAAAAAAAANoPAAAAAAAACAAAAAAAAAABAAAAAQEB AboPAAD//wAAAAAAAC4AAAC6DwAA//8AAAAAAAAvAAAAug8AAP//AAAAAAAAMAAAAPQDAAD//wAA NAAAAHgAAADvBwAAAAAAACQAAAB4AAAACAAAAP///wAAAAAAgICAAAAAAAAAzJkAMzPMAMzM/wCy srIAwAsAAP//AACAAAAAHAAAAMELAAAAAAAAKAAAAAAAAAD9////AAAAAABd4ACQ9///wPT//3AI AABACwAAAAAAALzoEgAAAAAAvQsAAAEAAAA4AAAAAAAAAAEAAAEAAAD+AAAA/gABAAAAAAAAAAAA AAAAAAUBAQAAAP4AAAAAAAAAAAAACDmnOAAAAAAAAAAAuAsAAP//AAAoAwAAFAAAAMILAAD//wAA 7AAAABMAAADDCwAAAAAAAAgAAAAAAAAAEwASAAAAAADBCwAAAAAAACgAAAAAAAAA/f///wAAAAAA AAAAXfr//232//+jBQAA4/7//wAAAAD9////AAESAL0LAAABAAAAOAAAAAAAAAAAAAAAAAAA/v// //4AAQAAAAAAAP////7////+AQEAAAD+AAAAAAAAAAAAAAA5pzgAAAAAAAAAAK4PAAD//wAARAAA AB8AAACvDwAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANYPAAD//wAAFAAAAAAAAADADwAA AAAAAAQAAAAAAAAABQEAAMILAAD//wAAHAIAABMAAADDCwAAAAAAAAgAAAAAAAAADgASAAEAAADB CwAAAAAAACgAAAAAAAAA/f///wAAAAAAAAAA0Pn//3D///8wBgAAkAkAAAAAAAD9////AQASAL0L AAABAAAAOAAAAAAAAAABAAABAAAA/gAAAP4BAQAAAAAAAAAAAP4AAAD+AQEAAAD+AAAAAAAAAAAA AAA5pzgAAAAAAAAAAKEPAAD//wAAdAEAAB4AAACgDwAAAAAAABAAAAAAAAAAOgAAAB0AAAAEgASA A+QSAKIPAAD//wAARAEAAAAAAACjDwAAAAAAACQAAAAAAAAAAgAAAATCkjADmOwEAID//wAAAAAK +v//jf////YFAABzCQAAtQ8AAAAAAAAEAAAAAAAAAAAAAADgDwAA//8AAOwAAAAAAAAA4w8AAAAA AAA0AAAAMgAAAAAQAAAA/ZUA//8CAGQAAAAAAAAAAAAAAAAAAAAAAAAAZAAAAB4AAAAAAAAAAAAA AAABAQHiDwAAAAAAABgAAAAzAAAAAQACAAwAAAAAAAAAAAESAAAAAAAAAAAA7gcAAAAAAAAAAAAA NQAAAOwHAAD//wAAEAAAAC8AAADuBwAAAAAAAAAAAAAvAAAA7AcAAP//AAAQAAAAMAAAAO4HAAAA AAAAAAAAADAAAADsBwAA//8AABAAAAAxAAAA7gcAAAAAAAAAAAAAMQAAAK0PAAAAAAAAAAAAAAAA AAD3AwAAAQAAAAwAAAAAAAAAAQAAAAwNAAAAAAAA2Q8AAP//AAA4AAAAAAAAANoPAAAAAAAACAAA AAAAAAABAAAAAQAAAboPAAD//wAAAAAAAC4AAAC6DwAA//8AAAAAAAAwAAAA9AMAAP//AAA0AAAA eAAAAO8HAAAAAAAAJAAAAHgAAAAIAAAA////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKysgDA CwAA//8AAIAAAAAcAAAAwQsAAAAAAAAoAAAAAAAAAP3///8AAAAAAF3gAMD0//+Q9///QAsAAHAI AAAAAAAATOkSAAAAAAC9CwAAAQAAADgAAAAAAAAAAQAAAQAAAP4AAAD+AAEAAAAAAAAAAAAAAAAA BQEBAAAA/gAAAAAAAAAAAAAIOac4AAAAAAAAAAC4CwAA//8AAKUGAAAUAAAAwgsAAP//AABCAgAA EwAAAMMLAAAAAAAACAAAAAAAAAAMABIAAAAAAMELAAAAAAAAKAAAAAAAAAD9////AAAAAAAAAACg 9v//IPj//7AHAACg+f//AAAAAP3///8BABIAvQsAAAEAAAA4AAAAAAAAAAEAAAEAAAD+AAAA/gEB AAAAAAAAAAAA/gAAAP4BAQAAAP4AAAAAAAAAAAAAADmnOAAAAAAAAAAAoQ8AAP//AACaAQAAHgAA AKAPAAAAAAAAEAAAAAAAAAA6AAAAHQAAAASABIAT5BIAog8AAP//AABqAQAAAAAAAKMPAAAAAAAA JAAAAAAAAAAAAAAABMKSMBOo7AQAgP//AAAAANr2//89+P//dgcAAIP5//+1DwAAAAAAAAQAAAAA AAAAAQAAAOAPAAD//wAAEgEAAAAAAADuBwAAAAAAAAYAAAA1AAAAUGxhbnM/7AcAAP//AAA8AAAA LwAAAO4HAAAAAAAALAAAAC8AAAAGAAAA4g8AAAAAAAAYAAAALwAAAAEAAgAsAAAAAAAAAAADEgAA AAAAAAAAAOwHAAD//wAAWAAAADAAAADuBwAAAAAAAEgAAAAwAAAABgAAAOMPAAAAAAAANAAAADAA AAAAXAAAAP2VAP//AgBkAAAAAAAAAAAAAAAAAAAAAQAAAGQAAAAAAAAAAAAAAAAAAAAAAQEB7AcA AP//AAAoAAAAMQAAAO4HAAAAAAAAGAAAADEAAAAGAAAA4Q8AAAAAAAAEAAAAMQAAAP////+tDwAA AAAAAAAAAAAAAAAAwgsAAP//AABDBAAAEwAAAMMLAAAAAAAACAAAAAAAAAANABIAAQAAAMELAAAA AAAAKAAAAAAAAAD9////AAAAAAAAAABw9v//UPv//5AJAACABAAAAAAAAP3///8BABIAvQsAAAEA AAA4AAAAAAAAAAEAAAEAAAD+AAAA/gEBAAAAAAAAAAAA/gAAAP4BAQAAAP4AAAAAAAAAAAAAADmn OAAAAAAAAAAAoQ8AAP//AACbAwAAHgAAAKAPAAAAAAAAEAAAAAAAAAA6AAAAHQAAAASABIAD5BIA og8AAP//AABrAwAAAAAAAKMPAAAAAAAAJAAAAAAAAAABAAAABMKSMAOQ7AQAgP//AAAAAKr2//9t +///VgkAAGMEAAC1DwAAAAAAAAQAAAAAAAAAAwAAAOAPAAD//wAAEwMAAAAAAADuBwAAAAAAANcA AAA1AAAAV2lsbCBiZSByZWFkeSBmb3IgbGFzdCBjYWxsIGlmIHRoZSBpc3N1ZXMgbGlzdGVkIHJl Z2FyZGluZyBkYXRhIG1vZGVsIGFyZSBjbGFyaWZpZWQNUG90ZW50aWFsIGZvciBzaWduaWZpY2Fu dCB1cGRhdGVzOg1JZiBBQ0wgbW9kZWwgYWRvcHRzIFg1MDAgYWRtaW5pc3RyYXRpb24gbW9kZWws IHJlcGxpY2F0aW9uIHNob3VsZCB0b28NVGhvdWdodHMgYW5kIHN1Z2dlc3Rpb25zID/sBwAA//8A AJQAAAAvAAAA7gcAAAAAAACEAAAALwAAAHcAAADiDwAAAAAAABgAAAAvAAAAAQACACAAAAAAAAAA AAESAAAAAAAAAAAARgAAAOIPAAAAAAAAGAAAAC8AAAABAAIAHAAAAAAAAAAAARIAAAAAAAAAAAAa AAAA4g8AAAAAAAAYAAAALwAAAAEAAgAgAAAAAAAAAAABEgAAAAAAAAAAAOwHAAD//wAAMAEAADAA AADuBwAAAAAAACABAAAwAAAAVAAAAOMPAAAAAAAANAAAADAAAAABXAAAAP2VAP//AgBkAAAAAAAA AAAAAAAAAAAAAAAAAGQAAAAUAAAAAAAAAAAAAAAAAQEBIwAAAOMPAAAAAAAANAAAADAAAAABXAAA AP2VAP//AgBkAAAAAAAAAAAAAAAAAAAAAAAAAGQAAAAUAAAAAAAAAAAAAAAAAQEBRgAAAOMPAAAA AAAANAAAADAAAAABXAAAAP2WAP//AgBkAAAAAAAAAAAAAAABAAAAAAAAAGQAAAAUAAAAAAAAAAAA AAAAAQEBGgAAAOMPAAAAAAAANAAAADAAAAABXAAAAP2VAP//AgBkAAAAAAAAAAAAAAAAAAAAAAAA AGQAAAAUAAAAAAAAAAAAAAAAAQEB7AcAAP//AAAoAAAAMQAAAO4HAAAAAAAAGAAAADEAAADXAAAA 4Q8AAAAAAAAEAAAAMQAAAP////+tDwAAAAAAAAAAAAAAAAAA0AcAAP//AADZEAAACwAAANEHAAAA AAAABAAAAAAAAAABAAAA+AMAAP//AAC1EAAAEAAAAO8DAAAAAAAACAAAAAAAAAAAAACAAAAAAO0D AAABAAAAGAAAAAAAAADA9P//kPf//0ALAABwCAAAAQEAAAFd4ADvBwAAAAAAACQAAAA3AAAACAAA AAAA/wD///8AAAAAAP//AAD/mQAAAP//AP8AAACWlpYA7wcAAAAAAAAkAAAANwAAAAgAAAD///8A AAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAO8HAAAAAAAAJAAAADcAAAAIAAAA////AAAAAAAz MzMAAAAAAN3d3QCAgIAATU1NAOrq6gDvBwAAAAAAACQAAAA3AAAACAAAAP//zAAAAAAAZmYzAICA AAAzmTMAgAAAAAAzzAD/zGYA7wcAAAAAAAAkAAAANwAAAAgAAAD///8AAAAAAICAgAAAAAAA/8xm AAAA/wDMAMwAwMDAAO8HAAAAAAAAJAAAADcAAAAIAAAA////AAAAAACAgIAAAAAAAMDAwAAAZv8A /wAAAACZAADvBwAAAAAAACQAAAA3AAAACAAAAP///wAAAAAAgICAAAAAAAAzmf8Amf/MAMwAzACy srIA9wMAAAEAAAAMAAAAAAAAAAEAAAABAgYIBwAAANkPAAD//wAAOAAAAAAAAADaDwAAAAAAAAgA AAAAAAAAAQAAAAEAAAG6DwAA//8AAAAAAAAuAAAAug8AAP//AAAAAAAAMAAAAPQDAAD//wAANAAA AHgAAADvBwAAAAAAACQAAAB4AAAACAAAAP///wAAAAAAgICAAAAAAAAAzJkAMzPMAMzM/wCysrIA wAsAAP//AACAAAAAHAAAAMELAAAAAAAAKAAAAAAAAAD9////AAAAAABd4ADA9P//kPf//0ALAABw CAAAAAAAAEDpEgAAAAAAvQsAAAEAAAA4AAAAAAAAAAEAAAEAAAD+AAAA/gABAAAAAAAAAAAAAP// //4BAQAAAP4AAAAAAAAAAAAACDmnOAAAAAAAAAAAuAsAAP//AADBDQAAFAAAAMILAAD//wAAXAIA ABMAAADDCwAAAAAAAAgAAAAAAAAAAQASAAAAAADBCwAAAAAAACgAAAAAAAAA/f///wAAAAAAAAAA cPb//xD5//+QCQAA4Pv//wAAAAD9////AQASAL0LAAABAAAAOAAAAAAAAAABAAABAAAA/gAAAP4B AQAAAAAAAAAAAP4AAAD+AQEAAAD+AAAAAAAAAAAAAAA5pzgAAAAAAAAAAKEPAAD//wAAtAEAAB4A AACgDwAAAAAAABAAAAAAAAAAOgAAAB0AAAAEgASAE+QSAOQPAAD//wAAhAEAAAAAAACjDwAAAAAA ACQAAAAAAAAAAAAAAATCkjATbI4FAID//wAAAACq9v//Lfn//1YJAADD+///tQ8AAAAAAAAEAAAA AAAAAAEAAADgDwAA//8AACwBAAAAAAAA7gcAAAAAAAAgAAAANQAAAENsaWNrIHRvIGVkaXQgTWFz dGVyIHRpdGxlIHN0eWxl7AcAAP//AAA8AAAALwAAAO4HAAAAAAAALAAAAC8AAAAgAAAA4g8AAAAA AAAYAAAALwAAAAEAAgAsAAAAAAAAAAADEgAAAAAAAAAAAOwHAAD//wAAWAAAADAAAADuBwAAAAAA AEgAAAAwAAAAIAAAAOMPAAAAAAAANAAAADAAAAAAXAAAAP2VAP//AgBkAAAAAAAAAAAAAAAAAAAA AQAAAGQAAAAAAAAAAAAAAAAAAAAAAQEB7AcAAP//AAAoAAAAMQAAAO4HAAAAAAAAGAAAADEAAAAg AAAA4Q8AAAAAAAAEAAAAMQAAAP////+tDwAAAAAAAAAAAAAAAAAAwgsAAP//AABeBAAAEwAAAMML AAAAAAAACAAAAAAAAAACABIAAQAAAMELAAAAAAAAKAAAAAAAAAD9////AAAAAAAAAABw9v//cPz/ /5AJAACQBgAAAAAAAP3///8BABIAvQsAAAEAAAA4AAAAAAAAAAEAAAEAAAD+AAAA/gEBAAAAAAAA AAAA/gAAAP4BAQAAAP4AAAAAAAAAAAAAADmnOAAAAAAAAAAAoQ8AAP//AAC2AwAAHgAAAKAPAAAA AAAAEAAAAAAAAAA6AAAAHQAAAASABIAD5BIA5A8AAP//AACGAwAAAAAAAKMPAAAAAAAAJAAAAAAA AAABAAAABMKSMANsjgUAgP//AAAAAKr2//+N/P//VgkAAHMGAAC1DwAAAAAAAAQAAAAAAAAAAgAA AOAPAAD//wAALgMAAAAAAADuBwAAAAAAAFIAAAA1AAAAQ2xpY2sgdG8gZWRpdCBNYXN0ZXIgdGV4 dCBzdHlsZXMNU2Vjb25kIGxldmVsDVRoaXJkIGxldmVsDUZvdXJ0aCBsZXZlbA1GaWZ0aCBsZXZl bOwHAAD//wAA7AAAAC8AAADuBwAAAAAAANwAAAAvAAAAIQAAAOIPAAAAAAAAGAAAAC8AAAABAAIA IAAAAAAAAAAAARIAAAAAAAAAAAANAAAA4g8AAAAAAAAYAAAALwAAAAEAAgAcAAAAAAAAAAABEgAA AAAAAAAAAAwAAADiDwAAAAAAABgAAAAvAAAAAQACABgAAAAAAAAAAAESAAAAAAAAAAAADQAAAOIP AAAAAAAAGAAAAC8AAAABAAIAFAAAAAAAAAAAARIAAAAAAAAAAAALAAAA4g8AAAAAAAAYAAAALwAA AAEAAgAUAAAAAAAAAAABEgAAAAAAAAAAAOwHAAD//wAAeAEAADAAAADuBwAAAAAAAGgBAAAwAAAA IQAAAOMPAAAAAAAANAAAADAAAAABXAAAAP2VAP//AgBkAAAAAAAAAAAAAAAAAAAAAAAAAGQAAAAU AAAAAAAAAAAAAAAAAQEBDQAAAOMPAAAAAAAANAAAADAAAAABXAAAAP2WAP//AgBkAAAAAAAAAAAA AAABAAAAAAAAAGQAAAAUAAAAAAAAAAAAAAAAAQEBDAAAAOMPAAAAAAAANAAAADAAAAABXAAAAP2V AP//AgBkAAAAAAAAAAAAAAACAAAAAAAAAGQAAAAUAAAAAAAAAAAAAAAAAQEBDQAAAOMPAAAAAAAA NAAAADAAAAABXAAAAP2WAP//AgBkAAAAAAAAAAAAAAADAAAAAAAAAGQAAAAUAAAAAAAAAAAAAAAA AQEBCwAAAOMPAAAAAAAANAAAADAAAAABXAAAAP27AP//AgBkAAAAAAAAAAAAAAAEAAAAAAAAAGQA AAAUAAAAAAAAAAAAAAAAAQEB7AcAAP//AAAoAAAAMQAAAO4HAAAAAAAAGAAAADEAAABSAAAA4Q8A AAAAAAAEAAAAMQAAAP////+tDwAAAAAAAAAAAAAAAAAAwgsAAP//AAA9AgAAEwAAAMMLAAAAAAAA CAAAAAAAAAAGARIAAgAAAMELAAAAAAAAKAAAAAAAAAD9////AAAAAAAAAABw9v//8AYAACD7//8Q CAAAAAAAAP3///8BABIAvQsAAAEAAAA4AAAAAAAAAAEAAAEAAAD+AAAA/gEBAAAAAAAAAAAA/gAA AP4BAQAAAP4AAAAAAAAAAAAAADmnOAAAAAAAAAAAoQ8AAP//AACVAQAAHgAAAKAPAAAAAAAAEAAA AAAAAAA6AAAAHQAAAASABIAD5BIAog8AAP//AABlAQAAAAAAAKMPAAAAAAAAJAAAAAAAAAAEAAAA BMKSMANsjgUAgP//AAAAAKr2//8NBwAA5vr///MHAAC1DwAAAAAAAAQAAAAAAAAAAAAAAOAPAAD/ /wAADQEAAAAAAADuBwAAAAAAAAEAAAA1AAAAKuwHAAD//wAAPAAAAC8AAADuBwAAAAAAACwAAAAv AAAAAQAAAOIPAAAAAAAAGAAAAC8AAAABAAIADgAAAIAAAAAAARIAAAAAAAAAAADsBwAA//8AAFgA AAAwAAAA7gcAAAAAAABIAAAAMAAAAAEAAADjDwAAAAAAADQAAAAwAAAAAFwAAAD9lQD//wIAZAAA AAAAAAAAAAAAAAAAAAAAAABkAAAAAAAAAAAAAAAAAAAAAAEBAewHAAD//wAAKAAAADEAAADuBwAA AAAAABgAAAAxAAAAAQAAAOEPAAAAAAAABAAAADEAAAABAAAArQ8AAAAAAAAAAAAAAAAAAMILAAD/ /wAAPQIAABMAAADDCwAAAAAAAAgAAAAAAAAACAISAAMAAADBCwAAAAAAACgAAAAAAAAA/f///wAA AAAAAAAAcPz///AGAACQAwAAEAgAAAAAAAD9////AQASAL0LAAABAAAAOAAAAAAAAAABAAABAAAA /gAAAP4BAQAAAAAAAAAAAP4AAAD+AQEAAAD+AAAAAAAAAAAAAAA5pzgAAAAAAAAAAKEPAAD//wAA lQEAAB4AAACgDwAAAAAAABAAAAAAAAAAOgAAAB0AAAAEgASAA+QSAKIPAAD//wAAZQEAAAAAAACj DwAAAAAAACQAAAAAAAAABAAAAATCkjADgI4FAID//wAAAACq/P//DQcAAFYDAADzBwAAtQ8AAAAA AAAEAAAAAAAAAAAAAADgDwAA//8AAA0BAAAAAAAA7gcAAAAAAAABAAAANQAAACrsBwAA//8AADwA AAAvAAAA7gcAAAAAAAAsAAAALwAAAAEAAADiDwAAAAAAABgAAAAvAAAAAQACAA4AAACAAAAAAAES AAAAAAAAAAAA7AcAAP//AABYAAAAMAAAAO4HAAAAAAAASAAAADAAAAABAAAA4w8AAAAAAAA0AAAA MAAAAABcAAAA/ZUA//8CAGQAAAAAAAAAAAAAAAAAAAABAAAAZAAAAAAAAAAAAAAAAAAAAAABAQHs BwAA//8AACgAAAAxAAAA7gcAAAAAAAAYAAAAMQAAAAEAAADhDwAAAAAAAAQAAAAxAAAAAgAAAK0P AAAAAAAAAAAAAAAAAADCCwAA//8AAD0CAAATAAAAwwsAAAAAAAAIAAAAAAAAAAcCEgAEAAAAwQsA AAAAAAAoAAAAAAAAAP3///8AAAAAAAAAAOAEAADwBgAAkAkAABAIAAAAAAAA/f///wEAEgC9CwAA AQAAADgAAAAAAAAAAQAAAQAAAP4AAAD+AQEAAAAAAAAAAAD+AAAA/gEBAAAA/gAAAAAAAAAAAAAA Oac4AAAAAAAAAAChDwAA//8AAJUBAAAeAAAAoA8AAAAAAAAQAAAAAAAAADoAAAAdAAAABIAEgAPk EgCiDwAA//8AAGUBAAAAAAAAow8AAAAAAAAkAAAAAAAAAAQAAAAEwpIwA3iOBQCA//8AAAAAGgUA AA0HAABWCQAA8wcAALUPAAAAAAAABAAAAAAAAAAAAAAA4A8AAP//AAANAQAAAAAAAO4HAAAAAAAA AQAAADUAAAAq7AcAAP//AAA8AAAALwAAAO4HAAAAAAAALAAAAC8AAAABAAAA4g8AAAAAAAAYAAAA LwAAAAEAAgAOAAAAgAAAAAABEgAAAAAAAAAAAOwHAAD//wAAWAAAADAAAADuBwAAAAAAAEgAAAAw AAAAAQAAAOMPAAAAAAAANAAAADAAAAAAXAAAAP2VAP//AgBkAAAAAAAAAAAAAAAAAAAAAgAAAGQA AAAAAAAAAAAAAAAAAAAAAQEB7AcAAP//AAAoAAAAMQAAAO4HAAAAAAAAGAAAADEAAAABAAAA4Q8A AAAAAAAEAAAAMQAAAAMAAACtDwAAAAAAAAAAAAAAAAAA8AMAAP//AAAWEAAAJwAAAPEDAAAAAAAA BAAAAAAAAAAAAACA7QMAAAEAAAAYAAAAAAAAAJD3///A9P//cAgAAEALAAABAQAAAas1MNkPAAD/ /wAASAAAAAAAAADaDwAAAAAAAAgAAAAAAAAAAQAAAAEBAQG6DwAA//8AAAAAAAAuAAAAug8AAP// AAAAAAAALwAAALoPAAD//wAAAAAAADAAAAD0AwAA//8AADQAAAB4AAAA7wcAAAAAAAAkAAAAeAAA AAgAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAMALAAD//wAAgAAAABwAAADBCwAA AAAAACgAAAAAAAAA/f///wAAAAAAXeAAkPf//8D0//9wCAAAQAsAAAAAAABA6RIAAAAAAL0LAAAB AAAAOAAAAAAAAAABAAABAAAA/gAAAP4AAQAAAAAAAAAAAAD////+AQEAAAD+AAAAAAAAAAAAAAg5 pzgAAAAAAAAAALgLAAD//wAAng4AABQAAADCCwAA//8AAD0CAAATAAAAwwsAAAAAAAAIAAAAAAAA AAkCEgAAAAAAwQsAAAAAAAAoAAAAAAAAAP3///8AAAAAAAAAAJD3///A9P//4P7//+D1//8AAAAA /f///wEAEgC9CwAAAQAAADgAAAAAAAAAAQAAAQAAAP4AAAD+AQEAAAAAAAAAAAD+AAAA/gEBAAAA /gAAAAAAAAAAAAAAOac4AAAAAAAAAAChDwAA//8AAJUBAAAeAAAAoA8AAAAAAAAQAAAAAAAAADoA AAAdAAAABIAEgAPkEgCiDwAA//8AAGUBAAAAAAAAow8AAAAAAAAkAAAAAAAAAAQAAAAEwpIwA7yO BQCA//8AAAAAyvf//930//+m/v//w/X//7UPAAAAAAAABAAAAAAAAAAAAAAA4A8AAP//AAANAQAA AAAAAO4HAAAAAAAAAQAAADUAAAAq7AcAAP//AAA8AAAALwAAAO4HAAAAAAAALAAAAC8AAAABAAAA 4g8AAAAAAAAYAAAALwAAAAEAAgAMAAAAgAAAAAABEgAAAAAAAAAAAOwHAAD//wAAWAAAADAAAADu BwAAAAAAAEgAAAAwAAAAAQAAAOMPAAAAAAAANAAAADAAAAAAXAAAAP2VAP//AgBkAAAAAAAAAAAA AAAAAAAAAAAAAGQAAAAAAAAAAAAAAAAAAAAAAQEB7AcAAP//AAAoAAAAMQAAAO4HAAAAAAAAGAAA ADEAAAABAAAA4Q8AAAAAAAAEAAAAMQAAAAAAAACtDwAAAAAAAAAAAAAAAAAAwgsAAP//AAA9AgAA EwAAAMMLAAAAAAAACAAAAAAAAAAGABIAAQAAAMELAAAAAAAAKAAAAAAAAAD9////AAAAAAAAAAAg AQAAwPT//3AIAADg9f//AAAAAP3///8BABIAvQsAAAEAAAA4AAAAAAAAAAEAAAEAAAD+AAAA/gEB AAAAAAAAAAAA/gAAAP4BAQAAAP4AAAAAAAAAAAAAADmnOAAAAAAAAAAAoQ8AAP//AACVAQAAHgAA AKAPAAAAAAAAEAAAAAAAAAA6AAAAHQAAAASABIAD5BIAog8AAP//AABlAQAAAAAAAKMPAAAAAAAA JAAAAAAAAAAEAAAABMKSMAOEjgUAgP//AAAAAFoBAADd9P//NggAAMP1//+1DwAAAAAAAAQAAAAA AAAAAAAAAOAPAAD//wAADQEAAAAAAADuBwAAAAAAAAEAAAA1AAAAKuwHAAD//wAAPAAAAC8AAADu BwAAAAAAACwAAAAvAAAAAQAAAOIPAAAAAAAAGAAAAC8AAAABAAIADAAAAIAAAAAAARIAAAAAAAAA AADsBwAA//8AAFgAAAAwAAAA7gcAAAAAAABIAAAAMAAAAAEAAADjDwAAAAAAADQAAAAwAAAAAFwA AAD9lQD//wIAZAAAAAAAAAAAAAAAAAAAAAIAAABkAAAAAAAAAAAAAAAAAAAAAAEBAewHAAD//wAA KAAAADEAAADuBwAAAAAAABgAAAAxAAAAAQAAAOEPAAAAAAAABAAAADEAAAABAAAArQ8AAAAAAAAA AAAAAAAAAMILAAD//wAA7AAAABMAAADDCwAAAAAAAAgAAAAAAAAABAASAAIAAADBCwAAAAAAACgA AAAAAAAA/f///wAAAAAAAAAAXfr//232//+jBQAA4/7//wAAAAD9////AAESAL0LAAABAAAAOAAA AAAAAAAAAAAAAAAA/v////4AAQAAAAAAAP////7////+AQEAAAD+AAAAAAAAAAAAAAA5pzgAAAAA AAAAAK4PAAD//wAARAAAAB8AAACvDwAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANYPAAD/ /wAAFAAAAAAAAADADwAAAAAAAAQAAAAAAAAAAAAAgMILAAD//wAAXgQAABMAAADDCwAAAAAAAAgA AAAAAAAABQISAAMAAADBCwAAAAAAACgAAAAAAAAA/f///wAAAAAAAAAA0Pn//3D///8wBgAAkAkA AAAAAAD9////AQASAL0LAAABAAAAOAAAAAAAAAABAAABAAAA/gAAAP4BAQAAAAAAAAAAAP4AAAD+ AQEAAAD+AAAAAAAAAAAAAAA5pzgAAAAAAAAAAKEPAAD//wAAtgMAAB4AAACgDwAAAAAAABAAAAAA AAAAOgAAAB0AAAAEgASAA+QSAKIPAAD//wAAhgMAAAAAAACjDwAAAAAAACQAAAAAAAAAAgAAAATC kjADHI4FAID//wAAAAAK+v//jf////YFAABzCQAAtQ8AAAAAAAAEAAAAAAAAAAAAAADgDwAA//8A AC4DAAAAAAAA7gcAAAAAAABSAAAANQAAAENsaWNrIHRvIGVkaXQgTWFzdGVyIHRleHQgc3R5bGVz DVNlY29uZCBsZXZlbA1UaGlyZCBsZXZlbA1Gb3VydGggbGV2ZWwNRmlmdGggbGV2ZWzsBwAA//8A AOwAAAAvAAAA7gcAAAAAAADcAAAALwAAACEAAADiDwAAAAAAABgAAAAvAAAAAQACAAwAAAAAAAAA AAESAAAAAAAAAAAADQAAAOIPAAAAAAAAGAAAAC8AAAABAAIADAAAAAAAAAAAARIAAAAAAAAAAAAM AAAA4g8AAAAAAAAYAAAALwAAAAEAAgAMAAAAAAAAAAABEgAAAAAAAAAAAA0AAADiDwAAAAAAABgA AAAvAAAAAQACAAwAAAAAAAAAAAESAAAAAAAAAAAACwAAAOIPAAAAAAAAGAAAAC8AAAABAAIADAAA AAAAAAAAARIAAAAAAAAAAADsBwAA//8AAHgBAAAwAAAA7gcAAAAAAABoAQAAMAAAACEAAADjDwAA AAAAADQAAAAwAAAAAFwAAAD9lQD//wIAZAAAAAAAAAAAAAAAAAAAAAAAAABkAAAAHgAAAAAAAAAA AAAAAAEBAQ0AAADjDwAAAAAAADQAAAAwAAAAAFwAAAD9lQD//wIAZAAAAAAAAAAAAAAAAQAAAAAA AABkAAAAHgAAAAAAAAAAAAAAAAEBAQwAAADjDwAAAAAAADQAAAAwAAAAAFwAAAD9lQD//wIAZAAA AAAAAAAAAAAAAgAAAAAAAABkAAAAHgAAAAAAAAAAAAAAAAEBAQ0AAADjDwAAAAAAADQAAAAwAAAA AFwAAAD9lQD//wIAZAAAAAAAAAAAAAAAAwAAAAAAAABkAAAAHgAAAAAAAAAAAAAAAAEBAQsAAADj DwAAAAAAADQAAAAwAAAAAFwAAAD9lQD//wIAZAAAAAAAAAAAAAAABAAAAAAAAABkAAAAHgAAAAAA AAAAAAAAAAEBAewHAAD//wAAKAAAADEAAADuBwAAAAAAABgAAAAxAAAAUgAAAOEPAAAAAAAABAAA ADEAAAD/////rQ8AAAAAAAAAAAAAAAAAAMILAAD//wAAPQIAABMAAADDCwAAAAAAAAgAAAAAAAAA CAISAAQAAADBCwAAAAAAACgAAAAAAAAA/f///wAAAAAAAAAAkPf//yAKAADg/v//QAsAAAAAAAD9 ////AQASAL0LAAABAAAAOAAAAAAAAAABAAABAAAA/gAAAP4BAQAAAAAAAAAAAP4AAAD+AQEAAAD+ AAAAAAAAAAAAAAA5pzgAAAAAAAAAAKEPAAD//wAAlQEAAB4AAACgDwAAAAAAABAAAAAAAAAAOgAA AB0AAAAEgASAI+QSAKIPAAD//wAAZQEAAAAAAACjDwAAAAAAACQAAAAAAAAABAAAAATCkjAjEI4F AID//wAAAADK9///PQoAAKb+//8jCwAAtQ8AAAAAAAAEAAAAAAAAAAAAAADgDwAA//8AAA0BAAAA AAAA7gcAAAAAAAABAAAANQAAACrsBwAA//8AADwAAAAvAAAA7gcAAAAAAAAsAAAALwAAAAEAAADi DwAAAAAAABgAAAAvAAAAAQACAAwAAACAAAAAAAESAAAAAAAAAAAA7AcAAP//AABYAAAAMAAAAO4H AAAAAAAASAAAADAAAAABAAAA4w8AAAAAAAA0AAAAMAAAAABcAAAA/ZUA//8CAGQAAAAAAAAAAAAA AAAAAAAAAAAAZAAAAAAAAAAAAAAAAAAAAAABAQHsBwAA//8AACgAAAAxAAAA7gcAAAAAAAAYAAAA MQAAAAEAAADhDwAAAAAAAAQAAAAxAAAAAgAAAK0PAAAAAAAAAAAAAAAAAADCCwAA//8AAD0CAAAT AAAAwwsAAAAAAAAIAAAAAAAAAAcCEgAFAAAAwQsAAAAAAAAoAAAAAAAAAP3///8AAAAAAAAAACAB AAAgCgAAcAgAAEALAAAAAAAA/f///wEAEgC9CwAAAQAAADgAAAAAAAAAAQAAAQAAAP4AAAD+AQEA AAAAAAAAAAD+AAAA/gEBAAAA/gAAAAAAAAAAAAAAOac4AAAAAAAAAAChDwAA//8AAJUBAAAeAAAA oA8AAAAAAAAQAAAAAAAAADoAAAAdAAAABIAEgCPkEgCiDwAA//8AAGUBAAAAAAAAow8AAAAAAAAk AAAAAAAAAAQAAAAEwpIwIxSOBQCA//8AAAAAWgEAAD0KAAA2CAAAIwsAALUPAAAAAAAABAAAAAAA AAAAAAAA4A8AAP//AAANAQAAAAAAAO4HAAAAAAAAAQAAADUAAAAq7AcAAP//AAA8AAAALwAAAO4H AAAAAAAALAAAAC8AAAABAAAA4g8AAAAAAAAYAAAALwAAAAEAAgAMAAAAgAAAAAABEgAAAAAAAAAA AOwHAAD//wAAWAAAADAAAADuBwAAAAAAAEgAAAAwAAAAAQAAAOMPAAAAAAAANAAAADAAAAAAXAAA AP2VAP//AgBkAAAAAAAAAAAAAAAAAAAAAgAAAGQAAAAAAAAAAAAAAAAAAAAAAQEB7AcAAP//AAAo AAAAMQAAAO4HAAAAAAAAGAAAADEAAAABAAAA4Q8AAAAAAAAEAAAAMQAAAAMAAACtDwAAAAAAAAAA AAAAAAAAyQ8AAP//AACYCgAAGwAAAO0DAAABAAAAGAAAAAAAAACQ9///wPT//3AIAABACwAAAQEA AAGrNTDZDwAA//8AAEgAAAAAAAAA2g8AAAAAAAAIAAAAAAAAAAEAAAABAQEBug8AAP//AAAAAAAA LgAAALoPAAD//wAAAAAAAC8AAAC6DwAA//8AAAAAAAAwAAAA9AMAAP//AAA0AAAAeAAAAO8HAAAA AAAAJAAAAHgAAAAIAAAA////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKysgDACwAA//8AAIAA AAAcAAAAwQsAAAAAAAAoAAAAAAAAAP3///8AAAAAAF3gAJD3///A9P//cAgAAEALAAAAAAAAQOkS AAAAAAC9CwAAAQAAADgAAAAAAAAAAQAAAQAAAP4AAAD+AAEAAAAAAAAAAAAA/////gEBAAAA/gAA AAAAAAAAAAAIOac4AAAAAAAAAAC4CwAA//8AADQJAAAUAAAAwgsAAP//AAA9AgAAEwAAAMMLAAAA AAAACAAAAAAAAAAJAhIAAAAAAMELAAAAAAAAKAAAAAAAAAD9////AAAAAAAAAACQ9///wPT//+D+ ///g9f//AAAAAP3///8BABIAvQsAAAEAAAA4AAAAAAAAAAEAAAEAAAD+AAAA/gEBAAAAAAAAAAAA /gAAAP4BAQAAAP4AAAAAAAAAAAAAADmnOAAAAAAAAAAAoQ8AAP//AACVAQAAHgAAAKAPAAAAAAAA EAAAAAAAAAA6AAAAHQAAAASABIAD5BIAog8AAP//AABlAQAAAAAAAKMPAAAAAAAAJAAAAAAAAAAE AAAABMKSMANEjgUAgP//AAAAAMr3///d9P//pv7//8P1//+1DwAAAAAAAAQAAAAAAAAAAAAAAOAP AAD//wAADQEAAAAAAADuBwAAAAAAAAEAAAA1AAAAKuwHAAD//wAAPAAAAC8AAADuBwAAAAAAACwA AAAvAAAAAQAAAOIPAAAAAAAAGAAAAC8AAAABAAIADAAAAIAAAAAAARIAAAAAAAAAAADsBwAA//8A AFgAAAAwAAAA7gcAAAAAAABIAAAAMAAAAAEAAADjDwAAAAAAADQAAAAwAAAAAFwAAAD9lQD//wIA ZAAAAAAAAAAAAAAAAAAAAAAAAABkAAAAAAAAAAAAAAAAAAAAAAEBAewHAAD//wAAKAAAADEAAADu BwAAAAAAABgAAAAxAAAAAQAAAOEPAAAAAAAABAAAADEAAAAAAAAArQ8AAAAAAAAAAAAAAAAAAMIL AAD//wAAPQIAABMAAADDCwAAAAAAAAgAAAAAAAAABgISAAEAAADBCwAAAAAAACgAAAAAAAAA/f// /wAAAAAAAAAAIAEAAMD0//9wCAAA4PX//wAAAAD9////AQASAL0LAAABAAAAOAAAAAAAAAABAAAB AAAA/gAAAP4BAQAAAAAAAAAAAP4AAAD+AQEAAAD+AAAAAAAAAAAAAAA5pzgAAAAAAAAAAKEPAAD/ /wAAlQEAAB4AAACgDwAAAAAAABAAAAAAAAAAOgAAAB0AAAAEgASAA+QSAKIPAAD//wAAZQEAAAAA AACjDwAAAAAAACQAAAAAAAAABAAAAATCkjADPOwEAID//wAAAABaAQAA3fT//zYIAADD9f//tQ8A AAAAAAAEAAAAAAAAAAAAAADgDwAA//8AAA0BAAAAAAAA7gcAAAAAAAABAAAANQAAACrsBwAA//8A ADwAAAAvAAAA7gcAAAAAAAAsAAAALwAAAAEAAADiDwAAAAAAABgAAAAvAAAAAQACAAwAAACAAAAA AAESAAAAAAAAAAAA7AcAAP//AABYAAAAMAAAAO4HAAAAAAAASAAAADAAAAABAAAA4w8AAAAAAAA0 AAAAMAAAAABcAAAA/ZUA//8CAGQAAAAAAAAAAAAAAAAAAAACAAAAZAAAAAAAAAAAAAAAAAAAAAAB AQHsBwAA//8AACgAAAAxAAAA7gcAAAAAAAAYAAAAMQAAAAEAAADhDwAAAAAAAAQAAAAxAAAAAQAA AK0PAAAAAAAAAAAAAAAAAADCCwAA//8AAD0CAAATAAAAwwsAAAAAAAAIAAAAAAAAAAgCEgACAAAA wQsAAAAAAAAoAAAAAAAAAP3///8AAAAAAAAAAJD3//8gCgAA4P7//0ALAAAAAAAA/f///wEAEgC9 CwAAAQAAADgAAAAAAAAAAQAAAQAAAP4AAAD+AQEAAAAAAAAAAAD+AAAA/gEBAAAA/gAAAAAAAAAA AAAAOac4AAAAAAAAAAChDwAA//8AAJUBAAAeAAAAoA8AAAAAAAAQAAAAAAAAADoAAAAdAAAABIAE gCPkEgCiDwAA//8AAGUBAAAAAAAAow8AAAAAAAAkAAAAAAAAAAQAAAAEwpIwIzzsBACA//8AAAAA yvf//z0KAACm/v//IwsAALUPAAAAAAAABAAAAAAAAAAAAAAA4A8AAP//AAANAQAAAAAAAO4HAAAA AAAAAQAAADUAAAAq7AcAAP//AAA8AAAALwAAAO4HAAAAAAAALAAAAC8AAAABAAAA4g8AAAAAAAAY AAAALwAAAAEAAgAMAAAAgAAAAAABEgAAAAAAAAAAAOwHAAD//wAAWAAAADAAAADuBwAAAAAAAEgA AAAwAAAAAQAAAOMPAAAAAAAANAAAADAAAAAAXAAAAP2VAP//AgBkAAAAAAAAAAAAAAAAAAAAAAAA AGQAAAAAAAAAAAAAAAAAAAAAAQEB7AcAAP//AAAoAAAAMQAAAO4HAAAAAAAAGAAAADEAAAABAAAA 4Q8AAAAAAAAEAAAAMQAAAAIAAACtDwAAAAAAAAAAAAAAAAAAwgsAAP//AAA9AgAAEwAAAMMLAAAA AAAACAAAAAAAAAAHAhIAAwAAAMELAAAAAAAAKAAAAAAAAAD9////AAAAAAAAAAAgAQAAIAoAAHAI AABACwAAAAAAAP3///8BABIAvQsAAAEAAAA4AAAAAAAAAAEAAAEAAAD+AAAA/gEBAAAAAAAAAAAA /gAAAP4BAQAAAP4AAAAAAAAAAAAAADmnOAAAAAAAAAAAoQ8AAP//AACVAQAAHgAAAKAPAAAAAAAA EAAAAAAAAAA6AAAAHQAAAASABIAj5BIAog8AAP//AABlAQAAAAAAAKMPAAAAAAAAJAAAAAAAAAAE AAAABMKSMCNM7AQAgP//AAAAAFoBAAA9CgAANggAACMLAAC1DwAAAAAAAAQAAAAAAAAAAAAAAOAP AAD//wAADQEAAAAAAADuBwAAAAAAAAEAAAA1AAAAKuwHAAD//wAAPAAAAC8AAADuBwAAAAAAACwA AAAvAAAAAQAAAOIPAAAAAAAAGAAAAC8AAAABAAIADAAAAIAAAAAAARIAAAAAAAAAAADsBwAA//8A AFgAAAAwAAAA7gcAAAAAAABIAAAAMAAAAAEAAADjDwAAAAAAADQAAAAwAAAAAFwAAAD9lQD//wIA ZAAAAAAAAAAAAAAAAAAAAAIAAABkAAAAAAAAAAAAAAAAAAAAAAEBAewHAAD//wAAKAAAADEAAADu BwAAAAAAABgAAAAxAAAAAQAAAOEPAAAAAAAABAAAADEAAAADAAAArQ8AAAAAAAAAAAAAAAAAANAH AAD//wAAugAAAAwAAADRBwAAAAAAAAQAAAAAAAAAAgAAAPoDAAD//wAAlgAAALQAAAD+AwAAAQAA AAIAAAAAAAAAAAHqBwAA//8AADAAAAAAAAAA+wMAAAAAAAAIAAAAAAAAAAAAAAAAAAAA+wMAAAAA AAAIAAAAAAAAAAEAAAAAAAAA/QMAAAEAAAA0AAAAAAAAAEAAAABkAAAAQAAAAGQAAAABAAAAAQAA AAEAAAABAAAAAAAAAAAAAABz+P//tvn//wEA4AACBAAA//8AACQAAABkAAAA4wcAAP//AAAUAAAA ZQAAAOkHAAAAAAAABAAAACwAAAABAAAA6gMAAAAAAAAAAAAAAAAAAAoAAAAAAAAACAAAAAAAAAAB AAAABQEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAIgQAAAAAAAAA AAAAAAAAAAEAAAABAAAAAQAAABQAAABQb3dlclBvaW50IERvY3VtZW50AAEAAAAAAAAAAAAOAAAA RWR3YXJkcyBFIFJlZWRzYW4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAATWljcm9zb2Z0IChSKSBQb3dlclBvaW50IChSKSBXaW5kb3dzICAABwEAAPADAABfwJHjAQAA AAAAAAAAAAAAAP7/AAAEAAIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAA APAJAAALAAAAAQAAAGAAAAACAAAAaAAAAAQAAACQAAAACAAAAKwAAAAJAAAAyAAAABIAAADUAAAA CgAAAPQAAAAMAAAAAAEAAA0AAAAMAQAADwAAABgBAAARAAAAIAEAAAIAAADkBAAAHgAAAB4AAABM REFQIFJlcGxpY2F0aW9uIEFyY2hpdGVjdHVyZQBhAB4AAAASAAAAVXBwaWxpIFNyaW5pdmFzYW4A cmMeAAAAEgAAAFVwcGlsaSBTcmluaXZhc2FuAHJjHgAAAAMAAAAxNABpHgAAABUAAABNaWNyb3Nv ZnQgUG93ZXJQb2ludABpdGVAAAAAgP4GFwkAAABAAAAAEGnPeLrPwQFAAAAASABlAGEAZABlAHIA AAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAAA4AAgD/ //////////////8VAAAAFgAAABcAAAAYAAAAGQAAAAAAAAAAAAAAAAAAAAAAAAACAAAAOQAAAP// //8FAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAA//////////////////// ////////////KAACAP//////////////////////////////////////////AAAAAAAAAAAAAAAA AAAAAAMAAAAgCgAA/////wUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwBy AG0AYQB0AGkAbwBuAAAA//////////84AAIA//////////////////////////////////////// //8AAAAAAAAAAAAAAAAAAAAALAAAABwCAAD///////////////////////////////////////// /////////////////////////////////////////////////wAAAAD///////////////////// //////////////////////////////////////////////////////////9ADtjgxM/BAQMAAADu AAAARwAAAMgIAAD/////AwAAAAgAiRBnDAAAAQAJAAADXAQAAAYAMwAAAAAAEQAAACYGDwAYAP// //8AABAAAAAAAAAAAADAAwAA0AIAAAkAAAAmBg8ACAD/////AgAAABcAAAAmBg8AIwD/////BAAb AFROUFAUALwAvgAyAAAA//9PABQAAABNAGkAAAAKAAAAJgYPAAoAVE5QUAAAAgD0AwkAAAAmBg8A CAD/////AwAAAA8AAAAmBg8AFABUTlBQBAAMAAEAAAABAAAAAAAAAAUAAAALAgAAAAAFAAAADALQ AsADBQAAAAQBDQAAAAcAAAD8AgAA////AAAABAAAAC0BAAAIAAAA+gIFAAEAAAAAAAAABAAAAC0B AQAEAAAALQEAAAkAAAAdBiEA8ADQAsADAAAAAAQAAAAtAQAABwAAAPwCAAD///8AAAAEAAAALQEC AAQAAADwAQAACAAAAPoCAAAAAAAAAAAAAAQAAAAtAQAAEAAAACYGDwAWAP////8AAEcAAACPAgAA EQEAAMECAAAIAAAAJgYPAAYA/////wEAHAAAAPsCAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAADa BQrnIYLtdyqC7XfAZ+932gUK5wAACgAEAAAALQEDAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAAIB AgAAABAAAAAmBg8AFgD/////AABHAQAAjwIAAHkCAADBAgAACAAAACYGDwAGAP////8BAAUAAAAJ AgAAAAIFAAAAFAIAAAAABQAAAAIBAgAAAAcAAAD8AgEAAAAAAAAABAAAAC0BBAAEAAAALQEBAAcA AAAbBCEBgQOoAFAABAAAAC0BAgAEAAAALQEAAAUAAAAJAgAAAAIFAAAAFAIAAAAAHAAAAPsCxf8A AAAAAACQAQAAAAAAQAASVGltZXMgTmV3IFJvbWFuACqC7XfAZ+93tA0KkwAACgAEAAAALQEFAAQA AADwAQMABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAADMAAAAyCvkAcwAd AAAATERBUCBSZXBsaWNhdGlvbiBBcmNoaXRlY3R1cmX/IgArACoAIQAPACcAGgAfAA8AEAAaABoA EQAQAB0AHgAPACoAFAAaAB4AEAAQABoAGgAQAB4AFAAaAAUAAAAuAQEAAAAFAAAAAgECAAAABQAA AAIBAgAAAAQAAAAtAQQABAAAAC0BAQAHAAAAGwRhAUEDGAGgAAQAAAAtAQIABAAAAC0BAAAFAAAA CQIAAAACBQAAABQCAAAAABwAAAD7AtX/AAAAAAAAkAEAAAAAAEAAElRpbWVzIE5ldyBSb21hbgAq gu13wGfvd9oFCu8AAAoABAAAAC0BAwAEAAAA8AEFAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4B GAAAAAUAAAACAQEAAAAPAAAAMgpGAQMBBQAAAGRyYWZ0ABUADgAUAA0ADAAFAAAALgEBAAAABQAA AAIBAgAAAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAJAAAAMgpGAVMB AQAAAC0ADgAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAA AAUAAAACAQEAAAANAAAAMgpGAWEBBAAAAGlldGYMABIADQAOAAUAAAAuAQEAAAAFAAAAAgECAAAA BQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAAAkAAAAyCkYBmgEBAAAALQ0O AAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIB AQAAAA0AAAAyCkYBqAEEAAAAbGR1cAwAFQAVABYABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQIA AAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAACQAAADIKRgH0AQEAAAAtAA8ABQAAAC4B AQAAAAUAAAACAQIAAAAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAADwAA ADIKRgEDAgUAAABtb2RlbAAgABUAFgASAAwABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQIAAAAC BQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAACQAAADIKRgFsAgEAAAAtDQ4ABQAAAC4BAQAA AAUAAAACAQIAAAAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAAEAAAADIK RgF6AgYAAAAwNy50eHQWABYACwAMABUADAAFAAAALgEBAAAABQAAAAIBAgAAABwAAAD7AuX/AAAA AAAAkAEAAAAAAEAAElRpbWVzIE5ldyBSb21hbgAqgu13wGfvd7QNCp4AAAoABAAAAC0BBQAEAAAA 8AEDAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAASAAAAMgquAcIBBwAA AEVkIFJlZWQAEQANAAcAEgAMAAsADgAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAgAAAAIFAAAA FAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAhAAAAMgrUAZMBEQAAAFVwcGlsaSBTcmluaXZhc2Fu SRMADgAOAAcACAAHAAYADwAJAAcADgAHAAwADAAKAAwADgAFAAAALgEBAAAABQAAAAIBAgAAAAUA AAACAQIAAAAEAAAALQEBAAQAAAAtAQQAHAAAAPsCEAAHAAAAAAC8AgAAAAABAgIiU3lzdGVtAHfR Bma8BwCKAQAACgAGAAAABwCKAQAACgAEAAAALQEDAAQAAADwAQUADwAAACYGDwAUAFROUFAEAAwA AAAAAAAAAAAAAAAACQAAACYGDwAIAP////8BAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAD+/wAABAACAAAAAAAAAAAAAAAAAAAAAAABAAAAAtXN1ZwuGxCTlwgAKyz5rjAA AADsAQAADQAAAAEAAABwAAAAAwAAAHgAAAAPAAAAkAAAAAQAAACsAAAABgAAALQAAAAHAAAAvAAA AAgAAADEAAAACQAAAMwAAAAKAAAA1AAAAAsAAADcAAAAEAAAAOQAAAANAAAA7AAAAAwAAACJAQAA AgAAAOQEAAAeAAAADwAAAE9uLXNjcmVlbiBTaG93AFAeAAAAEwAAAE9yYWNsZSBDb3Jwb3JhdGlv bgB0AwAAAAAAAAADAAAAIAAAAAMAAAAFAAAAAwAAAAUAAAADAAAAAAAAAAMAAAAAAAAACwAAAAAA AAALAAAAAAAAAB4QAAAHAAAAEAAAAFRpbWVzIE5ldyBSb21hbgAPAAAARGVmYXVsdCBEZXNpZ24A HgAAAExEQVAgUmVwbGljYXRpb24gQXJjaGl0ZWN0dXJlABMAAABTdW1tYXJ5IG9mIGNoYW5nZXMA GwAAAFN1bW1hcnkgb2YgY2hhbmdlcy0gY29udGQuAAcAAABTdGF0dXMABwAAAFBsYW5zPwAMEAAA BgAAAB4AAAALAAAARm9udHMgVXNlZAADAAAAAQAAAB4AAAAQAAAARGVzaWduIFRlbXBsYXRlAAMA AAABAAAAHgAAAA0AAABTbGlkZSBUaXRsZXMAAwAAAAUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= --=_2F728606.CAABC5BF-- From owner-ietf-ldup@mail.imc.org Wed Mar 20 13:14:38 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08873 for ; Wed, 20 Mar 2002 13:14:36 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2KI36l02876 for ietf-ldup-bks; Wed, 20 Mar 2002 10:03:06 -0800 (PST) Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2KI2x402861 for ; Wed, 20 Mar 2002 10:02:59 -0800 (PST) Received: from qsun.mt.att.com ([135.16.157.16]) by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with SMTP id g2KI2sW00573 for ; Wed, 20 Mar 2002 13:02:55 -0500 (EST) Received: from att.com by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id NAA07774; Wed, 20 Mar 2002 13:02:51 -0500 Message-ID: <3C98CEBA.5F52B81@att.com> Date: Wed, 20 Mar 2002 13:02:34 -0500 From: Richard Huber X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ldup@imc.org, minutes@ietf.org CC: "Moats, Ryan" , "McMeeking, John" Subject: Charts used for LDUP Mandatory Replica Management discussion Content-Type: multipart/mixed; boundary="------------057AA0EB879AC32FF5E25B18" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------057AA0EB879AC32FF5E25B18 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit These are the charts I used during the LDUP meeting this morning. Rick Huber --------------057AA0EB879AC32FF5E25B18 Content-Type: application/ppt; name="IETF 53 MRM Presentation.ppt" Content-Disposition: inline; filename="IETF 53 MRM Presentation.ppt" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAA1gAAAAAA AAAAEAAA/v///wAAAAD+////AAAAANQAAADVAAAA//////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////9gIRvwLRgAAO5oDcpubvxxmzeD6XSW1/FkhQAA AAAAAAAAAADlAgAAGgIAAGA+fwCwXFwA+xcAAAD+eNrl3Q+8jfXhwPHnHC75kz/5s9C4+VNo KCw0lKvQUMilobC5GuIqV2G5CvOnsLBhYaF4ChWFiorqarHlttjQYouGlhpaatHu75x7z/l0 7yfV2m/7vdp+157Oed6fc849z3nOufecc7/fs0hQKgiKPZ4WBCWDqhWC2Ff8vxeUKB/UTu3d tUP7SJyCSDDq6vhhsfh/UoPgWNPY0iPuQTAj4fHlj9EgqBIN+LqjTxA82i52lqu6doifOn6e 08WDIPa/oHxsuTl5wuIFF3BF7AKPBfo6UDy48+FiQa/g6uC62HJtjK4Mbg0GBrcHQ4IRwU2J k5WOLRUKna1UYv1g7PqcG1suiB0/Lyi4zkGhw/hXvdhSNmHnJI7HN+NsXWa1RMvLywsujB2e mzhdkLDClxX3XrHl4vhNFrvg2E0cvBA7nBs7TMm3ubH1+JIWO56Wv548b6zfWb/Q5ST9rEIe v66xmzMYGSk4fjR5BRJfz3y6H2q3i91eQ2K32M3BP/t1KP3eUvvTL79xWc9n/nSIw7gVf/NQ +oDcnJ7xber2l3OCCZXyr2dwb5vtPfPPesVbl5/3ck7ieM8rCh/GT1sydnj3Azk948fjy7HB L/V8vdTh9CA4nD45dliy8NWInW/Y0sRlBccuj90cwYRvxI8fTj+18NPLSD1xThA/b3wplTjr hFrxcjj9ulKP9xz2xtrEZdS+4tp9a3vGTxe/Dcc8WXCdX71jX/rRNct6xg/jPui2/E0qcj9J Ho/dR+4co/vJOYVOVzVx/NzEUvYM97nk+Usk1uNXYlpsaRpbuSF2uDJ2mMV99uN28SXeRibu 9120t/ISXwNix+OPmm6xB237IDMYHvuXGXvMpCTu22cnvme5xHWpmFjKJhZvV+FtTj6eol/w eIr+E4+nYp/zeCqmx9OUSMHjaXck+XjaHXkhf5kSSc1fdkfO9Hgq9jmPp+j/wf6Nav9eFltZ GltWxJanIkX3b7yti3z5/m0fjA5Gxe4d8b2bEXucpwZN2Z9lgoLHV3LflinY5vx9XuZrvH8r RQv27/rop/u3UnR3ZH3+MiVSKX/5+u/fi6IF+/e+6Gf3b7z9c/v3mn9o/5b7Gu/fRkHB/s0N Pt2/jWLHcvOXKZFG+cvXf/92DAr27xPBZ/dvvP1z+/eS/9jH75ftr7if6XvHr1vv2FI3ttyS eI50S+JnfDT/+NzYMoX7Q8lCl+P7wH/qdmfHLVJwmNzu7JhkB/8/tntQtOAwfrpB0fh2l/2v 3u7k9g6Kfrq/B8V+r8W3/R/Z7sL+r3zN8mWvQVLO8LPl05caecHnbXeNxPV6M1JwnS5NrL+R WE/23eqvqb+i/rL6i+rPqT+tvk79MfWV6svVl6gvVJ+nPlt9hvpU9Ynq49XHqI9SH6E+RH2Q en/1Purp6t3UO6t3UG+n3lq9hXpT9Ubq9dXrqNdUr6ZeWb28emn1FPVA/VRQtJ8Mivbj6kfV D6sfUN+nvkd9p/oO9W3qOeqb1Teqr1dfo75KfYX6UvVF6vPV56jPVJ+mPkk9W32sepZ6pvpQ 9Qz1Aep91Xupd1fvot5RPU29jXpL9WbqjdUbqNdVr6VeXb2KegX1MuolEuv/zb/T3tHPhPh6 TfU66vXVG6k3VW+h3lq9nXoH9c7q3dTT1fuo91cfpD5EfYT6KPUx6uPVJ6pPVZ+hPlt9nvpC 9SXqy9VXqj+mvk79afVNhdaPJNaTpz+ovl99r/ou9Vz17epb1beob1LfoL5WfbV6qL5MfbH6 AvW56rPUp6tPVp+gPk59tPpI9WHqg9UHqvdT763eQ72reif19upt1VupN1dvot5QvZ56qnoN 9arqFdXLqpdUj6p/EhTtHwVF+/vq76m/rf7WV+zx9S3qW9W3q+eq71Lfq75f/aD6EfV31U+o f6h+Wj0SKdpLRIr2MuoV1KuoV1evpV5XvYF6Y/Vm6i3V26inqXdU76LeXb2Xel/1AeoZ6kPV M9Wz1MeqZ6tPUp+mPlN9jvp89UXqS9VXqK9SX6O+Xn2j+mb1HPVt6jvUd6rvUd+nfkD9sPpR 9ePqJ9VPFerxx2Jeob4/sc7vV/Vd6rnq29W3qm9R36S+QX2t+mr1UH2Z+mL1Bepz1WepT1ef rD5BfZz66MT6mccKFHwxVuCcgrEC/C7WZQ3T9xqsPlC9n3pv9R7qXdU7qbdXb6veSr25ehP1 hur11FPVa6hXVa+oXla9pHrKGdZPFzp9fP1D9RPq76ofUT+ovl99r/ou9Vz17epb1beob1Lf oL5WfbV6qL5MfbH6AvW56rPUp6tPVp+gPk59tPpI9WHqg9UHqvdT763eQ72reif19upt1Vup N1dvot5QvZ56qnoN9arqFdXLqpdUj6p/EhTtHwVF+/vq76m/rf6W+h/UX1f/rfqr6r9Sf0n9 efVn1J9Uf1z9EfWH1B9Q/4X6z9V/qv4T9bvVf6x+p/qP1G9Tv0X9ZvWb1L+vfoP69erXqV+j frX6leqXq1+m/m31i9UvUr9A/Xz1877i+29f9H5Y3uf8XS2iv+HEx3BcWmi9XLRoL6VeXL3w 77D4+seRov0D9WPq76gfUn9T/Q313eqvqb+i/rL6i+rPqT+tvk79MfWV6svVl6gvVJ+nPlt9 hvpU9Ynq49XHqI9SH6E+RH2Qen/1Purp6t3UO6t3UG+n3lq9hXpT9Ubq9dXrqNdUr6ZeWb28 emn1FPVA/VRQtJ/U4/O4+lH1w+oH1Pep71Hfqb5DfZt6jvpm9Y3q69XXqK9SX6G+VH2R+nz1 Oeoz1aepT1LPVh+rnqWeqT5UPUN9gHpf9V7q3dW7qHdUT1Nvo95SvZl648J/o9TfO3Yk1vkb pXqO+mb1jerr1deor1Jfob5UfZH6fPU56jPVp6lPUs9WH6uepZ6pPlQ9Q32Ael/1Xurd1buo d1RPU2+j3lK9mXpj9QbqddVrqVdXr6JeQb1s4v5Y+P3tZuot1duop6l3VO+i3l29l3pf9QHq GepD1TPVs9THqmerT1Kfpj5TfY76fPVF6kvVV6ivUl+jvl59o/pm9Rz1beo71Heq71Hfp35A /bD6UfXj6ifVT6kHkaI9JVK0l1Yvr15ZvZp6TfU66vXVG6k3VW+h3lq9nXoH9c7q3dTT1fuo 91cfpD5EfYT6KPUx6uPVJ6pPVZ+hPlt9nvpC9SXqy9VXqj+mvk79afXn1F9Uf1n9FfXX1Her v6H+pvoh9XfUj6l/oP6xep568WjRXipatJdTr/QVekW9vq2qXkM9Vb2eekP1JurN1Vupt1Vv r95Jvat6D/Xe6v3UB6oPVh+mPlJ9tPo49Qnqk9Wnq89Sn6u+QH2x+jL1UH21+lr1Deqb1Leo b1Xfrp6rviux/q96DyfI+/IxTXl6Dyb+eCr8GCsVLdrLqVdSP1f9m+q11S9U/5b6JeqXqn9H /Qr1q9S/q36tek/176nfqP4D9R+qD1e/Vf129TvU71Kfon6P+r3qP1O/T/1+9QfVH1Z/VP0J 9afUn1V/Qf2X6r9W/43679R/r77/DOufFDp9fP0j9ffV31N/W/0t9T+ov67+W/VX1X+l/pL6 8+rPqD+p/rj6I+oPqT+g/gv1n6v/VP0n6ner/1j9TvUfqd+mfov6zeo3qX9f/Qb169WvU79G /Wr1K9UvV79M/dvqF6tfpH6B+vnq56l/Q/0c9bPVz1Ivpv73oGj/W1C0/1X9L4X6rFIFYwXO qXTmsQLxcQL5s7p7FJz3z7qsP+l7/VH99+q/U/+N+q/Vf6n+gvqz6k+pP6H+qPrD6g+q369+ n/rP1O9Vv0d9ivpd6neo365+q/pw9R+q/0D9RvXvqfdUv1b9u+pXqV+h/h31S9UvUf+W+oXq tdW/qX6ueiX1cuqlCs/hiBb8XY45HIl13h9V36G+TT1HfbP6RvX16mvUV6mvUF+qvkh9vvoc 9Znq09QnqWerj1XPUs9UH6qeoT5Ava96L/Xu6l3UO6qnqbdRb6neTL2xegP1uuq11KurV1Gv oF5GvYR6RP10pGj/MFK0n1B/V/2I+kH1/ep71Xep56pvV9+qvkV9k/oG9bXqq9VD9WXqi9UX qM9Vn6U+XX2y+gT1ceqj1UeqD1MfrD5QvZ96b/Ue6l3VO6m3V2+r3kq9uXoT9Ybq9dRT1Wuo V1WvqF5WvaR6VP2ToGj/KPhq/aPE574U7uXVK6tXU6+pXke9vnoj9abqLdRbq7dT76DeWb2b erp6H/X+6oPUh6iPUB+lPkZ9vPpE9anqM9Rnq89TX6i+RH255piGmoMaao5qqDmsoea4hpoD G2qObKg5tKHm2Iaagxtqjm6oObyh5viGmgMcao5wqDnEoeYYh5qDHGqOcqg5zKHmOIeaAx1q jnSoOdSh5liHmoMdao52qDncoeZ4h5oDHmqOeKg55KHmmIeagx5qjnqoOeyh5riHmgMfao58 qDn0oebYh5qDH2qOfqg5/KHGB4T6DIBQnxFQuB9Sf0f9mPoH6h+r56nH11err1XfoL5JfYv6 VvXt6rnqu9T3qu9XP6h+RP1d9RPqH6qfVo9EivYSkaK9jHoF9Srq1dVrqddVb6DeWL2Zekv1 Nupp6h3Vu6h3V++l3ld9gHqG+lD1TPUs9bHq2eqT1Kepz1Sfoz5ffZH6UvUV6qvU16ivV9+o vlk9R32b+g71nep71PepH1A/rH5U/bj6SfVT6vHlH/n7TLnEc7Mg+bs3SHz8ZeSs/Od4ZfL/ SJM/aj1aPfqnaPzznj6OfvpeWfHE79fi+c8ro/mnjETjs97jM0FOR5Mz4AtOF8n/fnWLpZzx 8yYLzlH0kqP5h8di5yz4zinMqk9eYvHET9z4X5ZORY8mPnWSz5us3e7WIQO/6JMmk1tQcP4K QclC549Eo7WvGzsqK2P4l52/WOIWKLg+jSPn5t8SpaKFv0N8Lk3T0iNjzz/iz5avvq5bavvM 4cMzR6QEZ8f+lYjdNmWDirF/ZWP/kpd65tu7+D94e6cUur0/+3mERW/hFN2ixYvs26+yhesi l+VvYfvRo7Iyh2fcmto0vmVlYtcwvn1lYttUIvbff/UWnukT+f59W3hRtMgWXvPZLSz3L9/C M30m3b9vCzsGRbbwkn/nPjzzVkR1OQU/A+oVi/IJbMnvW/Sx+Nlb4X93/Uro+pX40uuX/KS0 r8v1SX6C2dfn+hR8stjnXZ/C61/+/Yvr+3+6ntyuaGKuiK9P/HIrR6vFnuEXfKZntdhz/6Tt xl7DXsFexl7EnsOextZhj2ErseXYEmwhNg+bjc3ApmITsfHYGGwUNgIbgg3C+mN9sHSsG9YZ 64C1w1pjLbCmWCOsPlYHq4lVwypj5bHSWAoWYKeCpJ1k/x7HjmKHsQPYPmwPthPbgW3DcrDN 2EZsPbYGW4WtwJZii7D52BxsJjYNm4RlY2OxLCwTG4plYAOwvlgvrDvWBeuIpWFtsJZYM6wx 1gCri9XCqmNVsApYGaxE8HX5+fFO4n5YM3GscrQOVh9rhDXFWmCtsXZYB6wz1g1Lx/pg/bFB 2BBsBDYKG4ONxyZiU7EZ2GxsHrYQW4Itx1Zij2HrsKexTYWOHUnUTcFBbD+2F9uF5WLbsa3Y FmwTtgFbi63GQmwZthhbgM3FZmHTscnYBGwcNhobiQ3DBmMDsX5Yb6wH1hXrhLXH2mKtsOZY E6whVg9LxWpgVbGKWFmsJBbFPgmS9lGQtPex97C3sbe+wLYkjlWKbsW2Y7nYLmwvth87iB3B 3sVOYB9ip7FIJGklIkkrg1XAqmDVsVpYXawB1hhrhrXE2mBpWEesC9Yd64X1xQZgGdhQLBPL wsZi2dgkbBo2E5uDzccWYUuxFdgqbA22HtuIbcZysG3YDmwntgfbhx3ADmNHsePYSewUlhc5 mLC8yH5sL7YLy8W2Y1uxLdgmbAO2FluNhdgybDG2AJuLzcKmY5OxCdg4bDQ2EhuGDcYGYv2w 3lgPrCvWCWuPtcVaYc2xJlhDrB6WitXAqmIVsbJYSSwlcex04ljl6IfYCexd7Ah2ENuP7cV2 YbnYdmwrtgXbhG3A1mKrsRBbhi3GFmBzsVnYdGwyNgEbh43GRmLDsMHYQKwf1hvrgXXFOmHt sbZYK6w51gRriNXDUrEaWFWsIlYWK4lFsfjvpQL7KEja+9h72NvYW9gfsNex32KvYr/CXsKe x57BnsQexx7BHsIewH6B/Rz7KfYT7G7sx9id2I+w27BbsJuxm7DvYzdg12PXYddgV2NXYpdj l2Hfxi7GLsIuwM7HzgtSvuT1QNHn83mfeZ8j+Xw+/s5hwWWWSxyrHC2FFcfyIkn7OJK0D7Bj 2DvYIexN7A1sN/Ya9gr2MvYi9hz2NLYOewxbiS3HlmALsXnYbGwGNhWbiI3HxmCjsBHYEGwQ 1h/rg6Vj3bDOWAesHdYaa4E1xRph9bE6WE2sGlYZK4+VxlKwADvFe0Ung6Qdx45ih7ED2D5s D7YT24Ftw3KwzdhGbD22BluFrcCWYouw+dgcbCY2DZuEZWNjsSwsExuKZWADsL5YL6w71gXr iKVhbbCWWDOsMdYo2JmwRsEObBuWg23GNmLrsTXYKmwFthRbhM3H5mAzsWnYJCwbG4tlYZnY UCwDG4D1xXph3bEuWEcsDWuDtcSaYY2xBlhdrBZWHauCVUhY48TrxNirG14xtsTaYGlYR6wL 1h3rhfXFBmAZ2FAsE8vCxmLZ2CRsGjYTm4PNxxZhS7EV2CpsDbYe24htxnKwbdgObCe2B9uH HcAOY0ex49hJ7BQWRJKWEklaaaw8VhmrhtXE6mD1sUZYU6wF1hprh3XAOmPdsHSsD9YfG4QN wUZgo7Ax2HhsIjYVm4HNxuZhC7El2HJsJfYYtg57GnsOexF7GXsFew3bjb2BvYkdwt7BjmEf YB9jeVjxaNJKRZNWDqv0hVYpWhGritXAUrF6WEOsCdYca4W1xdpjnbCuWA+sN9YPG4gNxoZh I7HR2DhsAjYZm47NwuZiC7DF2DIsxFZja7EN2CZsC7YV247lYrsiX+W5cZD3ee9150XyuH8U jyatVDRp5bBK2LnYN7Ha2IXYt7BLsEux72BXYFdh38WuxXpi38NuxH6A/RAbjt2K3Y7dgd2F TcHuwe7Ffobdh92PPYg9jD2KPYE9hT2LvYD9Evs19hvsd9jvsf2JY58kjlWOfoS9j72HvY29 hf0Bex37LfYq9ivsJex57BnsSexx7BHsIewB7BfYz7GfYj/B7sZ+jN2J/Qi7DbsFuxm7Cfs+ dgN2PXYddg12NXYldjl2GfZt7GLsIuwC7HzsPOwb2DnY2dhZWDHs70HS/hYk7a/YX7A/Y3/C /oj9Hvsd9hvs19gvsRewZ7GnsCewR7GHsQex+7H7sJ9h92L3YFOwu7A7sNuxW7Hh2A+xH2A3 Yt/DemLXYt/FrsKuwL6DXYpdgn0LuxCrjX0TOxerhJXDSmEpwb6EpQR7sJ3YDmwbloNtxjZi 67E12CpsBbYUW4TNx+ZgM7Fp2CQsGxuLZWGZ2FAsAxuA9cV6Yd2xLlhHLA1rg7XEmmGNsQZY XawWVh2rglXAymAlsAh2OvlORPBh8tl5cAJ7FzuCHcT2Y3uxXVguth3bim3BNmEbsLXYaizE lmGLsQXYXGwWNh2bjE3AxmGjsZHYMGwwNhDrh/XGemBdsU5Ye6wt1gprjjXBGmL1sFSsBlYV q4iVxUpiUSz599MU/n56JiudOBZ7lYZVxqphNbE6WH2sEdYUa4G1xtphHbDOWDcsHeuD9ccG YUOwEdgobAw2HpuITcVmYLOxedhCbAm2HAsZRRQysihktFHICKSQUUkhI5VCRi+FjGgKGeUU MvIpZDRUyAipkFFTISOpQkZXhYy4ChmFFTIyK2S0VsgIrpBRXSEjvUJGf4WMCAsZJRYycixk NFnICLOQUWchI9FCRqeFjFgLGcUWMrItZLRbyAi4kFFxISPlQkbPhYyoCxllFzLyLmQ0XsgI vZB3/kJG8oWM7guDQ9g72DHsA+xjLPlqZ3XiWOXoWmwDtgnbgm3FtmO52C5sL7YfO4gdwd7F TmAfYqexCK/QSkSSVgargFXBqmO1sLpYA6wx1gxribXB0rCOWBesO9YL64sNwDKwoVgmloWN xbKxSdg0bCY2B5uPLcKWYiuwVdgabD22EduM5WDbsB3YTmwPtg87gB3GjmLHsZPYqUKvyvM+ 95V+wf+H8P8AxWYOQmAhG/BhGAAAOfTw54mcbpW8184sgIlupbSEAAAAAAAAAAAAAOUCAAAa AgAAYD5/ALBcXAAvGAAAAP542uXdD7zN9cHA8d85XOLKn/xZaJg/hYXCwoZCoaGQS0Nh3auh EFdhuQr501Bo2LCh8atY0VDRYnW12GKLDVts0aJFQ0steu5zfvee83HvJ2o9T8/r1fM8t/2c 83t/zjn3/M7vnnvPn+/3LBaUCoJifdsHQcmgSvkg8RX9e2mJckHtWn26dewQiyiIBS98HB0W i/6pFQTdmyaWnpEHwcykR8tf40FQOR7wdW/fIHiyXeIs13XrGJ06Os8/iwdB4n9BucRyR+qE xQsu4JrEBR4P9HWweHDf48WC3sH1wU2J5cYEXRuMCgYF9wRDguHB7cmTlU4s5QudrVRy/VDi +lycWC5NHL8kKLjOQaHD6KteYimTtIuSx6PNuFCXWTXZ8vLygssShxcnTxckrfBlRd47sVwR 3WSJC07cxMGLicN5icO0fJuXWI+W9onj7fPXU+dN9PvqF7qclF9QyKPrmrg5g5GxguNHU1cg +fX82f1Qu13i9hqSuMXuCP6rX/szrji2P+PqW5f3ynzs7GFkxe/fnzFwZ26vaJtu/sdFwcSK +dczeLjN9l75Z73mzasveSU3ebzXNYUPo9OWTBw++Ghur+h4tBwf/HKvvn/dnxEEBzKKJw5L Fr4aifMNW5a8rOD41YmbI5j4lej4gYzTi85eRt2TFwXReaOlVPKsE2tG5UDGTaWe7jXs9bXJ y6h9zY371/aKThfdhmOfKbjOCx96PePomuW9osPIM+/O36QiPyep44mfkfvG6ufkokKnq5I8 fnFyKXOOn7nomz6SWK5MrNySOFyTOMzmZ/SjdtEStZHJ83TV3slLfmUmjncOshJ7OjO4KxiT OByVuJysxL+jg7KJlp5cyhRa0gt+rvL3Q+p4urYvdd+Jf8p9J/5fuO8UO899p5juO1NjBfed PbHUfWdP7MX8ZWqsVv6yJ3au+06x89x34v/D+3JgYumfWFmWWB5ILM/Giu7LqK2LFVy/8+3L Xvn370sTv+uC/H2XWr4s+6VivGC/rI+f3S8V43ti6/OXqbGK+cuXa79MTyyXxwv2y/z4J/dL 1KL9UvpT9ku0b9sFtyX+G5G4hw1P3L8K/gpdeJ77V8nk7/vU+pdl/zUKCvbfzuDs/muUOLYz f5kaa5S/fLn235TEckNQsP9WBZ/cf1GL9l+pz9h/3fJ/Mw5L/GZM7b3gggr6/Zf+Jdx3n7Uv Ij/X946uW5/EUjex3JV8DHJX8vdqPP/4vMQylX1dstDleP/+b93unMhiBYep7c5JSE7w/2O7 M+MFh9HpMuPRdpf5P73dqe3NjJ/d35mJv0nRtv87213Yv8jnBJ/1GD/tHL9bzj6UzwvOt93V k9frjVjBdboquf56cj3V96i/pv6q+ivqL6m/oP6c+jr1p9SfUF+hvlR9kfp89TnqM9WnqU9S n6A+Vn20+nD1IeqZ6gPU+6pnqHdX76LeUb2demv1FupN1Rup11evo15Dvap6JfVy6qXV09QD 9dNB0X4qKNpPqB9VP6x+UH2/+l71Xeo71Lep56pvVt+ovl59jfoq9ZXqy9QXqy9Qn6s+S326 +mT1HPVx6tnqI9SHqmepD1Tvp95bvYd6V/VO6u3V26i3VG+m3li9gXpd9Zrq1dQrq5dXT1cv kVz/v/w37R39TojWa6jXUa+v3ki9qXoL9dbq7dQ7qndR766eod5XfYB6pvoQ9eHqo9XHqk9Q n6Q+TX2m+hz1+eqL1Jeqr1B/Qv0p9XXqz6lvKrR+JLmeOv0h9QPq+9R3q+9U366+VX2L+ib1 Depr1Verh+rL1ZeoL1Sfpz5bfYb6FPWJ6uPVx6iPVB+mPlh9kHp/9T7qPdW7qXdW76DeVr2V enP1JuoN1eup11Kvrl5FvYJ6GfWS6nH16M2Ywv3DoGh/T/1d9bfV3/ycPVrfor5Vfbv6TvXd 6vvUD6gfUj+ifkz9pPoH6mfUY7GivUSsaE9XL69eWb2aek31uuoN1BurN1Nvqd5Gvb16J/Wu 6j3Ue6v3Ux+onqU+VH2Eerb6OPUc9cnq09Vnqc9VX6C+WH2Z+kr1Vepr1Nerb1TfrJ6rvk19 h/ou9b3q+9UPqh9WP6p+Qv2U+ulCPbov5hXqB5Lr/H1V362+U327+lb1Leqb1Deor1VfrR6q L1dfor5QfZ76bPUZ6lPUJ6qPVx+jPlJ9mPpg9UHq/dX7qPdU76beWb1Dcv3cYwUKvhgrcFHB WAH+FuuyWul7NVdvot5QvZ56LfXq6lXUK6iXUS+pnnaO9TOFTh+tf6B+Uv2Y+hH1Q+oH1Pep 71bfqb5dfav6FvVN6hvU16qvVg/Vl6svUV+oPk99tvoM9SnqE9XHq49RH6k+TH2w+iD1/up9 1Huqd1PvrN5Bva16K/Xm6k3UG6rXU6+lXl29inoF9TLqJdXj6h8HRfuHQdH+nvq76m+rv6n+ F/U/qf9B/Xfqv1F/Wf1X6s+rP6P+tPrP1R9Tf1T9J+o/Un9E/SH1B9UfUL9P/fvqd6vfpX6H +u3q31W/Rf1m9ZvUb1C/Xv1a9avVv6n+DfUr1L+ufqn619Qv+Zyvv33a62F553lfLab3cKLx F1cVWi8bL9pLqRdXL/w3LFr/KFa0v69+XP0d9bfU31B/XX2P+mvqr6q/ov6S+gvqz6mvU39K /Qn1FepL1Repz1efoz5TfZr6JPUJ6mPVR6sPVx+inqk+QL2veoZ6d/Uu6h3V26m3Vm+h3lS9 kXp99TrqNdSrqldSL6deWj1NPVA/HRTtp3T/PKF+VP2w+kH1/ep71Xep71Dfpp6rvll9o/p6 9TXqq9RXqi9TX6y+QH2u+iz16eqT1XPUx6lnq49QH6qepT5QvZ96b/Ue6l3VO6m3V2+j3lK9 mXrjwu9R6v2OHcl13qNUz1XfrL5Rfb36GvVV6ivVl6kvVl+gPld9lvp09cnqOerj1LPVR6gP Vc9SH6jeT723eg/1ruqd1Nurt1Fvqd5MvbF6A/W66jXVq6lXVi+vXib581j49e1m6i3V26i3 V++k3lW9h3pv9X7qA9Wz1Ieqj1DPVh+nnqM+WX26+iz1ueoL1BerL1Nfqb5KfY36evWN6pvV c9W3qe9Q36W+V32/+kH1w+pH1U+on1I/rR7Eiva0WNFeWr2ceiX1quo11Ouo11dvpN5UvYV6 a/V26h3Vu6h3V89Q76s+QD1TfYj6cPXR6mPVJ6hPUp+mPlN9jvp89UXqS9VXqD+h/pT6OvXn 1F9Qf0n9FfVX1V9T36P+uvob6m+pv6N+XP199Y/U89SLx4v2UvGivax6xc/RK+j5bRX16uq1 1OupN1Rvot5cvZV6W/UO6p3Vu6n3VO+j3l99kPpg9WHqI9XHqI9Xn6g+RX2G+mz1eeoL1Zeo L1cP1Verr1XfoL5JfYv6VvXt6jvVdyfXv6jXcIK8zx7TlKfXYKL7U+H7WKl40V5WvaL6xepf Va+tfpn65epXql+l/i31a9SvU/+2+o3qvdS/o36r+m3q31O/U32U+j3q96rfrz5V/QfqD6v/ UP3H6j9V/5n64+pPqv9C/Vn1X6q/qP5r9d+q/179j+p/Vj9wjvWPC50+Wv9Q/T31d9XfVn9T /S/qf1L/g/rv1H+j/rL6r9SfV39G/Wn1n6s/pv6o+k/Uf6T+iPpD6g+qP6B+n/r31e9Wv0v9 DvXb1b+rfov6zeo3qd+gfr36tepXq39T/RvqV6h/Xf1S9a+pX6L+FfWL1C9Uv0C9mPp/BEX7 v4Ki/Z/q/1D/u/rf1P+q/mf1P6r/Xv236r9Wf1H9l4V621IFYwVGXXTusQLROIHoKxorEJ33 WV3WL/S9nlR/XP1n6j9V/7H6D9UfVv+B+lT1+9XvVb9HfZT6nerfU79N/Vb176j3Ur9R/dvq 16lfo/4t9avUr1S/XP0y9drqX1W/WL2ieln1UoXncMQL3pdjDkdynddH1Xeob1PPVd+svlF9 vfoa9VXqK9WXqS9WX6A+V32W+nT1yeo56uPUs9VHqA9Vz1IfqN5Pvbd6D/Wu6p3U26u3UW+p 3ky9sXoD9brqNdWrqVdWL6+erl5CPaZ+Jla0fxAr2k+qH1M/on5I/YD6PvXd6jvVt6tvVd+i vkl9g/pa9dXqofpy9SXqC9Xnqc9Wn6E+RX2i+nj1Meoj1YepD1YfpN5fvY96T/Vu6p3VO6i3 VW+l3ly9iXpD9XrqtdSrq1dRr6BeRr2kelz946Bo/zD4fP3D5OcJFe7l1CupV1WvoV5Hvb56 I/Wm6i3UW6u3U++o3kW9u3qGel/1AeqZ6kPUh6uPVh+rPkF9kvo09Znqc9Tnqy9SX6q+QnNM Q81BDTVHNdQc1lBzXEPNgQ01RzbUHNpQc2xDzcENNUc31BzeUHN8Q80BDjVHONQc4lBzjEPN QQ41RznUHOZQc5xDzYEONUc61BzqUHOsQ83BDjVHO9Qc7lBzvEPNAQ81RzzUHPJQc8xDzUEP NUc91Bz2UHPcQ82BDzVHPtQc+lBz7EPNwQ81Rz/UHP5Q4wNCfQZAqM8IKNzfUn9H/bj6++of qeepR+ur1deqb1DfpL5Ffav6dvWd6rvV96kfUD+kfkT9mPpJ9Q/Uz6jHYkV7iVjRnq5eXr2y ejX1mup11RuoN1Zvpt5SvY16e/VO6l3Ve6j3Vu+nPlA9S32o+gj1bPVx6jnqk9Wnq89Sn6u+ QH2x+jL1leqr1Neor1ffqL5ZPVd9m/oO9V3qe9X3qx9UP6x+VP2E+in10+rR8u+8P1M2+dgs SP3tDZIfLxm7IP8xXnr+mzT5o9bj1eJ/i0ef9/RR/OxrUcWTf1+L5z+ujOefMhaPZr1HM0HO xFMz4AtOF8v/fnWLpZ3z8xwLzlH0kuP5h8cT5yz4zmnMqk9dYvHkb9zonaXT8aPJT3Xk8xxr txs1ZNCnfZJjagsKzl8+KFno/LF4vPZN40ZnZ935WecvlrwFCq5P49jF+bdEqXjh7xA95m1a emRwZSy69TtnDcq8a8ygUdlZo0aXDdIT/5XJ/y89saUl8/9N57LPfasX/zdv9bRCt/onPwmw 6O2cptu1eJE9/O9tZ5n87VwX6x+LXqnseem1ie8f/fdFb825Pj/vi9+aKsmtuTwePcdpd9tt I8YMzx4y/PYLC+2zkonzRYdf9Bae6xPmvvgtrJzcwhvyXxXsNmjUsKxoA2+vkPwpTP/Ct+/c 2xDX5RTc5+sVi/OJa6nvW/S+98nb4L93/Uro+pX4zOuX+mS0L8v1SX1i2Zfn+hR8ktj5rk/h 9c/+/sX1/c+up7Yrnpwb4usTXW6leNXEI/qCz9+smnisn7I92GvYq9gr2EvYC9hz2DrsKewJ bAW2FFuEzcfmYDOxadgkbAI2FhuNDceGYJnYAKwvloF1x7pgHbF2WGusBdYUa4TVx+pgNbCq WCWsHFYaS8MC7HSQslPs3xPYUewwdhDbj+3FdmE7sG1YLrYZ24itx9Zgq7CV2DJsMbYAm4vN wqZjk7EcbByWjY3AhmJZ2ECsH9Yb64F1xTph7bE2WEusGdYYa4DVxWpi1bDKWHksHSsRfFl+ f7yT/DmskTxWKV4Hq481wppiLbDWWDusI9YF645lYH2xAVgmNgQbjo3GxmITsEnYNGwmNgeb jy3ClmIrsCewp7B12HPYpkLHjiTrpuAQdgDbh+3GdmLbsa3YFmwTtgFbi63GQmw5tgRbiM3D ZmMzsCnYRGw8NgYbiQ3DBmODsP5YH6wn1g3rjHXA2mKtsOZYE6whVg+rhVXHqmAVsDJYSSyO fRyk7MMgZe9h72JvY29+im1JHqsY34ptx3Ziu7F92AHsEHYEO4adxD7AzmCxWMpKxFKWjpXH KmPVsJpYXawB1hhrhrXE2mDtsU5YV6wH1hvrhw3EsrCh2AgsGxuH5WCTsenYLGwutgBbjC3D VmKrsDXYemwjthnLxbZhO7Bd2F5sP3YQO4wdxU5gp7DTWF7sUNLyYgewfdhubCe2HduKbcE2 YRuwtdhqLMSWY0uwhdg8bDY2A5uCTcTGY2OwkdgwbDA2COuP9cF6Yt2wzlgHrC3WCmuONcEa YvWwWlh1rApWASuDlcTSksfOJI9Vin+AncSOYUewQ9gBbB+2G9uJbce2YluwTdgGbC22Ggux 5dgSbCE2D5uNzcCmYBOx8dgYbCQ2DBuMDcL6Y32wnlg3rDPWAWuLtcKaY02whlg9rBZWHauC VcDKYCWxOBb9XSqwD4OUvYe9i72NvYn9BfsT9gfsd9hvsJexX2HPY89gT2M/xx7DHsV+gv0I ewR7CHsQewC7D/s+djd2F3YHdjv2XewW7GbsJuwG7HrsWuxq7JvYN7ArsK9jl2Jfwy4J0j7j +UDRx/N5n3idI/V4PnrdsOAyyyaPVYqXwopjebGUfRRL2fvYcewd7C3sDex1bA/2GvYq9gr2 EvYC9hy2DnsKewJbgS3FFmHzsTnYTGwaNgmbgI3FRmPDsSFYJjYA64tlYN2xLlhHrB3WGmuB NcUaYfWxOlgNrCpWCSuHlcbSsAA7zWtFp4KUncCOYoexg9h+bC+2C9uBbcNysc3YRmw9tgZb ha3ElmGLsQXYXGwWNh2bjOVg47BsbAQ2FMvCBmL9sN5YD6wr1glrj7XBWmLNsMZYo2BX0hoF O7BtWC62GduIrcfWYKuwldgybDG2AJuLzcKmY5OxHGwclo2NwIZiWdhArB/WG+uBdcU6Ye2x NlhLrBnWGGuA1cVqYtWwylj5pDVOPk9MPLvhGWNLrA3WHuuEdcV6YL2xfthALAsbio3AsrFx WA42GZuOzcLmYguwxdgybCW2CluDrcc2YpuxXGwbtgPbhe3F9mMHscPYUewEdgo7jQWxlKXF UlYaK4dVwqpiNbA6WH2sEdYUa4G1xtphHbEuWHcsA+uLDcAysSHYcGw0NhabgE3CpmEzsTnY fGwRthRbgT2BPYWtw57DXsBewl7BXsVew/Zgr2NvYG9h72DHsfexj7A8rHg8ZaXiKSuLVfxU qxivgFXBqmO1sHpYQ6wJ1hxrhbXFOmCdsW5YT6wP1h8bhA3GhmEjsTHYeGwiNgWbgc3G5mEL sSXYcizEVmNrsQ3YJmwLthXbju3Edsc+z2PjIO98r3XnxfL4+SgeT1mpeMrKYhWxi7GvYrWx y7DLsSuxq7BvYddg12Hfxm7EemHfwW7FbsO+h92JjcLuwe7F7semYj/AHsZ+iP0Y+yn2M+xx 7EnsF9iz2C+xF7FfY7/Ffo/9EfszdiB57OPksUrxD7H3sHext7E3sb9gf8L+gP0O+w32MvYr 7HnsGexp7OfYY9ij2E+wH2GPYA9hD2IPYPdh38fuxu7C7sBux76L3YLdjN2E3YBdj12LXY19 E/sGdgX2dexS7GvYJdhXsIuwC7ELsGLYfwQp+1eQsn9i/8D+jv0N+yv2Z+yP2O+x32K/xl7E fok9i/0CexJ7HPsZ9lPsx9gPsYexH2BTsfuxe7F7sFHYndj3sNuwW7HvYL2wG7FvY9dh12Df wq7CrsQuxy7DamNfxS7GKmJlsVJYWrA/aWnBXmwXtgPbhuVim7GN2HpsDbYKW4ktwxZjC7C5 2CxsOjYZy8HGYdnYCGwoloUNxPphvbEeWFesE9Yea4O1xJphjbEGWF2sJlYNq4yVx9KxElgM O5N6JSL4IPXoPDiJHcOOYIewA9g+bDe2E9uObcW2YJuwDdhabDUWYsuxJdhCbB42G5uBTcEm YuOxMdhIbBg2GBuE9cf6YD2xblhnrAPWFmuFNceaYA2xelgtrDpWBauAlcFKYnEs9f5pGu+f nstKJ48lnqVhlbCqWA2sDlYfa4Q1xVpgrbF2WEesC9Ydy8D6YgOwTGwINhwbjY3FJmCTsGnY TGwONh9bhC3FVmAho4hCRhaFjDYKGYEUMiopZKRSyOilkBFNIaOcQkY+hYyGChkhFTJqKmQk VcjoqpARVyGjsEJGZoWM1goZwRUyqitkpFfI6K+QEWEho8RCRo6FjCYLGWEWMuosZCRayOi0 kBFrIaPYQka2hYx2CxkBFzIqLmSkXMjouZARdSGj7EJG3oWMxgsZoRfyyl/ISL6Q0X1h8Bb2 DnYcex/7CEs921mdPFYpvhbbgG3CtmBbse3YTmw3tg87gB3CjmDHsJPYB9gZLMYztBKxlKVj 5bHKWDWsJlYXa4A1xpphLbE2WHusE9YV64H1xvphA7EsbCg2AsvGxmE52GRsOjYLm4stwBZj y7CV2CpsDbYe24htxnKxbdgObBe2F9uPHcQOY0exE9gp7HShZ+V5532mX/D/GfyflnUEUWAh G/ABFwAA7XtDBIKdHpNMszirnpHZ8Rp3AAAAAAAAAAAAAL0CAADxAQAAcER4AMBiVQDPFgAA AP542uXdCXCUZZ7H8acbHq6AHANogAHkEnACCsghZ0AuAbkSUO5IAEMkRCByCEQBAyggEAUU UIhiHEQhDuBAu8q8whZSpW/VDFUOtSO1NVjClDiLTo3T4zHs+3b6/dL9M3jMslvsLk6T7u8n HbrzPs//bQJkQqa6MZXW9zSmqmlYx3g//J/bVKltWjQfP2LQgJCfTMic/Hf/bSX/p+bGXGjn XYb63Zh18e5f3gwb81n5XWI/ijKN+XUv7y4DRwzy39u/z5zKxnj/M7W9y4PBO1Yu/wD9vPte MvLjj5XNo7+sZMaZoWasdxnppbvMPJNlFpock2dmxd+thnepk3C36vHbR73HdMn7uG28601M +WM2CW/9H629S814qxe/7t3N1JKPmRq3y5cvm1u8tzfF38/EW+LH8vs473Kbf9v7wP29t697 b4u9tzbWir3b/qW/d71/7HZwX88fbZvwcYJeLaH7j3WMd8kPlV+/GDyA+I+3wlxtke59vnK8 z9iD5p/9cT7z189/lNl3SknG0tB53vrtD5XOZ05zj2f4z2nUf9QzhT+LPU6zsfepjNhd+33c t8nJ4/HrGf0S3/rvW9V7+8SLxzP86/7l0sx/zTj6b594K+eTzGzvbdXEh+HdL3d3/GOZS329 T4cpvNG//knm19uvfIzmX9Qz/n39S/X4XQub+fJJ5tjqb2Tk/qEs/jFa9Bv5UVmG/37+53DR m+WPeU21s5kXD5Rk+G/9nv1w7CklrZPgurdGHl0k66Rewvs1jF+/KX6pWcGa83/Rp/316d2Y 7L3d7r1dwBr9Kt2/+JYfv89wOTqX4z+yvetDzAzvSGebh0yB93ae93FmeD/PNzd4lhK/1Ey4 pJSvq9hxCK6nyPML9k74e/ZO+J/YO5Wusncqyd4pCpXvnQ9Dwd75MPR67FIUqhm7fBiqaO9U usreCf83H8tp3mWwd2N3qHx//jqUfCx9Oxgqf3xXO5YZsf3dxpt1Jnbsgsv1clwux4/L7vCV 43LZOw67w/6lKHQ55F+ur+Oyxvdw+XFZEf7ucfHNPy41vue4+Mc23Uz3/pvr7bA8b3+Vn4Vq XWV/VQ3mffxyvRw//37+8YuYK8cv1bsWiV2KQqmxy/V1/FZ5lztN+fHbar57/Hzzj1/1Hzh+ I2KTMdebjAt4DVFX5l/KdXjsfuhY+L2iX9t/bOO9SyvvMjn+GmRyfP+GY9eLvUsRx7pqwsfR 4/u/9XnPjp9LZpsrz3u2V2ab/x/Pe1S4/K3/fqPC/vOu+X/6eQfP139bxPMuCvnP/cc878Rf Sz8H4StDxVztcTSOfw4+DZVfusZvX4rfDvyv4l+JXxavHE726uFkv0H8Z+I3if9cvIX4LeK/ EL9dvKt4T/F+4gPF7xYfKZ4hfp/4FPHp4g+IzxGfJ75QfKn4Y+JF4k+KbxR/Rvw58RfEXxL/ pfjr4r8SP1TB7QsJ7+/fPid+VvyM+GlxV/yU+AnxY+IR8cPiZeL7xEvFS8R3im8TLxbfIL5W fJV4ofgS8QLxfPFc8ZniWeKTxMeLjxEfIT404fbB+O3g/feL7xXfI75LfLv4FvFN4uvEV4uv EF8mvkh8vnieeI54tvhU8QnimeKjxIeJDxJPF+8l3k28k3iaeFvxluJNxVPF64vXFq8hbsWN +NehZP8ylOyfi18U92dV4nr1b48RHy8+STxLfKZ4rni+eIH4EvFC8VXia8U3iBeLbxPfKV4i Xiq+T7xM/LB4RPyY+AnxU+Ku+GnxM+Jnxc+J++eja/Ua7fJVXqcmvkaLmuRz4rcm+Rwaltdg VeU1Wk3xuuINxRuLNxdvLd5evKN4F/Ee4n3EB4gPER8hPkZ8vPgk8SzxmeK54vniBeJLxAvF V4mvFd8gXiy+TXyneIl4qfg+8TLxw+IR8WPiTgW3E1+jObJnHNlTjuw5R/akI3vWkT3tyJ53 ZCY4MjMcmSmOzBxHZpIjM8uRmebIzHNkJjoyMx2ZqY7MXEdmsiMz25GZ7sjMd+Sc4Mg5w5Fz iiPnHEfOSY6csxw5pzlyznPkHPkbOUe+Jf6m+Bvir4m/Iv6i+PPiz4o/Lf6U+BPij4s/Kv6I +MPiD4k/KD5L/H7xyeL3io8Vv0d8qPhd4n3F7xS/Q/w28VvF24jfLN5E/EbxeuK1xKuJVxL/ h0n2v5tkj5rk9Ro1yes5apLXe9Qk74eoSd4vUZO8n6Imeb9FTfJ+jJrk/Ro1yfs5apL3e9Qk z4OoSZ4XUZM8T6Imed5ETfI8iprkeRU1yfMsapLnXdQkz8OoSZ6XUZM8T6Mmed5GTfI89m+f ED8l7oqfFj8jflb8nLh/Pqr47wqU/+DvClQv/7sC1+xrbuaHv+Zm5fVcDXk9V1u8vniqeFPx luJtxdPEO4l3E+8lni4+SHyY+CjxTPEJ4lPFs8VzxPPE54svEl8mvkJ8tfg68U3iW8S3i+8S 3yO+V3y/+EHxI+Jvi78rflL8fXG3gtuJr+dc2V+u7D9X9qcr+9eV/e3K/ndlPrgyP1yZL67M H1fmkyvzy5X55sr8c2U+ujI/XZmvrsxfV+azK/Pblfnuyvx35fzgyvnDlfOLK+cfV85Prpy/ XDm/uXL+c+X86Mr59AM5n74nflz8HfGj4ofED4i/Kv6y+G7xHeJbxTeLrxdfI75SfLn4YvEF 4nPFZ4vPEJ8mPlF8nPho8eHig8X7i/cW7y7eWbyDeDvxVuLNxBuJNxCvI54iXkXcynq1sp6t rHcr+8HKfrGyn6zsNyv70cp+tbKfrex3K/PAyrywMk+szBsr88jKvLIyz6zMOyvz0Mq8tDJP rcxbK/PYyry2Ms+tzHsr5wMr5wsr5xMr5xtrru3X3H7Ma7TYa2KT/DW3UpP8NbdErxpK9pri dcUbijcWby7eWry9eEfxLuI9xPuIDxAfIj5CfIz4ePFJ4lniM8VzxfPFC8SXiBeKrxJfK75B vFh8m/hO8RLxUvF94mXih8Uj4sfEnQpuv2SSvybzgvhz4s+IbxR/UrxI/DHxpeILxeeJzxF/ QHy6+BTx+8QzxEeK3y0+ULyfeE/xruK3i6eZ5K95pZnkr3kl+pvib4i/Jv6K+Iviz4s/K/60 +FPiT4g/Lv6o+CPiD4s/JP6g+Czx+8Uni98rPlb8HvGh4neJ9xW/U/wO8dvEbxVvI36zeBPx G8XridcSryZeSfwfJtn/bpLdP38lrteoSV7P/u2e4v3EB4rfLT5SPEP8PvEp4tPFHxCfIz5P fKH4UvHHxIvEnxTfKP6M+HPiL4i/ZP5n/1zwY1P+92ODx/Cn+O3A/yz+F/Go+Lfi4VCyVw0l e03xuuINxRuLNxdvLd5evKN4F/Ee4n3EB4gPER8hPkZ8vPgk8SzxmeK54vniBeJLxAvFV4mv Fd8gXiy+TXyneIl4qfg+8TLxw+IR8WPiJ8RPibvip8U/rOD2kYT3928fFN8vvld8j/gu8e3i W8Q3ia8TXy2+QnyZ+CLx+eJ54jni2eJTxSeIZ4qPEh8mPkg8XbyXeDfxTuJp4m3FW4o3FU/9 Cf7b+O3A3xc/Kf6u+NviR8QPiu8X3yu+R3yX+HbxLeKbxNeJrxZfIb5MfJH4fPE88RzxbPGp 4hPEM8VHiQ8THySeLt5LvJt4J/E08bbiLcWbiqeK1xevLV5D3Iob8a9Nsn9pkv1z8Yvi58U/ jl/vmnC7uXhr8fbiHcW7iPcQ7yM+QHyI+AjxMeLjxSeJZ4nPFM8VzxcvEF8iXii+Snyt+Abx YvFt4jvFS8RLxfeJl4kfvoavWX/Mvzdw45fgMZyO3w78jPhZ8XPiF8Q/E/9C/G/i34iHQsle JZTsKeJ1xBuINxJvJt5KvJ14B/HO4t3Fe4v3Fx8sPlx8tPg48Yni08RniM8Wnyu+QHyx+HLx leJrxNeLbxbfKr4jfruGLf+7AjVqVPx3BS7E/6G2/3cF+HMo+Vgvy6/1qvgB8UPiR8XfET8u /p74B+K/E/+9+EfifxQ/L/5pBbc/kH9L9J74cfF3xI+KHxI/IP6q+Mviu8V3iG8V3yy+XnyN +Erx5eKLxReIzxWfLT5DfJr4RPFx4qPFh4sPFu8v3lu8u3hn8Q7i7cRbiTcTbyTeQLyOeIp4 FVmvVtazlfVuZT9Y2S9W9pOV/WZlP1rZr1b2s5X9bmUeWJkXVuZJou8W3yG+VXyz+HrxNeIr xZeLLxZfID5XfLb4DPFp4hPFx4mPFh8uPli8v3hv8e7incU7iLcTbyXeTLyReAPxOuIp4lXE Q+LfmGT/m0n2L8Q/E78gfk78rPgZ8dPirrgb/7ttiV5bvL54qnhT8ZbibcXTxDuJdxPvJZ4u Pkh8mPgo8UzxCeJTxbPFc8TzxOeLLxJfJr5CfLX4OvFN4lvEt4vvEt8jvld8v/hB8SPib4u/ K35S/H1x90f+/uaG+Fo0CX/nMvZtn0LVYms6JfabnNh3Wwh/HvqXsP99GL4KX3mNWDn+9YLK sa+bh2PvGQr7/3rc/y4N34SDf0le/n6h2K/XqpKt8Pssld8j+SOHY28vefcs/5Ut/zo9+IiV 4/962/+d2dfhi5fl+yy1SJ+Xk/V932EpeAbl969jqibcPxQOtxi7eP6CGXN+6P6V4p+B8sfT IXRT7DNRPZz4K/h7vFONfNMk5H/2h8zIyn6oIGveghnz5t/gnd9TvGPi/5fiPdOqsZ9T+NgV f9Yr/8jPuk34rH/3O/Qkf56tfF4rJx3hH/c8a8ae58HQ4JD/O4gxbe7yfn3/v2v9bCr6vjbX /tk0jD+bm8L+TE+fPn1uQd6CnLxZtRKOWVXvfv7ba/0MK/rOL9f+GTaIP8M7Y9+hZUTWvNwZ /hOcVTe+ClOu+fOr+DmE5eOU7/nWlcJ8J5Tg103ee9/9HPzXHl8VeXxVfvDxBd+x5Hp5PMF3 Erl+Hk/5d/i42uMJ7h88rnD8q2r68WzsX0J/Gvo0ZGPfQ+PT0KVQ0P5K+4p2mVY5HLTq4aDd QPsZ7Sbaz2ktaLfQfkG7ndaV1pPWjzaQdjdtJC2Ddh9tCm067QHaHNo82kLaUtpjtCLak7SN tGdoz9FeoL1E+yXtddqvaIfi1y7Er9UPn6OdpZ2hnaa5tFO0E7RjtAjtMK2Mto9WSiuh7aRt oxXTNtDW0lbRCmlLaAW0fFoubSYtizaJNp42hjaCNjTh2sG4Dg3tp+2l7aHtom2nbaFtoq2j raatoC2jLaLNp+XRcmjZtKm0CbRM2ijaMNogWjqtF60brRMtjdaW1pLWlJZKq0+rTatBszRD +zoUtC9DQfucdjEUHK1gDo2JX/OPatAm0bJoM2m5tHxaAW0JrZC2iraWtoFWTNtG20kroZXS 9tHKaIdpEdox2gnaKZpLO007QztLO0e74F37KeeBy985P105D0RNMHe+pYWZ+VU5D9Sk1aU1 pDWmNae1prWndaR1ofWg9aENoA2hjaCNoY2nTaJl0WbScmn5tALaElohbRVtLW0DrZi2jbaT VkIrpe2jldEO0yK0YzSHo+2wAhxWhcNKcVg9DivKYZU5rDyH1eiwQh1WrcNKdljdDiveYRc4 7AyH3eKwgxx2lcNOc9h9DjvSYZc67FyH3eywwx12vcMkcJgODhPDYYo4TBaHaXPl2m+YRW/R 3qS9QXuN9grtRdrztGdpT9Oeoj1Be5z2KO0R2sO0h2gP0mbR7qdNpt1LG0u7hzaUdhetL+1O 2h2022i30trQbqY1od1Iq0erRatGq0T7hwna301wtII5NCZ+zT+qQZtEy6LNpOXS8mkFtCW0 Qtoq2lraBloxbRttJ62EVkrbRyujHaZFaMdoJ2inaC7tNO0M7SztHO2Cd+0n/X7AXP33A5bz QA1abVp9WiqtKa0lrS0tjdaJ1o3Wi5ZOG0QbRhtFy6RNoE2lZdNyaHm0+bRFtGW0FbTVtHW0 TbQttO20XbQ9tL20/bSDtCO0t2nv0k7S3qe5HG2XFeCyKlxWisvqcVlRLqvMZeW5rEaXFeqy al1WssvqdlnxLrvAZWe47BaXHeSyq1x2msvuc9mRLrvUZee67GaXHe6y610mgct0cJkYLlPE ZbK4TJsr1z4wwSx6j3ac9g7tKO0Q7QDtVdrLtN20HbSttM209bQ1tJW05bTFtAW0ubTZtBm0 abSJtHG00bThtMG0/rTetO60zrQOtHa0VrRmtEa0BrQ6tBRaFY6W5QhajqrlSFuOvmVFWFaJ ZeVYVpNlhVlWnWUlWlanZcVaVrFlZVtWu2UHWHaFZadYdo9lR1l2mWXnWXajZYdadq1lJ1t2 t2XHW6aAZTLYa3QeKDXBuaXUfEsLfj9QaoLfD5SamrS6tIa0xrTmtNa09rSOtC60HrQ+tAG0 IbQRtDG08bRJtCzaTFouLZ9WQFtCK6Stoq2lbaAV07bRdtJKaKW0fbQy2mFahHaMFryKfckE r3FfoD1He4a2kfYkrYj2GG0pbSFtHm0O7QHadNoU2n20DNpI2t20gbR+tJ60rrTbaWkJ14LX 72nmLdqbtDdor9Feob1Ie572LO1p2lO0J2iP0x6lPUJ7mPYQ7UHaLNr9tMm0e2ljaffQhtLu ovWl3Um7g3Yb7VZaG9rNtCa0G2n1aLVo1WiVaMHr9zQTvH6/nbnR1QSvU3vS+tEG0u6mjaRl 0O6jTaFNpz1Am0ObR1tIW0p7jFZEe5K2kfYM7TnaC7SXzE97vX31r7tEzMfxjxkxf6L9mfYX WpT2LS2YxxHmcYR5HGEeR5jHEeZxhHkcYR5HmMcR5nGEeRxhHkeYxxHmcYR5HGEeR5jHEeZx hHkcYR5HmMcR5nGEeRxhHkeYxxHmcYR5HGEeR5jHEeZxhHkcYR5HmMcR5nGEeRxhHkeYxxHm cYR5HDEnaKdoLu007cP4tSPxa/XDB2n7aXtpe2i7aNtpW2ibaOtoq2kraMtoi2jzaXm0HFo2 bSptAi2TNoo2jDaIlk7rRetG60RLo7WltaQ1paV+b0s1v6W9TztJe5f2Nu0I7SBtP20vbQ9t F207bQttE20dbTVtBW0ZbRFtPi2PlkPLpk2lTaBl0kbRhtEG0dJpvWjdaJ1oabS2tJa0prRU Wn1abVoNmqUZ2tcmaF+aoH1Ou0g7H2+NmZjN49fqh1vT2tM60rrQetD60AbQhtBG0MbQxtMm 0bJoM2m5tHxaAW0JrZC2iraWtoFWTNtG20kroZXS9tHKaIe9a9fmT4xdE/zu2TWnaWdoZ2nn aBdon9G+oP2N9g0tFApaleBr2SaFVofWgNaI1ozWitaO1oHWmdad1pvWnzaYNpw2mjaONpE2 jTaDNps2l7aAtpi2nLaStoa2nraZtpW2g7ab9jLtVdoB2iHaUdo7tOO092gf0H5H+z3tI9of aedpwZ9bfWCCP8t6j3ac9g7tKO0Q7QDtVdrLtN20HbSttM209bQ1tJW05bTFtAW0ubTZtBm0 abSJtHG00bThtMG0/rTetO60zrQOtHa0VrRmtEa0BrQ6tBRaFZrlaFmOoOWoWo605ehbVoRl lVhWjmU1WVaYZdVZVqJldVpWrGUVW1a2ZbVbdoBlV1h2imX3WHaUZZdZdp5lN1p2qGXXWnay ZXdbdrxlClgmg2VaWCaIZapYJo1l+lgmkmVKWSaXZZpZJpxl6lkmoWU6WiamZYpaJqtl2lom sGUqWya1ZXpbJrplylsmv+VsUMMEX2mtTatPS6U1pbWktaWl0TrRutF60dJpg2jDaKNombQJ tKm0bFoOLY82n7aItoy2graato62ibaFtp22i7aHtpe2n3aQdoT2Nu1d2kna+wlnZ/eqZ/zy /2eq/wTF7VngAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAOgDrCIAAAEA 6QMoAAAAgBYAAOAQAADgEAAAgBYAAAUAAAAKAAAAAAAAAAAAAAABAAAAAAAAAQ8ACQTOAQAA AAAKBAQAAAAJAAAADwDMD44AAAAAAM0PCAAAAAAAAAABAAAAAQDDDxgAAAABAAAAAAAAAAQA AAAAAAAADAAAAABOzQAQALoPCgAAAFYASQBTAEkATwAgALoPHgAAAFYAaQBzAGkAbwAuAEQA cgBhAHcAaQBuAGcALgA1ADAAug8eAAAAVgBJAFMASQBPACAANQAgAEQAcgBhAHcAaQBuAGcA DwDMD44AAAAAAM0PCAAAAAAAAAABAAAwAQDDDxgAAAABAAAAAAAAAAIAAAAAAAAADQAAAABP zQAQALoPCgAAAFYASQBTAEkATwAgALoPHgAAAFYAaQBzAGkAbwAuAEQAcgBhAHcAaQBuAGcA LgA1ADAAug8eAAAAVgBJAFMASQBPACAANQAgAEQAcgBhAHcAaQBuAGcADwDMD44AAAAAAM0P CAAAAAAAAAABAAAwAQDDDxgAAAABAAAAAAAAAAYAAAAAAAAAEAAAAABQzQAQALoPCgAAAFYA SQBTAEkATwAgALoPHgAAAFYAaQBzAGkAbwAuAEQAcgBhAHcAaQBuAGcALgA1ADAAug8eAAAA VgBJAFMASQBPACAANQAgAEQAcgBhAHcAaQBuAGcADwDyA/oBAAAvAMgPDAAAADAA0g8EAAAA AQAAAA8A1QcwAQAAAAC3D0QAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAANRC zQB02hIAXNoSACHLBjAIAAAAAAAAAHTaEgBoegcwAJwEEhAAtw9EAAAAQQByAGkAYQBsACAA QgBsAGEAYwBrAAAAbQBhAG4AAADUQs0AdNoSAFzaEgAhywYwCAAAAAAAAAB02hIAaHoHMACc BCIgALcPRAAAAEEAcgBpAGEAbAAAAEIAbABhAGMAawAAAG0AYQBuAAAA1ELNAHTaEgBc2hIA IcsGMAgAAAAAAAAAdNoSAGh6BzAAnAQiMAC3D0QAAABDAG8AdQByAGkAZQByACAATgBlAHcA AABtAGEAbgAAANRCzQB02hIAXNoSACHLBjAIAAAAAAAAAHTaEgBoegcwAJwEMQAApA8KAAAA gABgAAAA/////wAApQ8MAAAAAAAACC4AAAAHAAAAAACpDwoAAAAHAAAAAgAJBAAAQACjD24A AAAFAP/9PwAAACIgAABkAAAAAAAAAGQAAAAAAAAAAABAAgAAAAAHAAAA///vAAAAAAD///// //8YAAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAE AAAAAA8ACwSMAQAADwAA8IQBAAAAAAbwgAAAAAI8AAAPAAAAJwAAAAwAAAABAAAABwAAAAIA AAAEAAAAAwAAAAQAAAAEAAAABAAAAAUAAAAEAAAACQAAAAQAAAAAAAAABAAAAAAAAAAEAAAA CgAAAAQAAAALAAAABAAAAAwAAAAEAAAABgAAAAQAAAAIAAAABAAAAAcAAAAFAAAATwAB8LAA AAACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAADcADIAB/AkAAAA AwTuaA3Kbm78cZs3g+l0ltfx/wA1GAAAAQAAAAAAAAAAANwAMgAH8CQAAAADBDn08OeJnG6V vNfOLICJbqX/AGkYAAABAAAANRgAAAAA3AAyAAfwJAAAAAME7XtDBIKdHpNMszirnpHZ8f8A CRcAAAEAAACeMAAAAADcAGMAC/AkAAAAgQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgA AQICAAAIQAAe8RAAAAAEAAAIAQAACAIAAAj3AAAQHwDwDxwAAAAAAPMDFAAAAAIAAAAAAAAA AAAAAAAAAIAAAAAADwDQB3sBAAAfABQEHAAAAAAAFQQUAAAAuh117ADKmjsyTs3JAMqaOwEB AAEPAPoDZwAAAAAA/gMDAAAAAAEAAAD9AzQAAAA/AAAAZAAAAD8AAABkAAAAIcsGMAgAAAAA AAAAaNoSAAAAAAAAAAAAoP///+z+//8BAAAAcAD7AwgAAAAAAAAAcAgAAHAA+wMIAAAAAQAA AEALAAAfAAcEPAAAAAAA/QM0AAAAIQAAAGQAAAAhAAAAZAAAAKOLBzAk3hIAAAAAAMBDzQAA AAAAAAAAAAAAAAAAAAAAAAESAB8AEwQ8AAAAAAD9AzQAAABkAAAAZAAAAGQAAABkAAAAo4sH MCTeEgAAAAAAwEPNAAAAAAAAAAAAAAAAAAAAAAAAARIAHwD/AxQAAAACAAAEDAAAAAAAAAAA AAAAAgAAAB8ACAQ8AAAAAAD9AzQAAABCAAAAZAAAAEIAAABkAAAAlNoSAG+PBzAk3hIAAQAA AAAAAAAAAAAAAAAAAAAAAAAAABIAPwDZDwwAAAAAANoPBAAAAAAAJQAPAPAPRRsAAAAA8wMU AAAAAwAAAAAAAAACAAAAAAEAAAAAAAAAAJ8PBAAAAAYAAAAAAKgPHQAAAE1hbmRhdG9yeSBS ZXBsaWNhIE1hbmFnZW1lbnQgEACfDwQAAAAFAAAAAACoDxsAAABkcmFmdC1pZXRmLWxkdXAt bXJtLTAxLnR4dCAAAKEPIAAAABwAAAAAAAAAAAAaAAAAAQADAAEAAwAYAAIAAAAAAAAAAACq Dz4AAAAGAAAAAAAAAAQAAAABAAAAAwABAAAAAAAAAAQAAAABAAAAAwABAAAAAAAAAAMAAAAB AAAAAwAJAAAAAAAAAAAA8wMUAAAABAAAAAAAAAACAAAAAQEAAAAAAAAAAJ8PBAAAAAAAAAAA AKgPEgAAAFN0cnVjdHVyZSBvZiBEcmFmdBAAnw8EAAAAAQAAAAAAoA8mAgAASwBlAHkAIABw AGEAcgB0AHMAIABvAGYAIABkAHIAYQBmAHQADQBTAGUAYwB0AGkAbwBuACAAMwAgABMgIABB AHMAcwB1AG0AcAB0AGkAbwBuAHMALwBQAHIAZQBjAHUAcgBzAG8AcgBzAA0AUwBlAGMAdABp AG8AbgAgADQAIAATICAAQQB0AG8AbQBzAA0AUwBlAGMAdABpAG8AbgAgADUAIAATICAAQwBv AG0AbQBvAG4AIABUAGEAcwBrAHMADQBTAGUAYwB0AGkAbwBuACAANgAgABMgIABEAGUAdABh AGkAbABlAGQAIABTAHAAZQBjAGkAZgBpAGMAYQB0AGkAbwBuAA0AQQB1AHQAaABvAHIAcwAg AHcAYQBuAHQAIAB0AG8AIABnAGUAdAAgAGMAbwBtAG0AZQBuAHQAcwAvAGEAZwByAGUAZQBt AGUAbgB0ACAAbwBuACAAUwBlAGMAdABpAG8AbgBzACAAMwAtADUAIABiAGUAZgBvAHIAZQAg AGQAbwBpAG4AZwAgAGQAZQB0AGEAaQBsAGUAZAAgAHcAbwByAGsAIABvAG4AIABTAGUAYwB0 AGkAbwBuACAANgAuAA0AQQBsAHMAbwAgAG4AZQBlAGQAIAB0AG8AIABzAHkAbgBjACAAdQBw ACAAdwBpAHQAaAAgAGwAYQB0AGUAcwB0ACAASQBuAGYAbwBNAG8AZAAgAGQAcgBhAGYAdAAu AAAAoQ9UAAAAEwAAAAAAABAAAFoAcQAAAAEAABAAAFoAYAAAAAAAABAAAFoAMAAAAAEAABAA AFoAEwAAAAAAAABxAAAAAAAAAGAAAAAABAAAAAQwAAAAAAgAAAAIAACqDxoAAAAFAQAAAAAA AAgAAAABAAAAAwAHAAAAAAAAAAAA8wMUAAAABQAAAAAAAAACAAAAAgEAAAAAAAAAAJ8PBAAA AAAAAAAAAKgPBgAAAElzc3VlcxAAnw8EAAAAAQAAAAAAoA8SAgAATwB2AGUAcgBsAGEAcABw AGkAbgBnACAAYQByAGUAYQBzACAAbwBmACAAcgBlAHAAbABpAGMAYQB0AGkAbwBuAA0AcgBl AHAAbABpAGMAYQBPAG4AbABpAG4AZQAgAGEAcwAgAGEAIABEAFMAQQAtAHMAcABlAGMAaQBm AGkAYwAgAGEAdAB0AHIAaQBiAHUAdABlAA0AWwBJAG4AZgBvAE0AbwBkAF0AIAATICAAUgBl AHAAbABpAGMAYQB0AGkAbwBuACAAYQBnAHIAZQBlAG0AZQBuAHQAIAB3AGkAdABoAG8AdQB0 ACAAcgBlAHAAbABpAGMAYQBEAE4ADQBTAGMAaABlAGQAdQBsAGUAcwAgAGEAcgBlACAAcgBl AGYAZQByAGUAbgBjAGUAZAAgAGIAeQAgAEQATgAuACAAIABBAHIAZQAgAHQAaABlAHIAZQAg AHIAZQBzAHQAcgBpAGMAdABpAG8AbgBzACAAbwBuACAAdwBoAGUAcgBlACAAdABoAGUAeQAg AGMAYQBuACAAYgBlAD8ADQBGAGEAaQBsACAAbwB2AGUAcgAgAHMAZQByAHYAZQByACAAEyAg AGgAbwB3ACAAdABvACAAbQBhAGsAZQAgAHMAdQByAGUAIABpAHQAIABnAGUAdABzACAAdQBw AGQAYQB0AGUAZAAgAGYAaQByAHMAdAA/AA0ADQAAAKEPFAAAAAoBAAAAAAAAAAAKAQAAAAAC ABwAAACqDz4AAAAhAAAAAAAAAA4AAAABAAAAAwAdAAAAAAAAAAcAAAABAAAAAwAiAAAAAAAA AAoAAAABAAAAAwCLAAAAAAAAAAAA8wMUAAAABgAAAAAAAAACAAAAAwEAAAAAAAAAAJ8PBAAA AAAAAAAAAKgPIAAAAE92ZXJsYXBwaW5nIEFyZWFzIG9mIFJlcGxpY2F0aW9uAAChDxQAAAAh AAAAAAAAAAAAIQAAAAAAAgAoABAAnw8EAAAAAQAAAAAAoA+IBAAAQQByAGUAIAB0AGgAZQB5 ACAAYQBsAGwAbwB3AGUAZAAgAGEAdAAgAGEAbABsAD8ADQBSAGUAZAB1AGMAZQBzACAAbgB1 AG0AYgBlAHIAIABvAGYAIABhAHIAZQBhAHMAIAByAGUAcQB1AGkAcgBlAGQADQBDAG8AbQBw AGwAaQBjAGEAdABlAHMAIABhAGQAbQBpAG4AaQBzAHQAcgBhAHQAaQBvAG4AIABvAGYAIAB0 AGgAZQAgAGEAcgBlAGEAcwANAG4AZQBlAGQAIAB0AG8AIABiAGUAIABjAGEAcgBlAGYAdQBs ACAAYQBiAG8AdQB0ACAAcwBwAGUAYwBpAGYAeQBpAG4AZwAgAGwAbwB3AGUAcgAgAGIAbwB1 AG4AZABzACAAbwBmACAAYQByAGUAYQBzAA0AQwBhAG4AIAB0AHcAbwAgAGEAcgBlAGEAcwAg AGgAYQB2AGUAIAB0AGgAZQAgAHMAYQBtAGUAIAByAG8AbwB0ACAAYwBvAG4AdABlAHgAdAA/ AA0AUgBlAGQAdQBjAGUAcwAgAG4AdQBtAGIAZQByACAAbwBmACAAYQByAGUAYQBzAA0ATgBl AGUAZAAgAG0AZQB0AGgAbwBkACAAdABvACAAZgBpAG4AZAAgAHQAaABlACAAcgBlAHAAbABp AGMAYQB0AGkAbwBuAEMAbwBuAHQAZQB4AHQAIABzAHUAYgBlAG4AdAByAGkAZQBzACAAZgBv AHIAIABhACAAZwBpAHYAZQBuACAAYQByAGUAYQAsACAAcwBpAG4AYwBlACAAZABpAGYAZgBl AHIAZQBuAHQAIAByAGUAcABsAGkAYwBhAHQAaQBvAG4AQwBvAG4AdABlAHgAdAAgAHMAdQBi AGUAbgB0AHIAaQBlAHMAIAB3AGkAdABoACAAcwBhAG0AZQAgAHAAYQByAGUAbgB0ACAAbQBh AHkAIAByAGUAZgBlAHIAIAB0AG8AIABkAGkAZgBmAGUAcgBlAG4AdAAgAGEAcgBlAGEAcwAg AG8AZgAgAHIAZQBwAGwAaQBjAGEAdABpAG8AbgANAHMAdQBiAHQAcgBlAGUAUwBwAGUAYwBp AGYAaQBjAGEAdABpAG8AbgBEAE4AIAB3AG8AdQBsAGQAIABoAGUAbABwACAAaABlAHIAZQA7 ACAAbwB0AGgAZQByAHcAaQBzAGUAIABuAGUAZQBkACAAbQBhAHQAYwBoAGkAbgBnACAAcgB1 AGwAZQAgAGYAbwByACAAcwB1AGIAdAByAGUAZQBzAHAAZQBjAGkAZgBpAGMAYQB0AGkAbwBu AC4ADQBEAG8AZQBzACAAcgBvAG8AdAAgAGMAbwBuAHQAZQB4AHQAIABvAGYAIABhAG4AIABh AHIAZQBhACAAYQB1AHQAbwBtAGEAdABpAGMAYQBsAGwAeQAgAGQAZQB0AGUAcgBtAGkAbgBl ACAAbABvAHcAZQByACAAYgBvAHUAbgBkACAAbwBmACAAYQAgABwgaABpAGcAaABlAHIAHSAg AGEAcgBlAGEAPwAAAKEPyAAAABkAAAAAAAAAAABJAAAAAQAAAAAAOgAAAAIAAAAAACoAAAAA AAAAAADLAAAAAQAAAAAAXwAAAAIAAAAAAFUAAAAAAAAAAAAZAAAAAAACABgASQAAAAAEAgAA BBQAOgAAAAAIAgAACBIAKgAAAAAMAgAADBgAkwAAAAAQAgAAEBQABAAAAAEQAgABEBQAFQAA AAAQAgAAEBQACQAAAAEQAgABEBQAFgAAAAAQAgAAEBQAXwAAAAAUAgAAFBIAVQAAAAAYAgAA GBgAAACqD1AAAAD2AAAAAAAAABIAAAABAAAAAwAuAAAAAAAAABIAAAABAAAAAwBJAAAAAAAA ABcAAAABAAAAAwAyAAAAAAAAABQAAAABAAAAAwBXAAAAAAAAAAAA8wMUAAAAEQAAAAQAAAAB AAAACQEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPIAAAAE92ZXJsYXBwaW5nIEFyZWFzIG9mIFJl cGxpY2F0aW9uAADzAxQAAAASAAAABAAAAAEAAAALAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8P AAAAV2l0aG91dCBPdmVybGFwAADzAxQAAAATAAAABAAAAAEAAAAKAQAAAAAAAAAAnw8EAAAA AAAAAAAAqA8gAAAAT3ZlcmxhcHBpbmcgQXJlYXMgb2YgUmVwbGljYXRpb24AAPMDFAAAAAcA AAAAAAAAAgAAAAQBAAAAAAAAAACfDwQAAAAAAAAAAACgD04AAAByAGUAcABsAGkAYwBhAE8A bgBsAGkAbgBlACAAEyAgAEQAUwBBAC0AUwBwAGUAYwBpAGYAaQBjACAAQQB0AHQAcgBpAGIA dQB0AGUAPwAAAKEPFAAAACgAAAAAAAAAAAAoAAAAAAACACQAAACqDxIAAAANAAAAAQAAAAMA GwAAAAAAAAAQAJ8PBAAAAAEAAAAAAKAPYgQAAHIAZQBwAGwAaQBjAGEATwBuAGwAaQBuAGUA IABzAGgAbwB1AGwAZAAgAG4AbwB0ACAAcgBlAHAAbABpAGMAYQB0AGUADQBQAGUAcgAgAFsA SQBuAGYAbwBNAG8AZABdACwAIAB0AGgAZQByAGUAIABpAHMAIABhACAAcgBlAHAAbABpAGMA YQBPAG4AbABpAG4AZQAgAGEAdAB0AHIAaQBiAHUAdABlACAAaQBuACAAZQBhAGMAaAAgAHIA ZQBwAGwAaQBjAGEAdABpAG8AbgBDAG8AbgB0AGUAeAB0ACAAcwB1AGIAZQBuAHQAcgB5AC4A DQBFAGEAYwBoACAAcwBlAHIAdgBlAHIAIABoAGEAcwAgAHIAZQBwAGwAaQBjAGEATwBuAGwA aQBuAGUAIABmAG8AcgAgAHMAZQBsAGYAIABhAG4AZAAgAGYAbwByACAAZQBhAGMAaAAgAHIA ZQBwAGwAaQBjAGEAdABpAG4AZwAgAHAAYQByAHQAbgBlAHIADQBXAGUAIABwAHIAbwBwAG8A cwBlADoADQByAGUAcABsAGkAYwBhAE8AbgBsAGkAbgBlACAAZgBvAHIAIAB0AGgAZQAgAGwA bwBjAGEAbAAgAHMAZQByAHYAZQByACAAaQBuAGQAaQBjAGEAdABlAHMAIABnAGUAbgBlAHIA YQBsACAAdwBpAGwAbABpAG4AZwBuAGUAcwBzACAAdABvACAAcgBlAHAAbABpAGMAYQB0AGUA IABmAG8AcgAgAHQAaABlACAAZwBpAHYAZQBuACAAYQByAGUAYQANAHIAZQBwAGwAaQBjAGEA TwBuAGwAaQBuAGUAIABmAG8AcgAgAGEAIABnAGkAdgBlAG4AIABwAGEAcgB0AG4AZQByACAA aQBuAGQAaQBjAGEAdABlAHMAIAB3AGkAbABsAGkAbgBnAG4AZQBzAHMAIAB0AG8AIAByAGUA cABsAGkAYwBhAHQAZQAgAHcAaQB0AGgAIAB0AGgAYQB0ACAAcABhAHIAdABuAGUAcgANAEUA ZgBmAGUAYwB0ACAALQAgAGYAbwByACAAcwBlAHIAdgBlAHIAIABBACAAYQBuAGQAIABCACAA dABvACAAcgBlAHAAbABpAGMAYQB0AGUAIABhACAAZwBpAHYAZQBuACAAYQByAGUAYQA6AA0A QQAZIHMAIAByAGUAcABsAGkAYwBhAE8AbgBsAGkAbgBlACAAZgBvAHIAIABBAA0AQQAZIHMA IAByAGUAcABsAGkAYwBhAE8AbgBsAGkAbgBlACAAZgBvAHIAIABCAA0AQgAZIHMAIAByAGUA cABsAGkAYwBhAE8AbgBsAGkAbgBlACAAZgBvAHIAIABCACwAIABhAG4AZAANAEIAGSBzACAA cgBlAHAAbABpAGMAYQBPAG4AbABpAG4AZQAgAGYAbwByACAAQQAgAG0AdQBzAHQAIABhAGwA bAAgAGIAZQAgAE8ATgAuAAAAoQ+6AAAAegAAAAAAABAAAFoASAAAAAEAABAAAFoADAAAAAAA ABAAAFoAuAAAAAEAABAAAFoANwAAAAAAABAAAFoAdQAAAAEAABAAAFoAFQAAAAAAAgAUAAQA AAABAAIAAQAUAGEAAAAAAAIAFABIAAAAAAACABIADAAAAAAEAgAABBQAuAAAAAAEAgAABBIA NwAAAAAIAgAACBQAcQAAAAAMAgAADBIAAgAAAAEMAgABDBIAAgAAAAAMAgAADBIAAACqD8YA AAAOAAAAAQAAAAMAGgAAAAAAAAAHAAAAAQAAAAMADgAAAAAAAAAOAAAAAQAAAAMAEgAAAAAA AAATAAAAAQAAAAMAGgAAAAAAAAAOAAAAAQAAAAMANgAAAAAAAAAOAAAAAQAAAAMAUwAAAAAA AAAOAAAAAQAAAAMAhAAAAAAAAAAOAAAAAQAAAAMACgAAAAAAAAAOAAAAAQAAAAMACgAAAAAA AAAOAAAAAQAAAAMADwAAAAAAAAAOAAAAAQAAAAMAFgAAAAAAAAAAAPMDFAAAAAkAAAAAAAAA AgAAAAYBAAAAAAAAAACfDwQAAAAAAAAAAACoDycAAABSZXBsaWNhdGlvbiBhZ3JlZW1lbnQg d2l0aG91dCByZXBsaWNhRE4AAKEPFAAAACgAAAAAAAAAAAAoAAAAAAACACQAAACqDxIAAAAd AAAAAAAAAAsAAAABAAAAAwAQAJ8PBAAAAAEAAAAAAKgP+QAAAFNpbmNlIHJlcGxpY2F0aW9u QWdyZWVtZW50IGlzIHVzZWxlc3Mgd2l0aG91dCByZXBsaWNhRE4sIHdoeSBub3QgbWFrZSBp dCBtYW5kYXRvcnk/DVtJbmZvTW9kXSBhdXRob3JzIGRpZCB0aGlzIHRvIGFsbG93IGZvciBy ZWZlcmVudGlhbCBpbnRlZ3JpdHkgKGluIGNhc2UgYW4gaW1wbGVtZW50YXRpb24gcmVtb3Zl cyByZWZlcmVuY2VzIHRvIGFuZCB3aGVuIHRoZSBlbnRyeSBpcyByZW1vdmVkKS4NV2UgY2Fu IGxpdmUgd2l0aCB0aGlzLgAAoQ8UAAAA+gAAAAAAAAAAAPoAAAAAAAIAHAAAAKoPPgAAAAYA AAAAAAAAFQAAAAEAAAADABMAAAAAAAAACQAAAAEAAAADAB4AAAAAAAAABwAAAAEAAAADAJ4A AAAAAAAAAADzAxQAAAALAAAAAAAAAAIAAAAIAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8ZAAAA VXBkYXRlIG9mIEZhaWxvdmVyIFNlcnZlcgAAqg8kAAAACgAAAAAAAAAJAAAAAQAAAAMABgAA AAAAAAABAAAAAQAAAAAAEACfDwQAAAABAAAAAACoD2MBAABJbiBzaW5nbGUtbWFzdGVyIHJl cGxpY2F0aW9uLCB0aGVyZSBzaG91bGQgYmUgYSB3YXkgdG8gcHJvbW90ZSBhIHJlYWRvbmx5 IHJlcGxpY2EgaWYgdGhlIG1hc3RlciBmYWlscy4NSW4gU2VjdGlvbiA1LjI0LCB3ZSBwcm9w b3NlIHVzZSBvZiBhIGZhaWxvdmVyIHNlcnZlciBpbiB0aGlzIGNhc2UuDVRoZSBmYWlsb3Zl ciBzZXJ2ZXIgc2hvdWxkIHJlY2VpdmUgdXBkYXRlcyBiZWZvcmUgb3RoZXIgc2VydmVycyBp biB0aGUgcmVwbGljYSBncm91cA1NYXN0ZXIgY2FuIGRldGVjdCB0aGUgZmFpbG92ZXIgc2Vy dmVyIHNpbmNlIGl0IGlzIHRoZSBvbmx5IG90aGVyIHNlcnZlciB3aXRoIHJlcGxpY2F0aW9u IGFncmVlbWVudHMuAAChD0AAAABnAAAAAAAAEAAAWgBDAAAAAQAAEAAAWgC6AAAAAgAAEAAA WgBnAAAAAAAAAEMAAAAABAAAAAS6AAAAAAgAAAAIAACqD1AAAABBAAAAAAAAAAkAAAABAAAA AwBCAAAAAAAAAAkAAAABAAAAAwAZAAAAAAAAAAkAAAABAAAAAwBeAAAAAAAAAAkAAAABAAAA AwBGAAAAAAAAAAAA8wMUAAAACgAAAAAAAAACAAAABwEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgP GwAAAFdoZXJlIENhbiBTY2hlZHVsZXMgUmVzaWRlPxAAnw8EAAAAAQAAAAAAqA9jAQAAcmVw bGljYUV2ZW50U2NoZWR1bGUgb2JqZWN0cyBhcmUgcmVmZXJlbmNlZCBieSBETiBmcm9tIHJl cGxpY2F0aW9uIGFncmVlbWVudHMuDUFyZSB0aGVyZSByZXN0cmljdGlvbnMgb24gd2hlcmUg dGhleSBtYXkgcmVzaWRlIGluIHRoZSBESVQ/DU11c3QgdGhleSBiZSBpbiB0aGUgYXJlYSBv ZiByZXBsaWNhdGlvbiB0aGV5IGNvbnRyb2w/DUlmIG5vdCwgd2hhdCBoYXBwZW5zIHdoZW4g dGhleSBhcmUgbm90IHByZXNlbnQgb24gc29tZSByZXBsaWNhcyBvciB3aGVuIHRoZXkgYXJl IGRpZmZlcmVudCBvbiBkaWZmZXJlbnQgcmVwbGljYXM/DVRoaXMgYWZmZWN0cyBzb21lIG9m IHRoZSBzY2VuYXJpb3MgaW4gU2VjdGlvbiA1LgAAoQ9uAAAATwAAAAAAAAAAADwAAAABAAAA AACoAAAAAgAAAAAAMQAAAAAAAAAAAE8AAAAAAAIAHAA8AAAAAAQCAAAEGAANAAAAAAgCAAAI FAACAAAAAQgCAAEIFACZAAAAAAgCAAAIFAAxAAAAAAwCAAAMHAAAAKoPEgAAABUAAAABAAAA AwBPAQAAAAAAAAAA6gMAAAAADwD4A6kIAAACAO8DGAAAAAEAAAABAgcJCAAAAAAAAAAAAAAA AAAAAGAA8AcgAAAAAAD/AP///wAAAAAA//8AAP+ZAAAA//8A/wAAAJaWlgBgAPAHIAAAAP// /wAAAAAAgICAAAAAAAAAzJkAMzPMAMzM/wCysrIAYADwByAAAAD///8AAAAAADMzMwAAAAAA 3d3dAICAgABNTU0A6urqAGAA8AcgAAAA///MAAAAAABmZjMAgIAAADOZMwCAAAAAADPMAP/M ZgBgAPAHIAAAAP///wAAAAAAgICAAAAAAAD/zGYAAAD/AMwAzADAwMAAYADwByAAAAD///8A AAAAAICAgAAAAAAAwMDAAABm/wD/AAAAAJkAAGAA8AcgAAAA////AAAAAACAgIAAAAAAADOZ /wCZ/8wAzADMALKysgAAAKMPPgAAAAEA//0/AAAAIiAAAGQAAAAAAAEAZAAAAAAAAAAAAEAC AAAAAAcAAAD//+8AAAABAP///////ywAAAAAAwAAEACjD3wAAAAFAP/9PwABACIgAABkAAAA AAAAAGQAFAAAANgAAABAAgAAAAAHAAAA///vAAAAAgD///////8gAAAAAAEAAIAFAAATINQB IAEAAAIAHACABQAAIiDQAkACAAACABgAgAUAABMg8ANgAwAAAgAUAIAFAAC7ABAFgAQAAAAA IACjD24AAAAFAP/9PwAAACIgAABkAAAAAAAAAGQAHgAAAAAAAABAAgAAAAAHAAAA///vAAAA AAD///////8MAAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAAAAAFAABgA2ADAAAAAAAF AACABIAEAAAAAFAAow9SAAAABQAAAAEJAAAAAAEAAAAAAAAAAQABCQAAAAABACABAAAAAAIA AQkAAAAAAQBAAgAAAAADAAEJAAAAAAEAYAMAAAAABAABCQAAAAABAIAEAAAAAGAAow8MAAAA AQAAAAAAAAAAAAAAcACjDz4AAAAFAAAAAAAAAAAAAgAcAAEAAAAAAAAAAgAYAAIAAAAAAAAA AgAUAAMAAAAAAAAAAgASAAQAAAAAAAAAAgASAIAAow8+AAAABQAAAAAAAAAAAAIAGAABAAAA AAAAAAIAFAACAAAAAAAAAAIAEgADAAAAAAAAAAIAEAAEAAAAAAAAAAIAEAAPAAwE4wQAAA8A AvDbBAAAEAAI8AgAAAAGAAAABgQAAA8AA/BzBAAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAA AAAAAAAAAAACAArwCAAAAAAEAAAFAAAADwAE8NIAAAASAArwCAAAAAIEAAAACgAAkwAL8DYA AAB/AAEABQCAAJx7zQCHAAEAAACBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIA AAgAABDwCAAAAIABsAHQFFAEDwAR8BAAAAAAAMMLCAAAAAAAAAABAM0ADwAN8FQAAAAAAJ8P BAAAAAAAAAAAAKgPIAAAAENsaWNrIHRvIGVkaXQgTWFzdGVyIHRpdGxlIHN0eWxlAACiDwYA AAAhAAAAAAAAAKoPCgAAACEAAAABAAAAAAAPAATwFgEAABIACvAIAAAAAwQAAAAKAACDAAvw MAAAAH8AAQAFAIAATH7NAIEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAA EPAIAAAA4ASwAdAUAA8PABHwEAAAAAAAwwsIAAAAAQAAAAIAzQAPAA3wngAAAAAAnw8EAAAA AQAAAAAAqA9SAAAAQ2xpY2sgdG8gZWRpdCBNYXN0ZXIgdGV4dCBzdHlsZXMNU2Vjb25kIGxl dmVsDVRoaXJkIGxldmVsDUZvdXJ0aCBsZXZlbA1GaWZ0aCBsZXZlbAAAog8eAAAAIQAAAAAA DQAAAAEADAAAAAIADQAAAAMADAAAAAQAAACqDwoAAABTAAAAAQAAAAAADwAE8LgAAAASAArw CAAAAAQEAAAACgAAgwAL8DAAAAB/AAEABQCAAMCBzQCBAQQAAAiDAQAAAAi/AQEAEQDAAQEA AAj/AQEACQABAgIAAAgAABDwCAAAAGAPsAFgBoAQDwAR8BAAAAAAAMMLCAAAAAIAAAAHAc0A DwAN8EAAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxYAAAACAAAAAAAAAAAAAgAAAAAA AwACAA4AAAD4DwQAAAAAAAAADwAE8MEAAAASAArwCAAAAAUEAAAACgAAgwAL8DAAAAB/AAEA BQCAAOiGzQCBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAGAP sAfQDoAQDwAR8BAAAAAAAMMLCAAAAAMAAAAJAs0ADwAN8EkAAAAAAJ8PBAAAAAQAAAAAAKgP FQAAAElFVEYgNTMgLSBNaW5uZWFwb2xpcwAAoQ8YAAAAFgAAAAAAAAgAAAEAFgAAAAAAAwAC AA4ADwAE8LoAAAASAArwCAAAAAYEAAAACgAAgwAL8DAAAAB/AAEABQCAAEiLzQCBAQQAAAiD AQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAGAPIBDQFIAQDwAR8BAAAAAA AMMLCAAAAAQAAAAIAs0ADwAN8EIAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxgAAAAC AAAAAAAACAAAAgACAAAAAAADAAIADgAAANgPBAAAAAAAAAAPAATwSAAAABIACvAIAAAAAQQA AAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAA AD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKysgAgALoPHAAA AEQAZQBmAGEAdQBsAHQAIABEAGUAcwBpAGcAbgAPAO4D5AEAAAIA7wMYAAAAAAAAAA8QAAAA AAAAAAAAgAAAAAAHAAAADwAMBJQBAAAPAALwjAEAACAACPAIAAAAAwAAAAMIAAAPAAPwJAEA AA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAACAAABQAAAA8ABPBy AAAAEgAK8AgAAAACCAAAIAIAAFMAC/AeAAAAfwAAAAQAgAD0JLwBvwEAAAEA/wEAAAEAAQMC BAAAAAAQ8AgAAACgBbAB0BRwCA8AEfAQAAAAAADDCwgAAAAAAAAADwC8AQ8ADfAMAAAAAACe DwQAAAAAAAAADwAE8HIAAAASAArwCAAAAAMIAAAgAgAAUwAL8B4AAAB/AAAABACAAIQlvAG/ AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAJAJYAMgE+ANDwAR8BAAAAAAAMMLCAAAAAEAAAAQ ALwBDwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAAABIACvAIAAAAAQgAAAAMAACDAAvwMAAA AIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8Acg AAAA////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKysgAPAO4D5AEAAAIA7wMYAAAAAQAA AA0OAAAAAAAAAAAAgAAAAAAHAAAADwAMBJQBAAAPAALwjAEAADAACPAIAAAAAwAAAAMMAAAP AAPwJAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAADAAABQAA AA8ABPByAAAAEgAK8AgAAAACDAAAIAIAAFMAC/AeAAAAfwAAAAQAgACcgrwBvwEAAAEA/wEA AAEAAQMCBAAAAAAQ8AgAAACQALAB0BTQAg8AEfAQAAAAAADDCwgAAAAAAAAADQC8AQ8ADfAM AAAAAACeDwQAAAAAAAAADwAE8HIAAAASAArwCAAAAAMMAAAgAgAAUwAL8B4AAAB/AAAABACA AFiDvAG/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAGADsAHQFAAPDwAR8BAAAAAAAMMLCAAA AAEAAAAOALwBDwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAAABIACvAIAAAAAQwAAAAMAACD AAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQAB ABAA8AcgAAAA////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKysgAPAO4D5AEAAAIA7wMY AAAAAQAAAA0OAAAAAAAAAAAAgAAAAAAHAAAADwAMBJQBAAAPAALwjAEAAEAACPAIAAAAAwAA AAMQAAAPAAPwJAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAA EAAABQAAAA8ABPByAAAAEgAK8AgAAAACEAAAIAIAAFMAC/AeAAAAfwAAAAQAgABwubwBvwEA AAEA/wEAAAEAAQMCBAAAAAAQ8AgAAACQALAB0BTQAg8AEfAQAAAAAADDCwgAAAAAAAAADQC8 AQ8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HIAAAASAArwCAAAAAMQAAAgAgAAUwAL8B4AAAB/ AAAABACAAAC6vAG/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAAADsAHQFAAPDwAR8BAAAAAA AMMLCAAAAAEAAAAOALwBDwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAAABIACvAIAAAAARAA AAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAA AD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKysgAPAO4D5AEA AAIA7wMYAAAAAQAAAA0OAAAAAAAAAAAAgAAAAAAHAAAADwAMBJQBAAAPAALwjAEAAFAACPAI AAAAAwAAAAMUAAAPAAPwJAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK 8AgAAAAAFAAABQAAAA8ABPByAAAAEgAK8AgAAAACFAAAIAIAAFMAC/AeAAAAfwAAAAQAgABw xbwBvwEAAAEA/wEAAAEAAQMCBAAAAAAQ8AgAAABgALAB0BDFdNleHG41qse5k+jhMX9oWnRbl+UoSk wC3363bL NG0+/lXwi+DnwU+BF4MfAz8CXgR+AHwv+C7w7eAF4BvA14CvAF8CvgB8Dvh08GzwieBZ4Gng KeDDwRPAB4P3B+8DHgkeDh4K3gW8A3gguB94C3AvcCV4PXA3cCdwB3BrcB5c3O+spT9jNb0C /D74bfBrf9HF6SLwI+DHwIvBT4GfB78IfhX8Fvg98IfgT8FfgotrN1i6uB9FS7cHV4C7gnuA e4I3BfcBbw0eAB4E3hk8BDwMPAK8N3g/8EHg8eBJ4KPAteCZ4BPAp4BPA58NPh98Mfhy8NXg 68E3g28D3wm+B3w/uA78MPhR8OPgJ8HPgZeAXwG/CX4X/AH4E/BKCxefiwYLv2iapvdX8FPg xeDHwI+AF4EfAN8Lvgt8O3gB+AbwNeArwJeALwCfAz4dPBt8IngWeBp4Cvhw8ATwweD9wfuA R4KHg4eCdwHvAB4I7gfeAtwLXAleD9wN3AncAdwaXPaG6ZcWxxenn4I/BL8Hfgv8KvhF8PPg p8CLwY+BHwEvAj8Avhd8F/h28ALwDeBrwFeALwFfAD4HfDp4NvhE8CzwNPAU8OHgCeCDwfuD 9wGPBA8HDwXvAt4BPBDcD7wFuBe4ErweuBu4E7gDuDU4Dy4uk1q6uExq6RXg98Fvg18DLwX/ Bfw0+M/gP4B/B/4t+FfgX4B/xn5vXQHjD60rUMu4roDleX0K5/UJXNZG8LXgK8GXgueCfwg+ AzwH/H3w98DHgo8GHwE+FHwI+DvgfcHfBu8B3hVcDf4WeFtwFXhL8GbgjcDF77X+yvdv/+j7 MAN789/VOIvrIP4NR/xbfTuLaUe+ptuCS8Et3+/E6RdcTX8MrgcvA78Bfhn8AvhZ8BPgP4F/ D34I/BvwfeC7wQvBt4JvAl8Hvgo8D3wR+DzwWeBTwSeDjwfPAE8FTwZPBI8DHwgeCx4N3gu8 O3gweCfw9uD+4L7g3uBNwBuCu4O7gMvB7cBl4Ay8ktX0J/D8fAB+F/wm+BXwEvBz4CfBj4Mf BT8MrgPfD74HfCf4NvDN4OvBV4MvB18MPh98Nvg08CngE8AzwbXgo8CTwOPBB4H3A+8NHgEe Bh4C3hk8CDwAvLWFi98VWP6947hp2uxHwQ+D68D3g+8B3wm+DXwz+Hrw1eDLwReDzwefDT4N fAr4BPBMcC34KPAk8HjwQeD9wHuDR4CHgYeAdwYPAg8Abw3uA94U3BPcA9wVXAHuYHo8trOY DgAPAu8MHgIeBh4B3hu8H/gg8HjwJPBR4FrwTPAJ4FPAp4HPBp8Pvhh8Ofhq8PXgm8G3ge8E 3wO+H1wHfhj8KPhx8JPg58BLwK+A3wS/C/4A/Al4Jbj4fm7p4vu9pduBy8FdwN3BG4I3AfcG 9wX3B28P3gk8GLw7eC/waPBY8IHgceCJ4MngqeAZ4OPBJ4NPBZ8FPg98EXge+CrwdeCbwLeC F4LvBt8H/g34IfDvwX8CPwF+FvwC+GXwG+Bl4Hrwx+AvwA3gUr6m2/I13RHc+S+4E1fz860b eD1wJbgXeAtwP/BA8A7gXcBDwcPBI8H7gPcHHwyeAD4cPAU8DTwLfCJ4Nvh08DngC8CXgK8A XwO+AbwAfDv4LvC94AfAi8CPgB8DLwY/ZZr+Z32HI25b6o++wzFwNb+DEZ9Pls8xW76mO4I7 g9cFbwDeGLw5eCvwNuDtwDuCa8C7gfcEjwKPAR8A/i74MPCR4GPA08HHgU8C/wB8Jvhc8IXg y8A/As8H/xh8C/gO8M/BvwT/Gvwg+N/AfwT/O/gZ8F/BL75h+pXF8cXpZ+AV4PfBb4NfAy8F /wX8NPjP4D+Afwf+LfhX4F+Afwb+Kfgn4BvB14KvBF8Kngv+IfgM8Bzw98HfAx8LPhp8BPhQ 8CHg74D3BX8bvAd4V3A1+FvgbcFV4C3Bm4E3Aq8PXge8NngtcBtwCXgVq+nPWU1/BF4Ofgf8 Ovgl8F/Bz4D/HfxH8L+BHwT/GvxL8M/Bd4BvAf8YPB/8I/Bl4AvB54LPBP8AfBL4OPB08DHg I8GHgb8LPgA8BjwKvCd4N3ANeEfwduBtwFuBNwdvDN4AvC64M7gjuK2Fl/DGv7WZ/Zxp2uwn wY+DHwU/DK4D3w++B3wn+DbwzeDrwVeDLwdfDD4ffDb4NPAp4BPAM8G14KPAk8DjwQeB9wPv DR4BHgYeAt4ZPAg8ALw1uA94U3BPcA9wV3AFuD24Ffg3VsZ1BdJrvXldAXE9AfGnersCcF7i ukiW5/WUq+kPwe+B3wK/Cn4R/Dz4KfBi8GPgR8CLwA+A7wXfBb4dvAB8A/ga8BXgS8AXgM8B nw6eDT4RPAs8DTwFfDh4Avhg8P7gfcAjwcPBQ8G7gHcADwT3A28B7gWuBK8H7gbuBO4Abg3O g4vrIln6M/bXXJy2A5eDu4C7gzcEbwLuDe4L7g/eHrwTeDB4d/Be4NHgseADwePAE8GTwVPB M8DHg08Gnwo+C3we+CLwPPBV4OvAN1l4JTOuI2x28YW6wMJlXE23A5eDu4C7gzcEbwLuDe4L 7g/eHrwTeDB4d/Be4NHgseADwePAE8GTwVPBM8DHg08Gnwo+C3we+CLwPPBV4OvAN4FvBS8E 3w2+D/wb8EPg34P/BH4C/Cz4BfDL4DfAy8D14I/BX4AbwMXp7eC7wPeCHwAvAj8Cfgy8GPwU +Hnwi+BXwW+B3wN/CP4U/CU4x9V0K66m24MrwF3BPcA9wZuC+4C3Bg8ADwLvDB4CHgYeAd4b vB/4IPB48CTwUeBa8EzwCeBTwKeBzwafD74YfDn4avD14JvBt4HvBN8Dvh9cB34Y/Cj4cfCT 4OfAS8CvgN8Evwv+APwJeCW4OP7M32fE7xDEZTNmOq14uHrzapxN9TKe+DnNuLTnwHvw13nh 9OwF//qzmHFfocbfvPBBTDwmx4v/6l38VyMveWb6F/DmfYqKl9dUInvj9syMp6h5zrxpL6Qc M16yrNrE86y5l1LG/nPXTGJxzX67VbKa10XyX3bZb9p62P+vy37TVr7+qy/7zefPw/kY73sv CU9b3jJfLqtxuf/s6yeF6yf9w+tn3kLWv8r1MW+56l/n+hi3KPV718dy+o8vH18jXk+b58v4 EDH85vqI5+vCu9Mevt1pr9/utCdwd9o7uDvtMdyd9iLuTnsWd6e9jbvTHsjdaa/k7rSncnfa e7k77dHcnfZy7k57PnenvaG70x7S3Wmv6e60J3V32ru6O+1x3Z32wu5Oe2Z3p721u9Me3N1p r+7utKd3d9r7uzvtEd6d9hLvTnuOd6e9ybvTHubdaa/z7rQnenfaO7077bHenfZi7057tnen vd27C5/0zM2FmpyaHTUZNUatkpnbE7p/H1C7S+0mtSvUSqido3aS2nFqR6kdpqajtp/aHmo7 qW2jtpnaemqrqS2ntpjafGqzqU2jNoXaBGqZ1LTURlFLohZPbRC1ftR6U4ugFkYthFpnakHU Aqi1puZDrSk1T2oe1FypKajZU7P63df7/9+vH2Wmx2FD0yEXvgk1b2q+1PyptafWiVowte7U elGLphZLbSC1OGqJ1JKppVLLoDae2mRqU6nNojaP2iJqedRWUVtHbRO1rdQKqe2mto/aAYtD t0x6gF2ldpHaeWqnqBVTO0btCLUiageo7aW2i9p2agXUNlBbQ20FtSXUFlCbQ206tWxqE6ll UUujlkJtOLUEaoOp9afWh1oktXBqodS6UOtALZCaH7UW1LyoKanVo+ZGzYmaAzVrajy1V8zc njFzq6B2n9ptatf+QSsyHXLmj1A7Rq2Y2ilq56ldpHaV2i1q96g9pPaU2ktqHGduVpy52VNT UHOl5kHNk1pTaj7UWlMLoBZErTO1EGph1CKo9abWj9ogavHUkqiNoqallkltArUp1KZRm01t PrXF1JZTW01tPbXN1LZR20ltD7X91HTUDlM7Su04tZPUzlEroXaF2k1qd6k9oPaEWiU1A3fV 1AzcRWrnqZ2iVkztGLUj1IqoHaC2l9ouatupFVDbQG0NtRXUllBbQG0OtenUsqlNpJZFLY1a CrXh1BKoDabWn1ofapHUwqmFUutCrQO1QGp+1FpQ86KmpFaPmhs1J2oO1KypyUyHXpoOufBP qT2kdo/aLWpXqV2kdp7aKWrF1I5RO0KtiNoBanup7aK2nVoBtQ3U1lBbQW0JtQXU5lCbTi2b 2kRqWdTSqKVQG04tgdpgav2p9aEWSS2cWii1LtQ6UAuk5ketBTUvakpq9ai5UXOi5kDNmhpP TXxfMrZnzNwqqN2ndpvaNWql1H6hdpraz9R+oPYdtW+pfUXtC2qfUfuU2ifUNlJbS20ltaXU cql9SG0GtRxq71N7j9pYaqOpjaA2lNoQau9Q60vtbWo9qHWlpqb2FrW21FTUWlJrRq0RtfrC 73/8eaDm8jwu/79enhe/bTOep6PpkAtvS01KzcCZ2wvO3B5T01P7f+3cf3zXcwLA8e+mobhE yymnnEJho3Ka05zGmjRspUVD62rS0JzmNKdJQ3MaGhoaGtobC0stLCwsLCxZR466E1fuyp3c yZ2wa+37fT48PPz46+4vn7/e3+fn8X18H9/H5/vH9/3+vD7vLWwTe4+9y95ib7DX2MvsBfYs e4otZY+xh9lCtoDNZ/PYXDaHzWaz2Aw2nU1jU9kUNomNZ+PYGJbFRrLhbBgbyoawQSyJ9Wd9 WW/WkyWyfVgXlsAibIe1ou2RmG1jW9lmtpGtZ+tYK2thzayJNbIGVs/qWC2rYdWsilWyClbO ylgpK2HFrIgVsgKWz/JYLsth2SyTZbA0lspS2GCWzJIirVFLirSwZtbEGlkDq2d1rJbVsGpW xSpZBStnZayUlbBiVsQKWQHLZ3ksl+WwbJbJMlgaS2UpbDBLZgNYP9aH9WI9WLeoJUfniTtn N2aMKSyVpbEMlsmyWQ7LZXksnxWwQlbEilkJK2VlrJxVsEpWxapZDatldayeNbBG1sSaWQtr ZevYeraRbWZb2Ta2ne1gkbiYJcTFrAvbhyWynqw368v6syQ2iA1hQ9kwNpyNZFlsDBvHxrNJ bAqbyqax6WwGm8VmszlsLpvH5rMFbCF7mD3GlrKn2LPsBfYye429wd5i77L32Ca2hX3MPmWf szbWKT5mneNj1pV1/17rHr8v258dyA5mh7Ij2NHsWHY8O5GdzE5lp7NRbCw7l01gF7CL2KXs cnYlu5pdy25gN7Fb2R3sbnYfC2wRW8yWseVsBVvJVrHVbO0P3Gv7xlp323etdbfFtfl9dIqP Wef4mHVl3dkB7CB2CDucHcUGsuPYCewkls5OY2eys9g57Hw2kV3ILmGXsSvYVewadj27kd3C bmd3sXvZA+wh9ihbwp5kz7Dn2UvsVbaGvcneYRuioy+jo8T4f7N/sr+zv7IP2J/YH9kf2Ovs FfYie449zZ5gj7NH2IPsfnYPu5Pdxm5mv2fXsZnsd+y37DfsYjaZ/Zqdx85mo9kZbAQ7hf2K /ZL9gh3DjmSHsZ+zn7Gfsv3YT9iebDf2VSRm/4nE7F/sH+xv7C/sz+wd9iZbw15lL7Hn2TPs SbaEPcoeYg+we9ld7HZ2C7uRXc+uYVexK9hl7BJ2IZvIzmfnsLPYmew0ls5OYiew49hAdhQ7 nB3CDmIHsO6sK+vMEiLro5YQWcdaWQtrZk2skTWwelbHalkNq2ZVrJJVsHJWxkpZCStmRayQ FbB8lsdyWQ7LZpksg6WxVJbCBrNkNoD1Y31YL9aDdWN7sd1ZHPsiLmafxf6dRz5hH7EP2fts A3ubrWWr2Sq2kq1gy9kytpgtYoHdx+5md7Bb2U3sBnYtu5pdyS5nl7KL2AVsAjuXjWWj2Ons VHYyO5Edz45lR7Mj2KHsYHYg25/ty/Zme7B4Frt/muD+6bdZl+ho5yyNJbKerDfry/qzJDaI DWFD2TA2nI1kWWwMG8fGs0lsCpvKprHpbAabxWazOWwum8fmswVsIQsqoqAsCmqjoEAKqqSg VArqpaBoCiqnoHwKaqigkAqqqaCkCuqqoLgKKqygzApqraDgCqquoPQK6q+gCAsqsaAcC2qy oDALqrOgRAvqtKBYCyq2oGwLareggAuquKCUC+q5oKgLKrugvAtqvKDQC1b+gpIvqPtCZBPb wj5mn7LPWWy2syg6SoxfzJax5WwFW8lWsdVsLXubbWDvsw/ZR+wT9hn7gsWZoe0eF7O9WDfW g/VifVg/NoAls8EshaWyNJbBMlk2y2G5LI/lswJWyIpYMSthpayMlbMKVsmqWDWrYbWsjtWz BtbImlgza2GtbB1bzzayzWwr28a2sx1fm5W3fedMf9fe6j8e/4cjaWDHk7Cj8icWTZg6+eL8 XftWJkTPHhPpKK0ndbyc2b4PfPuqS/vemO3XaGb0dft413OBOVkjThmfNSo9Z0T62NEd53Z5 O2eOOGNk2rDR6dH3fLDzYrfvD9G5U8ezrZ2in7l3t//5l/7xcPwXNJx+3hAAERA0UAAAADYB AHic7N0HQFP33v/x3zkJG02QoaCVqKDigAgOrCMBVFBBcKCto4CCioMgw1UVXFUrinvUgaNK HRVt1VZtG27VVr2ttI6qrYoTBypxLyT/3yHJt+FTe9s+z73//73P/+HeX8l5v7JO5kk4nvND kcul9bu8LjP46chkrMLowGytmsiHYJlQ/jpdYTQaLfktPoz/+/Mf8/OKj3DzfbiS/7bhQ7rP 7fiw58OBD0c+nPhw5qMaH9X5UJgeAsyFjxp8uPLhxoc7Hx581OSjFh+efHjxUZuPOny8wUdd Prz5UPFRj4/6fDTgw4cPXz4a8tGIj8Z8+PHRhI+mfDTjozkf/nwE8KHmowUfgXwE8dGSj1Z8 tOajDR/BfLTl400+2vHRno8OlY9txjR8aPkI4SOUjzA+OvHRmY8u5ttDGl354W58dOcjko8o PnrwEc1HDB89+ejFR28++vARy0dfPvqZz0O6ffvzwwP4GMjHID7e4SOOj3g+EvgYzMcQPhL5 SOJjKB/D+BjORzIfI/gYyccoPkbzkcKHjo9UPsbwkcZHOh8ZfGTyMZaPcXyM52MCHxP5eJeP SXxM5mMKH1l8ZFdedx3/Xwa/Lzrz883g5yWd4s//ePBHjOWxJL0e1PASK3uhibtYHzf1nbQL Hxz/myCT3HQ0/voRzecr6S9dpvWPIxMF68fznz2dG7Ncfhif/9H8tozm98OIv3z5NfjlS6+B cmZ63fszp5GOn2w+LJrnP4bf8kn8XlRX/u/P/9T6L8y/dF03zzQdrjDfb5bH++89/yv+pa9C //vz/+pHML2NV/lZcc2dDh8xv+H3MR9LOo3FEu09+GO5wihzNHV87kvvD3279u4arWql6pSW MC45ZVjl+4W5+atVvYcnpCalV76R9E1OT9b5m4/m34o9avvJGLheTswp23JYujxV/Zr80qXH 829m4Tc/z/h8uDl4sCUwH793eqmIp78/vdq/tnLxcnvWtNnzHdL7gw20Gvx8j5ufL9JNpTWd PDuCmd4npfcI6b1yoPk8pdd06X1Ueq2W3ku3m/s1uek91EFuen+0LGf93mFnpel5LDXp+RqT MIzfkDLzMaQqPXujEtIzktJ+7VzMy2325tNIt4OkcvMxpGnLrTGJv3Ht4G+QiTMl468Esk9C pTn1kO6vyv82tFWw+qp+UV3CTOcusHTpDbPy8qS3dwN/azb0Mp1zjrlL4xK/CHerG91ySarO UV2kY0unKZebrpV0642yHFFuOgMtP0MD3mVX5Cx7i4y/+3bl78ZdK9+hO/FX1QT+XpjM39uG mY8mvZoprU7mYJ6+yq9PLdG09FHH6pYWrI7ra773pFbDfFg035PW5+lpNulBJi3J1GK/Ps0s TyBfq9NLSwzSq75KMC2NfM1/L2ampTGVsJhPSyOUHw6tnLaclnt2Y6vzsXR7qy5dV2kJJVUw Hb5jrPou8cWv90P9EH57JfNbbBT7r/6UxC5wuBireWdDny+ul9Bvqckvl8TGFx3qI81TTFkN luVqehQu6HCsT+VJtdc0dY4cMh/uo7X+LR1Xeoa9v/FQH+mwNAxDv+nzs8MNvsB1I3YG/21n fTX46UauN58XM2ikZZ0saZGUH/flql/PQ/WgBpNOKw0H80mzvCW5Edvb4ZM+I8/vMp9HfW30 hV19pONJt+H4z0zX+YdJF2Lv7NzQR/ot9cSxlbNU5XFiOcwfI9nSEpn146SG1fE8zIdrmYez +TjW52U5va15WroSs/kIFExLllsF0yuL6TH7IkQakklLitLjPhLuLcu7QDw/LD1rYviT1rQ8 NJr/N6Xy8VfNPKTLrG6+Li7m4WweOF/W82x5PlkeZq97Ponsrz+fZL/OQ5Xzkrr18+k9wfR8 OiNYnk9nhK8rx3uCqnKcEV73fJKx1z+frJ9n/6r71/LJ2nL/vskn1vOxmY/Phar3r2S7hT++ f8P4Z4N0/uiQ7t0k/jxX8c9NlvtT+nRnx369b51M81x5nzuxf9/711U03b97xF/vX1fxjLCn crwnuFaOf//7t6loun8/EH97/0r2X7t/e/yp+7c6+/e9f6VP+9L9W8R+vX+b80NFleM9oXnl +Pe/f6VvWKT791P22/tXsv/a/dviP/b5+0f3l9Rfd9nSdZO+WZG+KRpjXkYaY36NFysPL+bj PXo82FmdDz4G/lPnW/r2xlkw/bbM9xReprD/P+Y7UTT9lo6XKErz7fw/er4t85so/np/J/L3 NWne/8x8W/d/5meWP/oMYvOa15ZfP2oYX3ubS/Nd23y9Lgum69TaPH3ePG3xM+AnwL8HPwJ+ EPwr8H3gu8ELwLeCbwJfB74KfBn4QvAc8Fng08Ang48HTwdPAU8GTwSPA+8PHgseA94dvAt4 CHh78DbggeDNwRuDNwCvC+4J7gauAHcEtwFn4C9ZVX/Cqvp98DvgN8CvgF8APwt+Evw4+FHw Q+B68P3ge8B3gm8D3wy+Hnw1+HLwReDzwGeDTwefAj4BPANcBz4CPAk8HnwAeF/wnuCR4OHg oeAdwIPBg8D9wf3AfcC9wb3A3cGV4E7gtubp/8nvaaXwmiBN1wVvAN4YvDl4IHgb8PbgIeBd wLuDx4DHgvcHjwNPBE8GTwFPBx8PPhl8Gvgs8BzwheDLwFeBrwPfBL4VvAB8N/g+8ANW0zfN 05bjXwW/CH4O/BR4Efgx8MPgheAHwPeC7wLfDp4PvgF8DfgK8MXg88HngM8AzwKfCJ4Jngo+ EnwoeAL4QPB+4L3Ao8AjwMPAO4K3BW8JHgDeBNwXXAVeG9wD3AXcGdwOXAR/xar6M1bVH4Lf A78Ffu0vujRdCH4Y/Bh4Efgp8HPgF8Gvgt8Evwv+APwpeDm4tDqCtdsKVd0JXAnuDu4F7g3u A+4H7g8eBB4M3gE8FDwcPBK8J3hf8AHg8eBJ4CPAdeAZ4BPAp4BPB58NPg98Efhy8NXg68E3 g28D3wm+B3w/uB78EPhR8OPgJ8HPgl8AvwJ+A/wO+H3wJ+AvrVx6Lhqt/KJ5mt5fwU+BF4Ef Az8MXgh+AHwv+C7w7eD54BvA14CvAF8MPh98DvgM8CzwieCZ5unXrytg+qF1BWqY1hWg92I4 r5FwWUPBE8AHgvcD7wUeBR4BHgbeEbwteEvwAPAm4L7gKvDa4B7gLuDO4HbgNq+ZLrc6vjT9 FPwB+F3wm+BXwS+CnwM/BV4Efgz8MHgh+AHwveC7wLeD54NvAF8DvgJ8Mfh88DngM8CzwCeC Z4Kngo8EHwqeAD4QvB94L/Ao8AjwMPCO4G3BW4IHgDcB9wVXgdcG9wB3AXcGtwMXwaXlV2uX ll+t/SH4PfBb4NfAi8F/Bj8N/gP438G/Af8b+Bfgn4F/Av4x+EfgG8HXgq8EXwKeC/4++Ezw bPB3wceCjwEfBT4MfDD4IPC3wHuD9wDvCt4JXAP+JngrcDV4U/CG4PXApe+1/sr3b//o+zAj e/3f1QSr6yD9DUdah6O11XR1sao7gMvBrd/DpOkXQlV/DG4ALwUvAb8Mfh78DPgJ8O/Bj4Af BP8KfB/4bvAC8K3gm8DXga8CXwa+EDwHfBb4NPDJ4OPB08FTwJPBE8HjwPuDx4LHgHcH7wIe At4evA14IHhz8MbgDcDrgnuCu4ErwB3BbcAZ+EtW1Z/A8/M++B3wG+BXwC+AnwU/CX4c/Cj4 IXA9+H7wPeA7wbeBbwZfD74afDn4IvB54LPBp4NPAZ8AngGuAx8BngQeDz4AvC94T/BI8HDw UPAO4MHgQeD+Vi59V2D9947j5mmLHwU/BK4H3w++B3wn+DbwzeDrwVeDLwdfBD4PfDb4dPAp 4BPAM8B14CPAk8DjwQeA9wXvCR4JHg4eCt4BPBg8CNwf3A/cB9wb3AvcHVwJ7mx+PLa2mg4C DwbvAB4KHg4eCd4TvC/4APB48CTwEeA68AzwCeBTwKeDzwafB74IfDn4avD14JvBt4HvBN8D vh9cD34I/Cj4cfCT4GfBL4BfAb8Bfgf8PvgT8Jfg0vu5tUvv99buCK4AdwP3BK8L3gC8MXhz 8EDwNuDtwUPAu4B3B48BjwXvDx4HngieDJ4Cng4+Hnwy+DTwWeA54AvBl4GvAl8Hvgl8K3gB +G7wfeBfgR8EPwL+PfgJ8DPg58Evg5eAl4IbwB+DvwA3gsvFqu4gVvXq4K5/wV2Eqp9vPcBr g6vAfcGbgAeAtwRvC94RPAw8AjwKvBd4P/CB4AngQ8FHgqeCZ4JPBM8CnwE+B3w++GLwFeBr wDeA54NvB98Fvhf8AHgh+GHwY+BF4KfM0/+s73CY8Y/XaTIKVb+DkZ5P1s8xB7GqVwd3Ba8F /gZ4ffBG4M3AW4C3Bm8HrgXvDN4NPBq8D/jb4O+ADwEfDj4aPA18HPgk8Kng74HPBV8AvhT8 A/A88A/Bt4DvAP8U/HPwL8G/Bv8W/DvwH8F/Av8F/OJrpl9ZHV+afgb+EPwe+C3wa+DF4D+D nwb/Afzv4N+A/w38C/DPwD8B/xj8I/CN4GvBV4IvAc8Ffx98Jng2+LvgY8HHgI8CHwY+GHwQ +FvgvcF7gHcF7wSuAX8TvBW4GrwpeEPweuB1wGuC1wCvBm4PLgOvYFX9Oavqj8DLrHy+g2ld gRqur19XQFpPQPqR1hWQTnsbzus6XNYl8F/AfwL/Efw78G/Bvwb/Evxz8E/Bd4BvAf8QPA/8 A/Cl4AvA54K/Bz4VfBL4OPA08NHgw8GHgL8D/jZ4H/Bo8G7gncG14O3AW4O3AG8G3gi8Pvgb 4LXAXcGrgztY+QXR9Hc5i581T1v8JPhx8KPgh8D14PvB94DvBN8Gvhl8Pfhq8OXgi8Dngc8G nw4+BXwCeAa4DnwEeBJ4PPgA8L7gPcEjwcPBQ8E7gAeDB4H7g/uB+4B7g3uBu4MrwZ3AbcEF cGn9Imt/KlT1B+B3wW+CXwW/CH4O/BR4Efgx8MPgheAHwPeC7wLfDp4PvgF8DfgK8MXg88Hn gM8AzwKfCJ4Jngo+EnwoeAL4QPB+4L3Ao8AjwMPAO4K3BW8JHgDeBNwXXAVeG9wD3AXcGdwO XASX1i+y9mfsr7k07QiuAHcD9wSvC94AvDF4c/BA8Dbg7cFDwLuAdwePAY8F7w8eB54Ingye Ap4OPh58Mvg08FngOeALwZeBrwJfB77Jyl8y0zrCFpcWpPOt3Eao6o7gCnA3cE/wuuANwBuD NwcPBG8D3h48BLwLeHfwGPBY8P7gceCJ4MngKeDp4OPBJ4NPA58FngO+EHwZ+CrwdeCbwLeC F4DvBt8H/hX4QfAj4N+DnwA/A34e/DJ4CXgpuAH8MfgLcCO4NL0dfBf4XvAD4IXgh8GPgReB nwI/B34R/Cr4TfC74A/An4KXgwtCVbcVqroTuBLcHdwL3BvcB9wP3B88CDwYvAN4KHg4eCR4 T/C+4APA48GTwEeA68AzwCeATwGfDj4bfB74IvDl4KvB14NvBt8GvhN8D/h+cD34IfCj4MfB T4KfBb8AfgX8Bvgd8PvgT8Bfgkvjz/x9RvpewLKVYqX5cOXmLwX7ymU86bOXaWnPWfQSr4vS 9p5eiL9+VyYdV3p/lX6L/IOYdExBlP7Vu/QvQcpFZv4X8KbjCZWX5yOzee32Jk2nqHrOYuVv Az+l6ZJtKk06T8s5mtz0l6WX4h3zVidpe5P1Q9KSE0ax3/+xzIHp9EpmZ3V6QRTr956QnpE0 +o9OLzPfAqbr4y/UqrwlHETrS/DgvwMdU/nyh7S03LV3jCpMN3q0LsWGVeP/s+W3jTNz4f9z 5v+znOvrb2/5n7y9baxu799uj7DqLWwDt6i8yn37V+Zwt/Bm5RyGZaZn6EYnpakCpTlz4tdQ mj8nPk+2/L//7Dl83Rb5/nVz2FSsMoc9fjuH1f/pc/i6bdL96+YwnFWZwxb/yvvw9XMhwvmY XgN8ZSJtgc1yuVWfi7+9Ff57188Wrp/tH14/y5bS/l2uj2ULZv8+18e0ZbHfuz7W0398+XK4 /F+nLfNleogYf3N9pPN1Ez35Er50yJUfOi9Y2hlqJ6h9T+0ItYPUvqK2j9puagXUtlLbRG0d tVXUllFbSC2H2ixq06hNpjaeWjq1FGrJ1BKpxVHrTy2WWgy17tS6UAuh1p5aG2qB1JpTa0yt AbW61DypuVFTUHOkZkONUXvJLO0J3b/3qd2hdoPaFWoXqJ2ldpLacWpHqR2ipqe2n9oeajup baO2mdp6aqupLae2iNo8arOpTac2hdoEahnUdNRGUEuiFk9tALW+1HpSi6QWTi2UWgdqwdSC qPlT86PmQ82bmhc1d2pKak7ULK8z/+9fP0rNj8O65kNuYgNqjak1pxZIrQ219tRCqHWh1p1a DLVYav2pxVFLpJZMLYVaOrXx1CZTm0ZtFrUcagupLaO2ito6apuobaVWQG03tX3UDlgdumnW A+wqtYvUzlE7Ra2I2jFqh6kVUjtAbS+1XdS2U8untoHaGmorqC2mNp/aHGozqGVRm0gtk1oq tZHUhlJLoDaQWj9qvahFUYugFkatI7W21FpSC6DWhJovNRW12tQ8qLlQc6ZmR02k9opZ2jNm aQ+p3aN2i9q1f9AKzYdcxcPUjlEronaK2jlqF6ldpXaT2l1qD6g9pVZOTRAszVawNCdqSmru 1LyoeVPzoeZHzZ9aELVgah2ohVILpxZJrSe1vtQGUIunlkRtBDUdtQxqE6hNoTad2mxq86gt orac2mpq66ltpraN2k5qe6jtp6andojaUWrHqZ2kdpbaBWpXqN2gdofafWpPqL2kZhSumptR uEjtHLVT1IqoHaN2mFohtQPU9lLbRW07tXxqG6itobaC2mJq86nNoTaDWha1idQyqaVSG0lt KLUEagOp9aPWi1oUtQhqYdQ6UmtLrSW1AGpNqPlSU1GrTc2Dmgs1Z2p21GzMh8rNh9zEp9Qe ULtL7Sa1q9QuUjtH7RS1ImrHqB2mVkjtALW91HZR204tn9oGamuoraC2mNp8anOozaCWRW0i tUxqqdRGUhtKLYHaQGr9qPWiFkUtgloYtY7U2lJrSS2AWhNqvtRU1GpT86DmQs2Zmh01kZr0 vmRqz5ilPaR2j9otateoFVP7mdppaj9Q+zu1b6j9jdoX1D6j9gm1j6l9RG0jtbXUVlJbQi2X 2vvUZlLLpvYutbHUxlAbRW0YtcHUBlF7i1pvaj2odaXWiZqG2pvUWlFTU2tKrSG1etTqMJs/ +DxQdXkel/9/XZ6Xvjk0nWd18yE30YGanJpRsLQXgqU9pmagVkqthNplauepnaF2gtr31I5Q O0jtK2r7qO2mVkBtK7VN1NZRW0VtGbWF1HKozaI2jdpkauOppVNLoZZMLZFaHLX+1GKpxVDr Tq0LtRBq7am1oRZIrTm1xtQaUKtLzZOaGzUFNUdqNtQYtZf0XdETZmn3qd2hdoPaFWoXqJ2l dpLacWpHqR2ipqe2n9oeajupbaO2mdp6aqupLae2iNo8arOpTac2hdoEahnUdNRGUEuiFk9t ALW+1HpSi6QWTi2UWgdqwdSCqPlTa85OmltzdpzaUWqHqOmp7ae2h9pOatuobaa2ntpqasup LaI2j9psatOpTaE2gVoGNR21EdSSqMVTG0CtL7We1CKphVMLpdaBWjC1IGr+1Pyo+VDzpuZF zZ2a0tz8zZ8T+acb+sQYTK0DtVBq4dQiqfWk1pfaAGrx1JKojaCmo5ZBbQK1KdSmU5tNbR61 RdSWU1tNbT21zdS2UdtJbQ+1/dT01A5RO0rtOLWT1M5Su0DtCrUb1O5Qu0/tCbWX1JhgaTaC pTlSU1Bzo+ZJrS61BtQaU2tOLZBaG2rtqYVQ60KtO7UYarHU+lOLo5ZILZlaCrV0auOpTaY2 jdosajnUFlJbRm0VtXXUNlHbSq2A2m5q+6h9Re0gtSPUvqd2gtoZauepXaZWQq2UmoHaY2ov qBmpyUVLcxAtrTo113/YXEUXah7UalNTUfOl1oRaALWW1NpS60gtjFoEtShqvaj1ozaQWgK1 odRGUkullkltIrUsajOozaE2n9piaiuoraG2gVo+te3UdlHbS+0AtUJqh6kdo1ZE7dQf/K0N vus2/t533UbBSI8PuWhpDqKlVafmSq0WtTeo1afWiFozai2otabWjpqWWmdq3ahFU+tD7W1q 71AbQm04tdHU0qiNozaJ2lRq71GbS20BtaXUPqCWR+1Daluo7aD2KbXPqX1J7Wtq31L7jtqP 1H6i9gu1i+ZDr8yH3MRn1B5Su0ftFrVr1Iqp/UztNLUfqP2d2jfU/kbtC2qfUfuE2sfUPqK2 kdpaaiupLaGWS+19ajOpZVN7l9pYamOojaI2jNpgaoOovUWtN7Ue1LpS60RNQ+1Naq2oqak1 pdaQWj1qdajVpFaDWjVq9tRk1CqYpT1nlvaIWhm129SuU7tE7RdqP1H7kdp31L6l9jW1L6l9 Tu1TajuobaH2IbU8ah9QW0ptAbW51N6jNpXaJGrjqKVRG01tOLUh1N6h9ja1PtSiqXWj1pma llo7aq2ptaDWjFojavWpvUGtFjVXatWpOVCzYRfMzYadpXaS2nFqR6kdoqantp/aHmo7qW2j tpnaemqrqS2ntojaPGqzqU2nNoXaBGoZ1HTURlBLohZPbQC1vtR6UoukFk4tlFoHasHUgqj5 U/Oj5kPNm5oXNXdqSmpO1GypCdTKBUt7alk6Zw+o3aV2k9pVahepnaN2iloRtWPUDlMrpHaA 2l5qu6htp5ZPbQO1NdRWUFtMbT61OdRmUMuiNpFaJrVUaiOpDaWWQG0gtX7UelGLohZBLYxa R2ptqbWkFkCtCTVfaipqtal5UHOh5kzNjppIzfL3Uxv6++nrmqP5EP+URs2Nmie1utQaUGtM rTm1QGptqLWnFkKtC7Xu1GKoxVLrTy2OWiK1ZGop1NKpjac2mdo0arOo5VBbSG0ZtVXU1lHb RC2f1iLKpzWL8mlto3xaAymf1krKpzWV8mntpXxaoymf1nLKpzWf8mltqHxaQyqf1prKpzWp 8mntqnxa4yqf1sLKpzWz8mltrXxagyuf1urKpzW98mntr3xaIyyf1hLLpzXH8mltsnxawyyf 1jrLpzXR8mnttHxaYy2f1mLLpzXb8mltt3xaAy6f1orLpzXl8mntuXxaoy6f1rLLpzXv8mlt vHxaQy+fvvnLpzX58mntvnxWQq2UmoHaY2ovqFk+7Ww3H3ITd1HbS+0AtUJqh6kdo1ZE7RS1 c9QuUrtK7Sa1u9QeUHtKrZyaQJ/QbAVLc6KmpOZOzYuaNzUfan7U/KkFUQum1oFaKLVwapHU elLrS20AtXhqSdRGUNNRy6A2gdoUatOpzaY2j9oiasupraa2ntpmatuo7aS2h9p+anpqh6gd pXac2klqZ6ldoHaF2g1qd6jdp/aE2kurT+XG3/2kb9mHMP70COnR9Xfon/TTlyWzdD50rBMf Q1hm5d7FUyq3CvpnfuowsfLaS3tvNFp2qfgHP9KeVQx18fK78ksdyn+n8WuQwC9fail/eF71 +eUbrX7+zOXLmOnflEg/Nqx35TxLl5nGJvzla9HYvARQuXeVP3n50hZOVk+xXD7e7n/t+gT/ F+ZfetR9YF6hvG9yerJO1bhPlJ+qU1rCuOSUYdUcLdes8j6aITA31ost+bkk9uM3TP/iXvq5 O+r2fZnXrQf8Iqcz45MHxocvDXbCs/tsTvbt+x7ybA+mYp4s28gKCwtZSUmJkX3//ffs008/ LWMffPBBPZbNhhqHDmVRUVEsyBgUxLy8vFhZVlkZe/HihdXVNP021pK+9jrRmY1RnzfaKy6/ 6Mw8Sw3FQh/GHEsNnVgWU1X+WyI//kbRXKweJIq9+iW3SRmW2JM/tlr1KTVobj78QfPAKLf9 +fZ91c2Hb2u9bKV/vNyctVDwu82r8tw1bJ/beSM/LutWahAC+siZis9eHcdLL5/K2fBSA/8I yUojZDcfCt2kf6ylF6WtRFVEM+FBb7nYWyg1qN9122EMvzxxhoYJWq+Sx6JCYNVj2AjbvrKj bJDdDCbLtO0ryAfHirGizTK57TK53TJhXbZwQhbtuNw+msmWyeXy3vIDokZu5+x949EJYYbQ p47HekFo7SW29pK1rmn/otoLY7bAesiWy5baLZfFPOb/OaBYLrNfJndYJo91XCZ3WiZ3Xiav xieqL5MrlsmVy+Quy+SbaiyTu471nq+0i2EJ21hFmEoIbyCGN5BtDW8gD29gE97ANryBnSFc dcL7mmtW3YbslTFic4NptaOF+OVuhT5ioU8HWWG9juIr4/5Gk7wvvQyopvHWtNBcfqFksoJq QUw2lbXq20IwiovYh9LChlHcyN4RZ7Aoo/ghuyOsYy2Nwix2iL3H3tezmaweW9yGOUaz2rLk qXzJfXxoB10jpo7dGnhYM19ZOEPwkG2Xr/EuqDWD2dTbcPOhYYF4kJ+Z3ZbWFWVsGFvShgls tCsbEcNP+6HM/o3oG4/aqYO0oQ/16jZdGnp8pPYO9f7IRrGR1dN20ti4rhfkEV2uBH4QXsjv wjVLnUJXs5F91R2FOgN3Nv+OfwSf7RTqUo3VOMH6fNaqjo2srzpMfv3JTLGt7fneXSIV7yik jV5kOv+9VY7rT/Ljgc2jp8dl26QmRKdH9/feXXsWe2uyek2Xqa3l7IiLdkFQjLZ2tFKniW45 9IzsoMj2hy0Nr8ZEFybcj5a9I7C2tm8K9eNaxnWJeytuxKB7b8+UlcZ069siLkWjmZa8oDxX t17HnzaBdb6tNqZf6nZN36zhY/3dh4/tU9Br2kRx2kTZtHGzprcMF9mMasxZG5co2GXN8MzS sGYBWSFZpYb3Wgj3pquPMhtpX1D995ca+BNRzupvVDWQdn/rw1+sfLcxv42qJh2ym4ZkN9va Obt512z/qOyAx6nqrbHZLd7ODhyUzWeh5dak7FbJ2a1HZ7cZkx28dUJ225nZb1ZjDe92EVlR lkPc4uCKrI90KYrPfZaK8SNiT4cvsn8s3h45nM1vte5J5lrNzsBFNg6dGlTjF5qbuz7309zD uWdyb+W+nL9rofan6mX2zfI65sXkDc7rFpLNxufl5K3O25FXmHci71rekzyVfYFXQbOCjgXD V/nFFYwpWDe9YGlBfsG+gpfzq1/YUl11u6C8oLpepQ/Ud+uaHaFnA/Wj9FP0C/Qb9N8VXCw4 q1fe1pfrqxcNX9U0oCikqHcRSyoaVzSnaFXRx0X6oh+LrhbJHxcNW92sZrFfcbviqOK44mZj il/OVyiWnVWEXZtzVVVQ/Lfik8XXi3VLmhuLXcrWNShrVRZe9nbZy/k1lp6rodpQvLpsR1lh 2Ymybm9n3yzTlpc5G+sa1cZQ46h7NaaUaVMfZRkXGjca9xh1SwKKjOyy8aHRRlFT4af4VH9Y P86oHKOYrliqGLZa/ZniqOIXBburMCpcvNsplp6bc72r9wBv+9HeWd7JH7TI897lfdD7tLf9 De/n3r2N1YcatW5tAroG2A8IGB2Q5RM4K2BlwLaALwNYUcDlAKeAKEWcwk/TThOlqT9sdZBO M1Xj0n/Ges2nmgeH2ypOaOZfFVgt4bQw+YrLspB1NRcOvqxgE2domzadc6lV9u2Rc8bUjg7I VrSIzrk+ckVLbb/o5OjFmnnRedFHWwn7o9ni3otOTL4yJ+5pmHN0jTifOLF1XLfM7Mi4+LhJ 0dPilsTVP9ay+o44j6Dbas9jb8255HheK1zqVHqz87Nox7hmnV2qV9O5tRq5onWQrrNOF8eS de/qdkUf7PGT9u9xC69fj1OW6l7pFFljFrVplNU2q3sWG5SlyzqqeZm79Jzn0hYBf8+y941u E+07IliRWy83KLdzLuuXm5z7bu683LzcXbnG/peyPzqZq1ksm932abb85TT5ZmFZI/Zg4Tdz 5QOGfvHML69d3uQx0bVv7p769x4j38qrXndd8OaKwDZ1vh2TsG67Jr4gbfNHy37stT5tc0Wv dULOVnF/zlZZTv4sFrl8xfZFG5e1PJyb9uEXxVN7rbMLLt0cubD9p35sRN115T2TIv7+nsZL /91MdVDHT/L5a0+rvTtXLvUbrOnNRuYtKO/pdm77bL/Bexycst8szjP6Vdvpx57mORTULmhe oCnoWTCqILOAzSpYWbCt4MuCooLLBQ8LbPTamvojRe30Ufo4/Rh9lffsx81uPRDu3+/oeGaj MbVDfe0ktx3hZZcnemnvP2LM6SWr48Jq8UWBugKzGXX5he15Y3WFShGouP7EqGWhrNnt67He H/FllCbt+Wun9BcjzzrnjVef1XrtsculYz/jx7Zvz4xdpDfHn0Q2U8XfAssM5Q/PG5/dHz6F v0Xy98PvhJsPR4fcfGivbVKtUNPe5hd9V/5yrelhK2c97Z/cH6oYr2ANxOrPDU2a2FYsZMJS R7G97VrhlayzbYU9E20HH+Avm4LdYFYk2r872L5IdBisYmuFW/Ie/Fg2d+2YUtlCW/LY3tvL Qy5vIm9s+3kt7/fFo4wNVhaJwrq3XT4WtB77xWQvebKXzYLkmkcdj7OFzN7fY63gcHuXl2Oy l1NyTfYZKy5mi5j8uUEv3Eqay28ktxuPbFjExFsPppcqBebIMi/eeqB6aGDsB2mJht9AC2bn GsumPZs/zt5JGJdjnC2f9exZag6rW1eca7QxNFQEK7opLg1UpCiyFYsUq2U5TPZy3DOH6vNn C89y7YzCs1c9Sw29koZkJKQYh41K8meqccnGjOGqjKTxGSpjQkqiaoguJaXioSFZl6JK1SUb UzLS/VVh/NiqwUmq9Iy0JGPGkOFJiaoMXYUdm6BKTB6dlPJGuitL92ds9OCrz27qbz68pHn0 qEImv6Rv80OybI2u9U19sLt4SVNHNvKmxk126eUjVtjSqZrh5SOD3hhReS/K2On6pQZZqcFY 8aAty5ALV54Lzw0CG+4qxPWRtu5x8yG/M3s/0zRTtJIbWtrcbGnz9JKmp5Mjq87ErU3tKsYw IdNRzHSUVYTbVtRgojxTLI1X9bex+UiwyZQ9KnAYw2wHV9612+wGn5XZF8sdioXGZUwm2rgz QW6j4QtzdsyGX6bLUlHaymQNxpQPmczxqWjzShRkNZoonZRNlIUu/D81lb5yhe0vTMw2Rmor GF8keXXSWBGndHTi7xrxbY1hutQJacnDhhszVFtULdq2bWNUmRZmw4y6tFRdWkJGslGX4q9S hYwa9Uo1qUa6Ki0pPcmYNjYp0Z9V1KxIY/GK3sMTUpOM/sNHpdZr0Fb9VK1mbys3skCheAar Layq4J8Unm4QRj0TYvmC/qRQdxcXkS+EV5QpZwoPXcWHylbyJrZugvNbaexjVsxsKmqpBD3b 6l3f8bnBRlQ6tlHJ1E2UrVXT7KoFDBbqNeuoYH0DGteLrydvnu2n8lsRUEM22imNpQltVIUV 51V3hUv1hMK3lXPZpdsPVbsfqmY/VA1k7xfwzypzKphtiGqMPI2pBB9fp378Urew2vXsd9r7 +DVRXJrabAtrVG+nPaurya7XUvOFn1PjQRrv+hkaw3uaxBarNec1K9kJ1m8lW9tUO6KptnVT bTW5qHQWJq8oNfiy5kzkj/rHo/kbBX+U3OaPiccG4byRf6TjT/5v2MAr12PjVPaMlZQaGvgx Y8bT67G2DvwViT/EHf1YszvXYx/3C2MDwsVO7NGl/Ouxn4QxN6GpH9te8PB67KdhLKjUEPFV UzbqwfXYkjBWkz0xPD923nj5hfTE0xj5Z4svbl2PPVHGX2/4S8xR1knPnJfciH1Qm9m+4Av3 riyHvxyx+/Z1ZCGKSy/r8s9HxpzS67GvnBirNz6m8gl4+YXNOlvrV0uju/R4P1mN3e9UajAY yo3MoN/6VQ3B0UXbN7Y2e5zurq0wljyuxrqUGuIEaVGfPy3KDJMiZU0U0gcOvrivl5b3V4s3 H3Y1Si+60muusav0qstfdH/R8qdJoSbHRt/V0VGuWWsr9FV8rbjxaKfYjz9RJthVXGbCdNsT 9wQxx/aeIFvKnxF66dWOvwe72C0fLG0fWL6Wi8385jX5S1w92wjverbyavIc/pEnxaO/907m qazJX+O8awgrXV4J9WyXONbY4iXf4mWzpaZnDXmEt9sV5WVmn+JxT3C473XYcYuX05aaWd6+ vgZNp+DmzRvH/Oh0Wdjixf+f+pF7S9e97i2VjkyWLm1mWJDz51imuCW+i3Drgc2GerL8+jY9 PlbxZ++nfpeZ7cCGp1Qenkr7uz4Ovi5slZEVCJ+xIrboq2H8uTBXHMafjmV9XJnyQoUrO5oR LuikD0s1mN0v7PZSF4euzHGY9K8AC5gzs23H7C4x+21MEaZWhqtduqtrbI1Wu7ZjbpdY8AC1 exNPtccQdc226t2/sMAWftVKDbsblvdmu6/wqcm157UxaMqNwiXRli/07+7KpCUZpxZHW9av Jy882/pp64Nqm3saFi3s7qn2iG4c3U7dITo6eokyZrbmg8BO6qTuP2RE/fB1i482qjZFfxbt NCTqbEbU2Rpft3DmS+Fxu9uxudEfBHatrolbGaT4VnNOs9tTXSexS20hNvZ6RviG2IPqOS4r 4rbG7W6rfjuuN0vqc4WlCCtO20bceiBWG/zhRlW1wfJhzGOIbbXBNXyi1NUTvNrx/9Rfoqye 0LVJGD8YGM7/82Z39YPqCaHR/GA3Np1t6j8yvtfI+BEJoSPj39w6Mj5wZHyTkfH1R8Z78Yka I+MdR8bLo9WDHZurZaPFJkniFtX6BKfAH22GsS91Nx9GfFSvj21ESPwB1TnRJkrdQyH0VCcJ ybbljX3fldXQumVcddfWs/HN1ATw12s2KMBt7PgGdTM/9LorrmhcamindlmatlDDJjVKF+Jn 9l4ydsGYk/bLY2S22wZvOJ4m7LT5ebynstobLsyYzj5kx9gMlredf0ybKqjrJ1x/l41ybcFf AGefsrOx6xYg+Db0Hdsi92MxIGBg/9yfhbnsrenZnaZnD1JPz67D3m+nnjOMLbV1ym78qo9/ 8fiLr5511eTZRNoYZ/TaMMT16jOjZeMa0boUljyM37Dtf3BuoGzUM/50p+EN7NyW1XK5IN5P 82NLtg1uwRzGRKlThHUtAq4/WR5zMt3nZMbyGOH4hIh5lw5nB2R93jxgad6BxStZxqkF8VtP LYg8tSD41AJ5lHr2+9XixXMjxBu65zqnLG3Ws8YDc79+/KhrQ+bPp3plJWa22pSR9V7WiqzG W7O+yDqeJh5Pk/2cdWecMPVplkPuz2JqbpfccP2I3OyR+om5Oblr56bLpQ8xxufiudxSQ+WW F7wrN5/xLNcxr06e6L+MBed1y+MfG/OGFm1ZmJ207PaHmXx8nDe/6MdVzRxPLah1bYXs3IjP E4QC14LQ6hPrBhV0LuhXkFxQd1KBan7BuoJPCg4V/LTdftvg8hPsXJaod9M31M/Wd9PHlU3T s+lli/Qf6vPe/1p1vuysPlJ0kPGXp6M9FEX1ioKKOhexfkXJRe8WnS7K+6b8XObC8nPsUNEm 482iF0e3x/8y/MbCWsW1mhT7+USefKbpXpxv1BWzpMb9bZYUby7+vPhY8fniM9ts9ycIomsN Q4FnWdOyDmUsryyhbKz3yrIPvLeUHSjLez/iC92dsuMz5XZG8WiLhkYWbOxmHGhMMWYbFxnv GPO+yXb1zFzo6vmL8YsAo/HFURvxXLx4YfDBXexxRAuhdtmCZxG2X+95267y5XPjRLlvZjzb W+fm2kYxxlrNO/V5We+5/oWPa70D/GN2fKajMV5+bbDI7DLLqsVnOn3VUpbtUvGNI2MVHvw1 1O1wy30tsxNTXVzjv1DvU7vLClvYPm8hHFEfVss7ZZkWSeLn9hl3SWNTO4S/qtXvutl/gd3g y2r/BfadOjkoO4V4xddS7oiXe8XX4L98bVI7OHY7HW9b/olyrWJZZpeK2gdYqlbVLp5VfBIm sGwn7cSgGttDZZ9EHwr1+GzwjoSBoeKAMNtr2gFhd6Ouq3bEu/a+9DA8Kcyz/8vaijeYMKOI /SCsOazs6sJfL+8JPd2XqNzfyHaNTzggVGTFCAlsZk9R/n7MHm+hRXy5ul4XX7ZNduSX1tM0 mwcZmmr3D5jLYmPOKuucryHTKiM6CdltNF01A950iVdMGtslbrE9m1rzSNxmzeeaY/xNXXoF VNaI9oluHR0RLfuy8J3OrdNCbM4pShWvhKb5OSddx2bWCtw8P2SHlqVun3oiZGVaYGFXYUXW oc5i6g3lj6GsKK2we1HWJX4y2fRW6c9DmTxX2bN1WsB0xSxNeqv3n7/xY50rm1KWXN/SeEBM DbF4DWsszEzg75ayjuKouClxC+J+itsdV/iecsjwn+PuxFUMslPo6unebu9yqJFbN93XM2ol pgwZnp0oOHw9NUe3VrdT97XulK5El/1M55hVJ6tP5/YL4jolbrBhoWfGRk/ZtKBTzi+buuwX NzoIsg/Dr4Ukbji9ccjG56E/FRQqeyZuED69nD96o91+xqrHx4ps78i4bblf5srytJdzD/db uMI+zyuvYpB9hzwWnfe2psP5iZoczfjRjvX257Hv8i7mGfLEAreChgXBBd0KWJ/OP++M6ySe SP9odueMgkUZrJ7qx9AOJza/26H4cMh+Mecc+3a7eGLeSeHk89D5xcqe4gm27+TKM04n9T+3 jyt63j8uWM+66QfqN+iz9d/EdSvbqz+i/5vDL/q7eqN+n6vq6xd2/cdmejY6lF0zcXT200ts c17fouFFE4tyitYW7Sz6uqjwVFFJUa/w3ZfiOp1/YKM2fl53ZmnPz9dqTspr9pyUXr/mNw+E wd3l0oaz7jwZnfGlg6HJixveZfd3NDjtuXxrE8YfMS+u75MHy7+VDbK9FnL+AZsp++Xh89D3 FMqe5x/ski20s7/+8DPHJruC571XvUxVFliWPb6sb9nwW/bPs8sWlVUMcrTfU/Zt2bk7PmOW qg4OiZ+WV2fu6iFD7bUxEU2HynKWyGOfezWwZQ3dxWMeeZGrjYU7jIXGE0/nK+M6La1vs9Zw x/jWxNq2ttVm8mVeR/WntUptc8YsKVdU97paq1N/76T6wshGI1yWfKlsoGnSKjh2fOD18Da2 vTRjWwkXRmuyNP281mrUNd28G3pfuqgxaOpr3KJHuMyVviCcy8rZXHbodrI2J1nbJ8vDjo3K FSKYU673eu9zd4JVY/K+cx80pOE3C5c9Cj1c4S0qG8lrBzT3n5rZxa+TKjYge1jAhIATT2do 22bM7fVhY1H+xKhkYmYvB9HD6Ysxm0/62LMEw3s3VBd9ZXOz79gIb+3rVLbBqHKqYadp+I0Y vaClprXLQtV0rc085UKVwN4aHJN5LsJf14MvXozXRUavW61roivU+XRrMMLpTVXax8I8Javw SRUajxH6sQqWrFUmac8mazPXJWuHZ3nYsjenaqc6z4xeHr0l2uXowgWqg072c9ayx+WzHB5H uwR8mqGKky8d18XPqWvcgLjRcT88758aMb9PwrQPG9ttjjursnOrtsDW5lRcSZxB+OFVnEL6 88jPHsc0lzW6nonO5So2cIj/ojHuq/RTdbKsjyfG5F06pPtJ917eC93WPMZcnPV5L4cffDx7 /d7gnz2erEytnudWUCurSdZclp2kvR+RpO2Y9cMue7ZVMH2b/2r4rQc1pS8GOhrNi7qTskxL ulr+yUBg0saJbJjRjtkzB77QbnTiy3fV+GdCo4IpmQv/EJflytyYO/N4aBgUfPmFE4t5g0W+ wVpFvMEXePkC/qs60tK+9NWC8dDOklibWowJ8ecNlu8grLjOByWxkyS2P2941ePqM+lPZHxZ /iCLNNyI/cnZyJifk7SLNqOWyReWxBprPmXMVvrOvhcztlxSEpvET/ukJmOdvNmkRSWx1WY0 svwVgZ+RZ63zxhuP3FjxbnnlqQSmj0kYltS8heG+yD+HVH5cH/ZyVNJjQ7/hyRlJRtXQ5FGj +AknPTbIbf0DWdiEug5lQeztpLoOLVlUWQK/mOZsbHK6MWZUwpAk/gm9KKN3xgQnsY9Dp6Sn qRnDk2S9dJkZnyWnDIuXRep6iZHFySlJfXSLhbBRxqSEtISUIUlvNWLhafMV62Rvd2db7Wv2 0CWudujVgR1RfCWb1F7owzE5MXE6qzhoEzpKN2Rk7+RbEzex6rXfTpKFjE0al5KZVMuVtVH7 1yl7m7G2Ia5huhRjRppuVHpIeldjSmpmRjoLSv1moiwp3VOZJCsQumUaR6d2SRiSoUsb3EEZ cdhues2eyt7De8mNunHRKZ3SdKlbSw1Bnyvbfq6MiGK9i4czFpJ2rGaf5J9+chfYAGWKDdOl VTw2mD5oq6+qVbP4x0iDWwtVRBn/KD7KUZXB2MvLwj2PQBX/bK1P1I1jgnjPI8ioCk9LSMxM yDiZlPjI4NewxVPXQLaY1QtpZNc4sLeft2/gPhbSKKhxINP6NQxc+9Q1iLERKzkGndrGNSi7 UWBQ4yD2aqlfw1ZqVejIYU1TEp+57rjfqEW5j0Oj+vcbBZb71PN96BtU7tOq0Qu/hm1eqnRp iUlpT1lt2T33YLUq6rOEtJHJ6kDZZuWQLIGFJqQnDyk1ePbZYjfdhe0YrZ4dqPKtmKoOah7E 9LKgHXnqILZ2n3r1PvWirfvU8/epJ+5TD9unjry9Tx20T+2xT10hBm1jN66rT1xX77uu3rz1 ujr3unridXXCdXUUn2h9XV3vutr5urq8QAhi99y1t921JVvdtVfctRfdtT+7a3/iEyfctcfd tcfctUf4xB537Rp37Wx37UQ+keCujXLXtnfXNmvirvVy1zq6h7Db6tHa2L2jtR+M1s4erc3g E++M1vYfre02WvvmaO1pv9HaOqO11UZr5UzRjn0tM9rKWeUT12jD+IIT+2jSrAuxDmUGmcJd UfLYKBjrKsIUsYphigmKuYo1CqMjMz2rjfbMjn9Id2OvHJ4bmjF/FsCy1KwFC2RBzw2znJhr AJOWMAyCYzumOMjPuvlaRXH5epsC8YTQyvvSS9ke5nJP2m98jYeGVqx2GfNmqmRlA+Yj7Umq IWvEGl/5Ue5wRrHI+5W8NWu7jdXnT8T7j1zilK3asTajvfxYk6ne17yVL22N3i4Bt+8LHgFv BkQGZL8TcPX5iID5AesCPgm4+syOfRVwJeBRgK3m6rOBLo00bTVbb99XnmbVD9ZtmtS+2ZGT 3rM1C1o6Oyi/4U9Vu2Dm/tSwU7FAc0HzzJ3xFxTpx7nyZc/j9S97pQajyOozfrWZ0Xy1mZFf NdaUNWPG5pU3i5oZK28W1pKN43NSXO7EenRmjyM7sy6dWS1+y8v6vPbrVfmnJbHe5XUYGyJt +tru3TH/8MtYt5/5sWe+Ufll7IHdwqWX/OXY+MDhKhtWft9ZUVfBWGOj7+mfWxW8eUWb1zjH q6J1sNiy+rUbX5bElt0vexaxvORV7M2HrvyO6sXiErNLYoNLDYNKDXE1+Qtup3fZ0lLDafvp 8j7vsjW58los6wSTXyqJ3VRqeNWh1NCQX/6kGf1KYq+UGuqVGrzyWXGf90tiZWWGlbZG6d/p xrNDs8pH2ewUYtij3JLYuNV2/HYtNbwxjuXllFyPzXzARgs+HW+wJdNKYo89YA+EV43GsfYr S2JX1eIv3F31opbtnp1fEsvv70WC32fsw7L5JbF3AtwCWRc9Gzi8JPaRt/J6mcjYsXBls5fX 9bHnajPmWWZob2SdmM/UktgHBXUq/wasGcdWG5fxa8BvKNUL/hFtmDLyh5LYrGdZypNsmLIX O3WqRBY7L8uN/e9PlZ+pzLSFcmmvrjP4mMlMe4SRtlIu7dl1Dh/vM9NeY6QtlUt7d53PRy4z 7VlG2lq5tIfXxXwsYaa9z0hbLJf28rqCjwqj0Vhh/N+ff9efCqO0ZGS1oUbzj7RgeGlm3oPn 0cOV2xbas6aNPj2n5m3UlMot1Va6tB6PtHgVw0zr/wxkpu3RSnv8kdaxkdYhktaLyWamf7sk PX5czI8Lafqa3LR3Acu2Df87h6W9Kn832bQOjnTZ9mxS/x0hkjvwK3Oxo3TNPCo3gS/9V9q/ VH2V9f6l1kkzZ1oPS8XnqDkfUaZzzzF3aVwSTftEsfxM6s+YdCmqzlFdpGNLpymSm44r7WeB tm4rN52Blp+hAW/qK3KWvUXG+vJF/N58SPs36sTSWAIbx5JZChtmPpq0Wo7S6mQO5umrommf iZZ9OFpuEcHquL7s1/02WvbhKM1GNThPT7PxG7FyP0e12K/7gjSaVy7ytTp9Xz6kG07aL0Yo //21YHolsKlsv92OsOW03F+7L0rrbSBL1/X/9Ty9J5jmSdoOvWmefrut3v+keZL2tSnNk7Rf J8s8vW7rvP9J8yTtb0SaJ2k7+ZZ5et32eP8T5umPrqPUX3fZ0uF+fPgw074OF5t/S7eLWHnY tFVey2l/b7vj/8nzLa1QadlfvWW+LVv7/f9hvhNF02/p9JatCv9Pnm/L/CaKv97flq0X/5n5 tu5/dd4stxHOm/X52vzO5Ukdb/NfFymMr73NpcPW+zyRrpP1PlGs99l0BvwE+PfgR8APgn8F vg98N3gB+FbwTeDrwFeBLwNfCJ4DPgt8Gvhk8PHg6eAp4MngieBx4P3BY8FjwLuDdwEPAW8P 3gY8ELw5eGPwBuB1wT3B3cAV4I7gNuAMXNpnlbU/YVX9Pvgd8BvgV8AvgJ8FPwl+HPwo+CFw Pfh+8D3gO8G3gW8GXw++Gnw5+CLweeCzwaeDTwGfAJ4BrgMfAZ4EHg8+ALwveE/wSPBw8FDw DuDB4EHg/uB+4D7g3uBe4O7gSnAncFvz9P/k97RSeE2QpuuCNwBvDN4cPBC8DXh78BDwLuDd wWPAY8H7g8eBJ4Ing6eAp4OPB58MPg18FngO+ELwZeCrwNeBbwLfCl4Avht8H7j1ftNumqct x78KfhH8HPgp8CLwY+CHwQvBD4DvBd8Fvh08H3wD+BrwFeCLweeDzwGfAZ4FPhE8EzwVfCT4 UPAE8IHg/cB7gUeBR4CHgXcEbwveEjwAvAm4L7gKvDa4B7gLuDO4HbgILu3X1dqfsar+EPwe +C3wa3/RpelC8MPgx8CLwE+BnwO/CH4V/Cb4XfAH4E/By8GldR2sXdpPobU7gSvB3cG9wL3B fcD9wP3Bg8CDwTuAh4KHg0eC9wTvCz4APB48CXwEuA48A3wC+BTw6eCzweeBLwJfDr4afD34 ZvBt4DvB94DvB9eDHwI/Cn4c/CT4WfAL4FfAb4DfAb8P/gT8pZVLz0WjlV80T9P7K/gp8CLw Y+CHwQvBD4DvBd8Fvh08H3wD+BrwFeCLweeDzwGfAZ4FPhE8EzwVfCT4UPAE8IHg/cB7gUeB R4CHgXcEbwveEjwAvAm4L7gKvDa4B7gLuDO4HbjNa6bLrY4vTT8FfwB+F/wm+FXwi+DnwE+B F4EfAz8MXgh+AHwv+C7w7eD54BvA14CvAF8MPh98DvgM8CzwieCZ4KngI8GHgieADwTvB94L PAo8AjwMvCN4W/CW4AHgTcB9wVXgtcE9wF3AncHtwEVwaZnU2qVlUmt/CH4P/Bb4NfBi8J/B T4P/AP538G/A/wb+Bfhn4J+w31tXwPRD6wpUM60rYH1eH8N5fQSXtRF8LfhK8CXgueDvg88E zwZ/F3ws+BjwUeDDwAeDDwJ/C7w3eA/wruCdwDXgb4K3AleDNwVvCF4PXPpe6698//aPvg8z stf/XU2wug7S33Ckv9W3tpquLlZ1B3A5uPX7nTT9Qqjqj8EN4KXgJeCXwc+DnwE/Af49+BHw g+Bfge8D3w1eAL4VfBP4OvBV4MvAF4LngM8CnwY+GXw8eDp4CngyeCJ4HHh/8FjwGPDu4F3A Q8Dbg7cBDwRvDt4YvAF4XXBPcDdwBbgjuA04A3/JqvoTeH7eB78DfgP8CvgF8LPgJ8GPgx8F PwSuB98Pvgd8J/g28M3g68FXgy8HXwQ+D3w2+HTwKeATwDPAdeAjwJPA48EHgPcF7wkeCR4O HgreATwYPAjc38ql7wqs/95x3Dxt8aPgh8D14PvB94DvBN8Gvhl8Pfhq8OXgi8Dngc8Gnw4+ BXwCeAa4DnwEeBJ4PPgA8L7gPcEjwcPBQ8E7gAeDB4H7g/uB+4B7g3uBu4MrwZ3Nj8fWVtNB 4MHgHcBDwcPBI8F7gvcFHwAeD54EPgJcB54BPgF8Cvh08Nng88AXgS8HXw2+Hnwz+DbwneB7 wPeD68EPgR8FPw5+Evws+AXwK+A3wO+A3wd/Av4SXHo/t3bp/d7aHcEV4G7gnuB1wRuANwZv Dh4I3ga8PXgIeBfw7uAx4LHg/cHjwBPBk8FTwNPBx4NPBp8GPgs8B3wh+DLwVeDrwDeBbwUv AN8Nvg/8K/CD4EfAvwc/AX4G/Dz4ZfAS8FJwA/hj8BfgRnC5WNUdxKpeHdz1L7iLUPXzrQd4 bXAVuC94E/AA8JbgbcE7goeBR4BHgfcC7wc+EDwBfCj4SPBU8EzwieBZ4DPA54DPB18MvgJ8 DfgG8Hzw7eC7wPeCHwAvBD8Mfgy8CPyUefqf9R2OtHWpP/oOxyhU/Q5Gej5ZP8ccxKpeHdwV vBb4G+D1wRuBNwNvAd4avB24FrwzeDfwaPA+4G+DvwM+BHw4+GjwNPBx4JPAp4K/Bz4XfAH4 UvAPwPPAPwTfAr4D/FPwz8G/BP8a/Fvw78B/BP8J/Bfwi6+ZfmV1fGn6GfhD8Hvgt8CvgReD /wx+GvwH8L+DfwP+N/AvwD8D/wT8Y/CPwDeCrwVfCb4EPBf8ffCZ4Nng74KPBR8DPgp8GPhg 8EHgb4H3Bu8B3hW8E7gG/E3wVuBq8KbgDcHrgdcBrwleA7wauD24DLyCVfXnrKo/Ai8Dvw1+ HfwS+C/gP4H/CP4d+LfgX4N/Cf45+KfgO8C3gH8Ingf+AfhS8AXgc8HfA58KPgl8HHga+Gjw 4eBDwN8Bfxu8D3g0eDfwzuBa8HbgrcFbgDcDbwReH/wN8FrgruDVwR2s/IJo+lubxc+apy1+ Evw4+FHwQ+B68P3ge8B3gm8D3wy+Hnw1+HLwReDzwGeDTwefAj4BPANcBz4CPAk8HnwAeF/w nuCR4OHgoeAdwIPBg8D9wf3AfcC9wb3A3cGV4E7gtuBf2ZrWFUir9vp1BaT1BKSfyu0KwHlJ 6yJZn9dToao/AL8LfhP8KvhF8HPgp8CLwI+BHwYvBD8Avhd8F/h28HzwDeBrwFeALwafDz4H fAZ4FvhE8EzwVPCR4EPBE8AHgvcD7wUeBR4BHgbeEbwteEvwAPAm4L7gKvDa4B7gLuDO4Hbg Iri0LpK1P2N/zaVpR3AFuBu4J3hd8AbgjcGbgweCtwFvDx4C3gW8O3gMeCx4f/A48ETwZPAU 8HTw8eCTwaeBzwLPAV8Ivgx8Ffg68E1W/pKZ1hG2uPRCnW/lNkJVdwRXgLuBe4LXBW8A3hi8 OXggeBvw9uAh4F3Au4PHgMeC9wePA08ETwZPAU8HHw8+GXwa+CzwHPCF4MvAV4GvA98EvhW8 AHw3+D7wr8APgh8B/x78BPgZ8PPgl8FLwEvBDeCPwV+AG8Gl6e3gu8D3gh8ALwQ/DH4MvAj8 FPg58IvgV8Fvgt8FfwD+FLwcXBCquq1Q1Z3AleDu4F7g3uA+4H7g/uBB4MHgHcBDwcPBI8F7 gvcFHwAeD54EPgJcB54BPgF8Cvh08Nng88AXgS8HXw2+Hnwz+DbwneB7wPeD68EPgR8FPw5+ Evws+AXwK+A3wO+A3wd/Av4SXBp/5u8z0ncIls04Ks2HKzevJthXLuNJn9NMS3vOopd4XZS2 VvdC/PWzmGnfm6bfIv8gJh1TEKV/9S79q5FykZn/BbxlH53S5fnIbF67PTPTKaqes2jeq6fA TJdsU2nSeVbd6ydj/71rJrO6Zr/dKlnV6yL7l13267Ye9n/rsl+3la9/9WW//vxFOB/Tfe8r E2nLW5bLZVUu9599/eRw/eR/eP0sW8j6d7k+li1X/ftcH9MWpX7v+lhP//Hl42vEr9OW+TI9 RIy/uT7S+bqJnrTHbE/ai7Yn7Vnbk/a27Ul74PakvXJ70p66PWnv3Z60R29P2su3J+3525P2 Bu5Jewj3pL2Ge9KexD1p7+KetMdxT9oLuSftmdyT9lbuSXsw96S9mnvSns49ae/nnrRHdE/a S7on7Tndk/am7kl7WPekva570p7YPWnv7J60x3ZP2ou7J+3Z3ZP29u5Je4D3pL3Ce9Ke4j1p 7/GetEd5T9rLvCfted6T9kbvSXuo96S91nvSnuw92RO6f+9Tu0PtBrUr1C5QO0vtJLXj1I5S O0RNT20/tT3UdlLbRm0ztfXUVlNbTm0RtXnUZlObTm0KtQnUMqjpqI2glkQtntoAan2p9aQW SS2cWii1DtSCqQVR86fmR82Hmjc1L2ru1JTUnKjZ/u7r/f/t149S8+OwrvmQm9iAWmNqzakF UmtDrT21EGpdqHWnFkMtllp/anHUEqklU0uhlk5tPLXJ1KZRm0Uth9pCasuoraK2jtomalup FVDbTW0ftQNWh26a9QC7Su0itXPUTlEronaM2mFqhdQOUNtLbRe17dTyqW2gtobaCmqLqc2n NofaDGpZ1CZSy6SWSm0ktaHUEqgNpNaPWi9qUdQiqIVR60itLbWW1AKoNaHmS01FrTY1D2ou 1Jyp2VETqb1ilvaMWdpDaveo3aJ27R+0QvMhV/EwtWPUiqidonaO2kVqV6ndpHaX2gNqT6mV UxMES7MVLM2JmpKaOzUvat7UfKj5UfOnFkQtmFoHaqHUwqlFUutJrS+1AdTiqSVRG0FNRy2D 2gRqU6hNpzab2jxqi6gtp7aa2npqm6lto7aT2h5q+6npqR2idpTacWonqZ2ldoHaFWo3qN2h dp/aE2ovqRmFq+ZmFC5SO0ftFLUiaseoHaZWSO0Atb3UdlHbTi2f2gZqa6itoLaY2nxqc6jN oJZFbSK1TGqp1EZSG0otgdpAav2o9aIWRS2CWhi1jtTaUmtJLYBaE2q+1FTUalPzoOZCzZma HTUb86Fy8yE38Sm1B9TuUrtJ7Sq1i9TOUTtFrYjaMWqHqRVSO0BtL7Vd1LZTy6e2gdoaaiuo LaY2n9ocajOoZVGbSC2TWiq1kdSGUkugNpBaP2q9qEVRi6AWRq0jtbbUWlILoNaEmi81FbXa 1DyouVBzpmZHTaQmvS+Z2jNmaQ+p3aN2i9o1asXUfqZ2mtoP1P5O7Rtqf6P2BbXPqH1C7WNq H1HbSG0ttZXUllDLpfY+tZnUsqm9S20stTHURlEbRm0wtUHU3qLWm1oPal2pdaKmofYmtVbU 1NSaUmtIrR61Ovz3P/48UHV5Hpf/f12el75tM51ndfMhN9GBmpyaUbC0F4KlPaZmoFZKrYTa ZWrnqZ2hdoLa99SOUDtI7Stq+6jtplZAbSu1Tf+nnbsNq7I8ADh+YNKmNbOJTW1pqS2toHwp qaSSQjKpQBNLWuKUUiyppJJKMqmkEpe0pCUtacW9hhVWuIYrrLDCHK4wsxet7MVe7MVe7MU2 Ejnnd+3atdan7VPPp/v8nutc5zrXcz6c+37+z82WsiVsMVvEFrD5bB6bw2azWWwmm86mskls IhvPstgYNoqNZCPYcDaEJbGBrD/rw3qxRLY368ISWITttFa0IxKz7Wwb28q2sE1sI2tlLayZ NbFG1sDqWR2rZTWsmlWxSlbBylkZK2UlrJgVsUJWwPJZHstlOSybZbIMlsZSWQobypJZUqQ1 akmRFtbMmlgja2D1rI7VshpWzapYJatg5ayMlbISVsyKWCErYPksj+WyHJbNMlkGS2OpLIUN ZclsEBvA+rLerAfrFrXk6Dxx1+zGjDGFpbI0lsEyWTbLYbksj+WzAlbIilgxK2GlrIyVswpW yapYNathtayO1bMG1siaWDNrYa1sI9vEtrCtbBvbznawnSwSF7OEuJh1YXuzRNaL9WH92UCW xIaw4WwEG8lGsTEsi41nE9kkNpVNZzPZLDabzWHz2Hy2gC1ii9kStpTdzf7E7mcPsb+wR9kT 7Gn2N/Yce4G9wl5nb7P32cfsc/Y1a2Od4mPWOT5mXVn3/2rd4/dh+7L92AHsIHYIO5wNY0ez 49iJ7GR2KhvLJrCz2WR2LpvBLmSXsMvZVewadj1byG5mt7Lb2Z0ssGVsOVvBVrJVbDVbw9ax 9d9zr+3f1rrbvmutuy2uze+jU3zMOsfHrCvrznqy/Vk/djA7jA1mR7Fj2QksnZ3CTmdnsLPY OWwKm8YuYBezy9iV7Gp2HbuR3cRuYbexO9hd7B52H3uQPcweYY+zp9ha9izbwF5mm6Ojf0RH ifFfsk/Zh+xd9iZ7lb3Enmd/Z8+wJ9lj7K/sz+wBdi/7I/sD+z37Hfst+w27gV3L5rIr2KXs InY+O4/9mv2KncnGsdPYaHYSO54dw45kR7BD2S/ZgewX7OfsZ+yn7CfsR+yfkZh9FYnZZ+wj 9h57i73GXmYb2LNsLXuKPc4eYQ+zB9l97B52F7uD3cZuYTexG9l17Gp2JbuMXcwuYNPYFHYO O4udwU5np7B0dgI7lh3FBrPD2MGsH9uf9WTdWVfWmSVENkUtIbKRtbIW1syaWCNrYPWsjtWy GlbNqlglq2DlrIyVshJWzIpYIStg+SyP5bIcls0yWQZLY6kshQ1lyWwQG8D6st6sB+vG9mR7 sDj2TVzMvoj9O498wj5g77A32Gb2IlvP1rE1bDVbxVayFWw5W8YCu5Pdzm5lN7OF7Hp2DbuK Xc4uYReyGexcNpmdzSawsexUdjI7kR3HjmbD2OHsEHYQO4Dtx/Zl+7C92I9ZPIvdP01w//Q/ WZfoaNcsjSWyXqwP688GsiQ2hA1nI9hINoqNYVlsPJvIJrGpbDqbyWax2WwOm8fmswVsEVvM lrCl7G4WVERBWRTURkGBFFRJQakU1EtB0RRUTkH5FNRQQSEVVFNBSRXUVUFxFVRYQZkV1FpB wRVUXUHpFdRfQREWVGJBORbUZEFhFlRnQYkW1GlBsRZUbEHZFtRuQQEXVHFBKRfUc0FRF1R2 QXkX1HhBoRes/AUlX1D3hcjb7H32Mfucfc1is51l0VFi/HK2gq1kq9hqtoatY+vZi2wze4O9 wz5gn7Av2Dcszgxtj7iY7cm6sR6sN+vLBrBBLJkNZSkslaWxDJbJslkOy2V5LJ8VsEJWxIpZ CStlZaycVbBKVsWqWQ2rZXWsnjWwRtbEmlkLa2Ub2Sa2hW1l29h2toPt/JdZedt3zvR3763+ w/F/OJIGdzwJOzZ/StHkmeedn79738qE6NkjIh2l9dSOl3Pb94FvX3Vp3xuz/RrNjb5uH+9+ LjAna/RJk7LGpueMTp8wruPcbm/nzNGnjUkbOS49+p43d13s9v0hOnfqeLa1U/Qz9+r2P//S PxyObwG4dY1XEAAREKFMAAAAGgEAeJzs3QlAVOXC//HnzMKqDiAu4MK4rwiCay4zrrghiCBp JKCCIgrI4oLaoOJCGqi4kEsoaqRRSKmV0w2uaVftJl2zW95ballqUYG7uTD/c2DmF/yye+t9 e9//ve/7cu+Tc76fWZk5zzmDeObDctdLu0s8vxD0NVioRbXFUdjVaSp5SLYFl5+Wqy0Wiy1P kIfl/77+bb4eycNofQ7Xyn9q5aE85/bycJCHozyc5OEsjwbyaCiPRvLQ1b4EhKs83OTRWB7u 8mgij6byaCaP5vLwkIenPFrIo6U8WsmjtTy85KGXRxt5tJVHO3m0l0cHeXSURyd5dJZHF3l0 lUc3eXSXh7c8esjDRx6+8ugpDz95+Mujlzx6y6OPPPrKo588+svjCXkMkMdAeQyqeW0LYbA+ ZmUMlU8Pk8dweYyQx0h5BMhjlDxGy2OMPMbKY5w8AuUxXh5B8gi2XofyPZwonw6VR5g8Jskj XB5PymOyPKbI4yl5RMjjaXlMlUekPKLkES2PafKYLo8Z8oiRR6w8Zspjljzi5DFbHvHymCOP ufJIkEeiPJLkMU8eyfJIkUeqPNLkMV8eC+SxUB6L5JEuj8XyWCKPpfJ4Rh4meWTII0S+pkT5 knr5kSfIfybXXOLXfzWVXzG215IyH7h5qmp6WS2PrHveDxss/XzbmT9KasVrzybPH0Hy44r5 TbdZ98tJqKS6r+dfezl3Ybv9YfLjnyt/L4Pk52H2b759N/n2lTlQI2rnvV9zGeX8cdbTKuvj D5a/8zHys+hb879f/9X8P/D4lfsasaD2dLX1ebOtC7+0/lf/l85C//f1/+tLqt2M1/vK+6oJ Tp+0bvBDredSLmOzGQ5N5ddytUXtVNt53Ve2D5NGTxwdpO+tH54cvSAuYWbN9sLaevjqJ86K TopJqdmQTIpLiUvsYT1bj97iVv/X5tH9chbOGbbTyu3p2zaTb115Pf/sIfzs6578ONwdm4pN 9Dh+6fJKUX38wcc7erRwyd3qILp1//FVZfugpeYmX+8Z6/qifKuMtRfPULYdynZS2UYo28oI 63Uqc7qyHVXmamVbWmTtX2lqt6GOmtrto20/65dON3CpXY+VpqyvwdEz5W+k2noOpSprb2B0 SmpM8k9dFut+m4P1Msr3QVGN9RzKsu27sUremL0pbzQ9FygmzwTq5wYoj7Sp8nzV/LejnU60 1YcHjhxWe+2SOHlJ+VO5RmXzfk3efF8bXXvN66xdGW/IN/E9diV/uiX9iMCRyrmVy8zV1N4r 5bs3x3ZGTe0VGOXLVvFT9qVGZOxXy1vf0WKiPJQt9HB5Vo2Wt4Vx8rZtpvVsymzmUudijtbl o/J9qpJq9z5a1vlO17mbNXsnDazNzXpa+W41pOv0sJryIlP2ZJqLn1Yz2wrUoc7llT0GZdZv IF+xsjfyqvxnrqjdG2sg5crLyhgqnx5as2y7rOwZnetcj6071OnKfQ2RR5JUe/o7S/2txNs/ vfjbDpG/X3Hyd2yO+I9+XQ1784XPwwxTC0KXSFfxp9I+U18Niyo/Hqo8puBKN2FqXPsqXD/o dGjNRY1fGVqePG49HWqs+6dyXmUNe3bP8VDltDKqYt8LPfr3K/Ir50rYDPlP+7p3Q75c/G7r dYkqg7KvY1J2SeXzPtj+03Xob7gJ5bLKcLRe1OSlyJWwiY6vhcZ/VmK9jrbGoM9LQpXzKd/D hW/U3uc1DhfCvjtYEKr8qfQZ82seUr3Xie20/BrJUPbI6r5O3Oqcr6n1dHPraGA9T93rUm50 kzxaSrV7ktul2pmk9jV6f4gyFEuyXmYcPTu2WV/Z0xwl729Ey/uc8+R9xmj5eU+Vl5PlPRBl 1nIWP+3x24ayrDw4+zqnnenx2dYd20vqceuOSvz2dUf90/2vd11Kr7vurJJq151PJNu684n0 as1YJTWoGZ9Ij1t31OLx607ddeq/4rmMkkeAvLBbql0/35TqP5eKHZJq798vPZfK9YTIs5ay dWpUZ/yrPC8W6/OyW/XT82KRn4fdKmWskiySMv61npc1iqtqn5flqp8/L4opz4vTP3heouTT Q+T3ddPl9xdpNe+tardCyvf1ceuXvbC+Zq3jX+X5Uy6nPH9m8dPz5yGfMteMVZJHzfjXev4y Re27fuX52yp+/vwppjx/jv/k+QusmRnj5ZkxFfsQrqL+/Of8L/jc/bPnQumPu23lvik/uVB+ EvO0dR/kaev6q6o5nSuPVXiu7etcDz+//66PW/kZgLItUf60Pe7Zcpkt/nc87mBV7Z/K+YJV yuNu8D/6cdser/LnKjzuVZLy2H/N4657W/w9wK61fN9/6X60sH4PKqTa0ce6XGVdtvlt8vvk FnKNqr47qup7I/LG5M3JW5G3Je9E3p28J3kf8gHkRvIR5GPIg8hDySeTTyWfTj6LfC55MvkC 8iXky8hXka8lX0++mXwbeT75XvL95K+Sv05++DHL1+qcX1m+TH6B/Dz5OfJy8tPkJ8jLyM3k R8hLyIvIC8kLyHeS55HnkmeTZ5FnkpvI08nTyJPI48ljyaPJI8jDyUPIA8lH11k+ZF22nb+Y /AD5PvJd5NvJt5BvIF9Hvpp8OflS8oXkKeQJ5HHkM8gjyaeQh5EHk48lH0k+hHwgeV9yP3Jv 8s7k7chbk3uQu5PryJ3IteSC/IFU3+9I9f06+XfkylxV9/WqLIeQh5NHkEeTx5LHkyeRp5Gn k5vIM8mzyLPJc8nzyHeSF5AXkheRl5AfITeTl5GfID9NXk5+jvw8+QXyy+TK9uj32keziMfv p8o3gftwT9TfJj4S9behKqm+20v1vQG5K3lT8hbkevIO5F3Jfch7kfcnH0w+jHwUeSB5CHk4 eQR5NHkseTx5EnkaeTq5iTyTPIs8mzyXPI98J3kBeSF5EXkJ+RFyM3kZ+bHHLNfdRztG68wx WqeO0Tp3jNbJY7TOHqN1+hit88doTjhGc8YxmlOU5RLyIvJC8gLyneR55Lnk2eRZ5JnkJvJ0 8jTyJPJ48ljyaPII8nDyEPJA8rrbyD9K9beRb5O/Qf4a+SvkL5HvIX+B/HnyTeQ55M+SryTP IF9MPp98Hvkc8pnk08ifJn+SfCL5ePLR5MPJDeRPkPcm9yXvRt6RvA15S/Jm5G7kDckdyNXk 1aK+/yjqu7L9rPt6VZZDyMPJI8ijyWPJ48mTyNPI08lN5JnkWeTZ5Lnk+8gLfoOMPQYZuw4ydvp2kLHZIKP9IONdSb6Nq0uNf11qPLnU ePjAUuPOpcY1S43pS43R8kLgUuPApcbuS+XbWGp0Wmr8QfiLswcOG48cNm47bFxz2JgqL0w9 bJxy2DjmsPEJeaHLYWPLw8aGh40aLzFAOGksdhpRs25btKKV/G55/ferPw9zrKxS65rorty2 SJbWumG6MN1M3SLdWt1OncVJ1K74FuVIUM3kNd7iKFSiu+ghLD7CV/QUfqKV/x/lMzX+seq8 rkL3Q5XkJJq/K08L3pkv6C4+1Barzkq9vS49UB89LFzfkNdCt5tVvUtFC+El9HEu7Syivegg OopOa0Xnv2gcP9Ft9Hqk6VMp+ou2yurpYRaed6vkeeX6Le0T012ap7l1EV2XeX3l1fY794bD vVx8vrkhNfV5wkeM85nqc/nH2T7ZPrt8XvORpw37d3y+9LnlY2e4fC/CtZMhtb/h2+uukS7y 7PWx6NJorueHrt3i+3T/yGuN4cb6XjpHl/fkNbqfkJrYuxzUrTd8bniorT0akXJcskezvrnR 9PFzZUWVRSXainbyw7DUPA7RWVjk+yi6yd8ki7f8fVK+TRbl++QveokFfUT/iw+dxfgR4va4 EWLkCHkm1Ah16GN/HBv6zpUwr+6thJiuHCJvpeeCf/jD21SXq2Feh1vV/PDWfEi69ECewy03 HC+LmQ+vN9C11gnR2bKuQ+mTxU98aczv/OpA/eR+ql6NIq4+vBJWeb3yXsbrVx6FXbvZWH7m QkTkcHnq7FdR9bT88JrJ8/Kc3VfCwjZXVDms0OxYK3bmaCzNxVnxmepq2O19FVWDKqo6yncg 8taLV8K+rKhqU1G11LNQaC5dCVNXVlmet1N+gT9K/Fi0Vly5PUgEizmWQ1fCdtgL0eB+RVWr BWLv0SthKaE3xFyp/VVxa604eUPcvyF1WiBSi66E7a2UJ/TRpSqj6B7SwuV7L5eNUpc3hCZe PLrt4+4nRgpN8N0rYY+8XJRfvXx0OsDl3MyrYXdbyFuFbpVVA8VwsXSJWch728pfGC81LBCZ 5ithOYkut/UVVcNmuoy7fSXsenGiy0dipkuI0LjYXw37g8ld/C/4WiZqj0yoHE03Ux4rRe2n 8yhHJ1SOuKscJf1ZeVRbLJZqy/99/U/7qrYoO0Sqn70ulL3DSyvzb/wYNMvl5Q0Oolun18/7 yu1cUs0RG2tc+UQAZa9KOfKm8gNY5Qj/yu/CKJ8epfyOjfI7RMrvxWSI2t+GVo5wqfzNdJ51 +StN7VFFbcf8+s+cVo6m3Cup9ndwlNt2EKvC3hyouKN8Z1z7KfdM+RTyX/os8j3K4Tp/+izy 9vIYXnvt66xdGW/Id/t7200qa0qYEMqt6EcEjlTOrVxmlKb2vMrxVXGUR03tFRjly1bxt/pL jcjYrxaTxGgxUR7KZ3kNF8kiWiyQd7MSxEzr2ZRfy3GpczFH6/JRVe3RJm2fBWC7e3Xuprxp /en4/7bPAlCegYZ0nR5Wk7+J8iZMKPvnP30OlvWXizrUubxyzGvlVdHAevzqV6Xaz03Q1rSf H0/TdlnZH/uZBnWPBarc1//fj2mVVPuYPpFsj+nnR6v8d3pMFutj2q366TE97piV/06PSbmc 8pjM4qfH9LijVP47PKZ/dh+V/rjbVk4rn7ciT1s1n9+Ya/1T+b6oak7XHq3SdtlfOv7uv/Pj Vo7fr6yzyp+2x207Cub/hscdrKr9U7m87Wib/5Mft+3xKn+uwuOuParnr3ncdW+LvweP+xwd vh91PwtBGbZjXVdZl21+m/w+uYVco6rvjqr63oi8MXlz8lbkbck7kXcn70neh3wAuZF8BPkY 8iDyUPLJ5FPJp5PPIp9Lnky+gHwJ+TLyVeRrydeTbybfRp5Pvpd8P/mr5K+TH37M8rU651eW L5NfID9Pfo68nPw0+QnyMnIz+RHyEvIi8kLyAvKd5HnkueTZ5FnkmeQm8nTyNPIk8njyWPJo 8gjycPIQ8kDy0XWWD1mXbecvJj9Avo98F/l28i3kG8jXka8mX06+lHwheQp5Ankc+QzySPIp 5GHkweRjyUeSDyEfSN6X3I/cm7wzeTvy1uQe5O7kOnInci25IH8g1fc7Un2/Tv4duTJX1X29 Kssh5OHkEeTR5LHk8eRJ5Gnk6eQm8kzyLPJs8lzyPPKd5AXkheRF5CXkR8jN5GXkJ8hPk5eT nyM/T36B/DK5sj36vfbR6n4+t2KP20e7J+pvEx+J+ttQ5SM+6rq9VN8bkLuSNyVvQa4n70De ldyHvBd5f/LB5MPIR5EHkoeQh5NHkEeTx5LHkyeRp5Gnk5vIM8mzyLPJc8nzyHeSF5AXkheR l5AfITeTl5Efe8xy3X20Y7TOHKN16hitc8donTxG6+wxWqeP0Tp/jOaEYzRnHKM5RVkuIS8i LyQvIN9JnkeeS55NnkWeSW4iTydPI08ijyePJY8mjyAPJw8hDySvu438o1R/G/k2+Rvkr5G/ Qv4S+R7yF8ifJ99EnkP+LPlK8gzyxeTzyeeRzyGfST6N/GnyJ8knko8nH00+nNxA/gR5b3Jf 8m7kHcnbkLckb0buRt6Q3IFcTV4t6vuPor4r28+6r1dlOYQ8nDyCPJo8ljyePIk8jTyd3ESe SZ5Fnk2eS55HvpO8gLyQvIi8hPwIuZm8jPwE+WnycvJz5OfJL5BfJv8999GUvbR/to+m/Ny+ 7jbRSdTfhurI3ck9yFuTtyPvTO5N7kfel3wg+RDykeRjyYPJw8inkEeSzyCPI08gTyFfSL6U fDn5avJ15BvIt5BvJ99Fvo/8AHkx+SHyt8jfIX+X/CT5B+Tlj1muu4+mLF8mv0B+nvwceTn5 afIT5GXkZvIj5CXkReSF5AXkO8nzyHPJs8mzyDPJTeTp5GnkSeTx5LHk0eQR5OHkIeSP/12B 2i/8roCm9ncFAum66m5Pz4j629NT5MfJS8mPkh8mP0j+MvmL5LvJd5BvJd9I/hz5GvIV5M+Q LyJPJU8kn00eQx5F/hT5JPIJ5OPIA8iHkg8i70fuT96DvAt5e3Ivck/yJuQu5M7kduTKtrbu 61VZDiEPJ48gjyaPJY8nTyJPI08nN5FnkmeRZ5PnkueR7yQvIC8kLyIvIT9CbiYvIz9Bfpq8 nPwc+XnyC+SXyf+79+dq9onFT/fhkXXZ5srP3Oq6vVTfG5C7kjclb0GuJ+9A3pXch7wXeX/y weTDyEeRB5KHkIeTR5BHk8eSx5MnkaeRp5ObyDPJs8izyXPJ88h3kheQF5IXkZeQHyE3k5eR H3vM8t4651eW88m3kW8mX0++lnwV+TLyJeQLyJPJ55LPIp9OPpV8MnkoeRD5GPIR5EbyAeR9 yHuS1/2M+D9al23nf5v8DfLXyF8hf4l8D/kL5M+TbyLPIX+WfCV5Bvli8vnk88jnkM8kn0b+ NPmT5BPJx5OPJh9ObiB/grw3uS95N/KO5G3IW5I3I3cjb0juQK4mV37mVdd/FPVd2X7Vfb3e E/Vfz8ryAHIj+QjyMeRB5KHkk8mnkk8nn0U+lzyZfAH5EvJl5KvI15KvJ99Mvo08n1yZj/87 /17wK1H7e6O2+/CNddnmP5DfJL9H/ohc2cep6/ZSfW9A7krelLwFuZ68A3lXch/yXuT9yQeT DyMfRR5IHkIeTh5BHk0eSx5PnkSeRp5ObiLPJM8izybPJc8j30leQF5IXkReQn6E3ExeRn6C /DR5Ofk58k8es/xWnfMry4fIi8kPkO8j30W+nXwL+QbydeSryZeTLyVfSJ5CnkAeRz6DPJJ8 CnkYeTD5WPKR5EPIB5L3Jfcj9ybvTN6OvDW5x2/ws9Zlm39AfpL8XfJ3yN8iP0ReTH6AfB/5 LvLt5FvIN5CvI19Nvpx8KflC8hTyBPI48hnkkeRTyMPIg8nHko8kH0I+kLwvuR+5N3ln8nbk rck9yN3JdeRO5FpyQf5A1Pc7or5fJ/+O/Cr5V9bTfeos68k7kHcl9yHvRd6ffDD5MPJR5IHk IeTh5BHk0eSx5PHkSeRp5OnkJvJM8izybPJc8jzyneQF5IXkReQl5EfE7/hztV/x7w3KrcN2 H85Zl21+nvwC+WXya+Tfk98gv0v+kFyS6rudVN+dyV3Im5B7knuRtyfvQt6D3J+8H/kg8qHk AeTjyCeQTyJ/ijyKPIZ8NnkieSr5IvJnyFeQryF/jnwj+VbyHeS7yV8kf5n8IPlh8qPkpeTH yU+RnyH/iPxT8s/JvyS/Sl7xmOUzdc6vLJ8iP05eSn6U/DD5QfKXyV8k302+g3wr+Uby58jX kK8gf4Z8EXkqeSL5bPIY8ijyp8gnkU8gH0ceQD6UfBB5P3J/8h7kXcjbk3uRe5I3IXchdya3 E/Vfr1pR//WsFfVf73X9U/KPyM+QnyI/Tl5KfpT8MPlB8pfJXyTfTb6DfCv5RvLnyNeQryB/ hnyRdflZVe3vCjhpH/+7AtesB6BSfleg7txd97oS6bZmk8eQR5E/RT6JfAL5OPIA8qHkg8j7 kfuT9yDvQt6e3Ivck7wJuQu5M7kduUSu7LvU9buivt8g/578Gvll8gvk58nPkZeTK8tO5Dpy d3IP8tbk7cg7k3uT+5H3JR9IPoR8JPlY8mDyMPIp5JHkM8jjyBPIU8gXki8lX06+mnwd+Qby LeTbyXeR7yM/QF5Mfoj8LfJ3yN8lP0n+Abkyfs37m0ai9rUorJdVTtcc9kRyqHlNO9e8yVFO NVBdl/6gsn1Opm2OrP10LWH9nExVzTkllfKvx5VjyDxU2f4lue1TuJTba6/WPvY4I7WXqH/N KuvndknWT+jU1pgFn9Bp+1wvIf5z90xd5579/Ggh9e+L+r/sth93VI//rtt+3NE3/qtv+/HX r6LrqX3uO6hVOCKG7XZFvdv9ve+fhu6f5p/eP9uRK/5V7o/tiBL/Oven9kgPv3R/bJd//Kfx /nR9yv1yV1VIts/wrJCqJFu7jXYfzYKmUdmao8rWGqE1RmuO1gqtLVontO5oPdH6oA1AM6KN QBuDFoQWijYZbSradLRZaHPRktEWoC1BW4a2Cm0t2nq0zWjb0PLR9qLtR3sV7XW0w9ZT16yn 3FWX0S6gnUc7h1aOdhrtBFoZmhntCFoJWhFaIVoB2k60PLRctGy0LLRMNBNaOloaWhJaPFos WjRaBFo4WghaINroOqcOWXW0VIx2AG0f2i607Whb0DagrUNbjbYcbSnaQrQUtAS0OLQZaJFo U9DC0ILRxqKNRBuCNhCtL5ofmjdaZ7R2aK3RPNDc0XRoTmhaNIH2QLK1O5KtXUf7TrI9W7Z5 KESyfZZwOFoEWjRaLFo8WhJaGlo6mgktEy0LLRstFy0PbSdaAVohWhFaCdoRNDNaGdoJtNNo 5Wjn0M6jXUC7jHZNPvVbtgM/bXd+vh24J2zzziM0FeZ8e2wHGqC5ojVFa4GmR+uA1hXNB60X Wn+0wWjD0EahBaKFoIWjRaBFo8WixaMloaWhpaOZ0DLRstCy0XLR8tB2ohWgFaIVoZWgHUEz o5WhHcOzfQyvAFu7gHYe7RxaOdpptBNoZWhmtCNoJWhFaIVoBWg70fLQctGy0bLQMtFMaOlo aWhJaPFosWjRaBFo4WghaIFoo+uc+iPmorfR3kB7De0VtJfQ9qC9gPY82ia0HLRn0VaiZaAt RpuPNg9tDtpMtGloT6M9iTYRbTzaaLThaAa0J9B6o/midUPriNYGrSVaMzQ3tIZoDmhqtGph az8K27Nlm4dCrKeUZ9XWItCi0WLR4tGS0NLQ0tFMaJloWWjZaLloeWg70QrQCtGK0ErQjqCZ 0crQTqCdRitHO4d2Hu0C2mW0a/Kp3/R+QPzy+wEttgNOaDo0dzQPtNZo7dA6o3mj+aH1RRuI NgRtJNpYtGC0MLQpaJFoM9Di0BLQUtAWoi1FW462Gm0d2ga0LWjb0Xah7UM7gFaMdgjtLbR3 0N5FO4n2AZrtk9mvSbZPa7+MdgHtPNo5tHK002gn0MrQzGhH0ErQitAK0QrQdqLloeWiZaNl oWWimdDS0dLQktDi0WLRotEi0MLRQtAC0UbXOXVG2OaiU2jH0UrRjqIdRjuI9jLai2i70Xag bUXbiPYc2hq0FWjPoC1CS0VLRJuNFoMWhfYU2iS0CWjj0ALQhqINQuuH5o/WA60LWns0LzRP tCZoLmjOaHZ4tmzzUIj1lPKs2loEWjRaLFo8WhJaGlo6mgktEy0LLRstFy0PbSdaAVohWhFa CdoRNDNaGdoJtNNo5Wjn0M6jXUC7jHZNPvX7bAcKhW3bUigeodneDxQK2/uBQtEAzRWtKVoL ND1aB7SuaD5ovdD6ow1GG4Y2Ci0QLQQtHC0CLRotFi0eLQktDS0dzYSWiZaFlo2Wi5aHthOt AK0QrQitBO0ImhmtDM22F7tX2PZx89G2oW1GW4+2Fm0V2jK0JWgL0JLR5qLNQpuONhVtMloo WhDaGLQRaEa0AWh90Hqiedc5Zdt/9xZvo72B9hraK2gvoe1BewHtebRNaDloz6KtRMtAW4w2 H20e2hy0mWjT0J5GexJtItp4tNFow9EMaE+g9UbzReuG1hGtDVpLtGZobmgN0RzQ1Gi2/Xdv Ydt/74l5o4+w7acOQDOijUAbgxaEFoo2GW0q2nS0WWhz0ZLRFqAtQVuGtgptLdp6tM1o29Dy 0faK37a//cs/dzGLr6zXaRbfoP2AdhPtHtojNNt8bMZ8bMZ8bMZ8bMZ8bMZ8bMZ8bMZ8bMZ8 bMZ8bMZ8bMZ8bMZ8bMZ8bMZ8bMZ8bMZ8bMZ8bMZ8bMZ8bMZ8bMZ8bMZ8bMZ8bMZ8bMZ8bMZ8 bMZ8bMZ8bMZ8bMZ8bMZ8bMZ8bMZ8bMZ8bMZ8bMZ8bMZ8bMZ8bBYn0E6jlaOdQ/vEeuot6yl3 1SG0YrQDaPvQdqFtR9uCtgFtHdpqtOVoS9EWoqWgJaDFoc1Ai0SbghaGFow2Fm0k2hC0gWh9 0fzQvNE6o7VDa43m8Q+bhziL9gHaSbR30d5BewvtEFox2gG0fWi70LajbUHbgLYObTXacrSl aAvRUtAS0OLQZqBFok1BC0MLRhuLNhJtCNpAtL5ofmjeaJ3R2qG1RvNAc0fToTmhadEE2gNh a3eErV1H+w7tqrW1wIypt55yV3VA64rmg9YLrT/aYLRhaKPQAtFC0MLRItCi0WLR4tGS0NLQ 0tFMaJloWWjZaLloeWg70QrQCtGK0ErQjsinfp+/MS4XtnfP5eIc2nm0C2iX0a6hfY92A+0u 2kM0SbI1O8nWnNFc0JqgeaJ5obVH64LWA80frR/aILShaAFo49AmoE1CewotCi0GbTZaIloq 2iK0Z9BWoK1Bew5tI9pWtB1ou9FeRHsZ7SDaYbSjaKVox9FOoZ1B+wjtU7TP0b5Eu4pm+3ur M8L2d1mn0I6jlaIdRTuM9v/au1/fJsIwDuAn+C7hR7ImAwECBIghuvBDgBiiC2Vp1pCOhpKA KGITEAJiEyBGGhAgQIAYYhNMDLEJEJgZDAZD+A/4W8b1yoeZSRScae9zqvc+z/dNmvfu/cS2 2Qe2wdbZO/aWvWYv2XP2lD1hy+wRu88W2V12h/XYPGuzWTbDrrDL7CKbYmfZGXaKnWDHWI0d ZmMsRitGMEY1RjpGPyoiqiQqJ6opKiyqLioxqjMqNqo4KjuqPToguiI6JbonOiq6LDovujE6 NLo2Ojm6Ozo+UiCSIdIiEiRSJZIm0icSKVIqkivSLBIuUi+SMNIxEjNSNJI10jYSOFI5kjrS OxI9Uj6SP2aDQ8Xvf1rH2VF2nJ1kp9kkq7ML7BKbZg12jc2xDrvJbrM+W2D32EO2xB6zFfaM vWCv2Bu2ytbYe7bJtthH9pntsC/sK/vGvu+ZnX/sO+MP3+BX/Nyz+u/fO+rnqxXmo02vHywO n+3J6Oq5olrRt1CdDsr9DMvbVT6/U969wei8/F6u+e33Oq2r/c6NZq/VvNWtrg295Hbr+txM o9ss/uz+OPHr8+CBas346PGI4kjtr//o/4djF2VpWKsAAHIXTAAAAAEAcAAAAAAAtCIAAGUr AABRLQAAPS8AACkxAADrOAAACQBQANc6AACvPgAAwzwAAJtAAADpkAAAEABAACXhAAAVMwAA BzUAAPk2AAAAAPUPHAAAAAABAACPFQADAAAAAM4tAQABAAAAEwAAAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA /v8AAAUAAgAAAAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQq5EIACsns9kwAAAAbAoAAAsA AAABAAAAYAAAAAIAAABoAAAABAAAAJAAAAAIAAAAqAAAAAkAAADAAAAAEgAAAMwAAAAKAAAA 7AAAAAwAAAD4AAAADQAAAAQBAAAPAAAAEAEAABEAAAAYAQAAAgAAAOQEAAAeAAAAHgAAAE1h bmRhdG9yeSBSZXBsaWNhIE1hbmFnZW1lbnQgAHQAHgAAAA4AAABSaWNoYXJkIEh1YmVyAGlj HgAAAA4AAABSaWNoYXJkIEh1YmVyAGljHgAAAAIAAAA1AGNoHgAAABUAAABNaWNyb3NvZnQg UG93ZXJQb2ludABhZ2VAAAAAQK7Ong0AAABAAAAA0Cnsu/3JwQFAAAAAACOEl8nPwQEDAAAA yQEAAEcAAABKCQAA/////wMAAAAIAIkQZwwAAAEACQAAA50EAAAGACIAAAAAABEAAAAmBg8A GAD/////AAAQAAAAAAAAAAAAwAMAANACAAAJAAAAJgYPAAgA/////wIAAAAXAAAAJgYPACMA /////wQAGwBUTlBQFACgAM0AMgAAAP//TwAUAAAATQBpAAAACgAAACYGDwAKAFROUFAAAAIA 9AMJAAAAJgYPAAgA/////wMAAAAPAAAAJgYPABQAVE5QUAQADAABAAAAAQAAAAAAAAAFAAAA CwIAAAAABQAAAAwC0ALAAwUAAAAEAQ0AAAAHAAAA/AIAAP///wAAAAQAAAAtAQAACAAAAPoC BQABAAAAAAAAAAQAAAAtAQEABAAAAC0BAAAJAAAAHQYhAPAA0ALAAwAAAAAEAAAALQEAAAcA AAD8AgAA////AAAABAAAAC0BAgAEAAAA8AEAAAgAAAD6AgAAAAAAAAAAAAAEAAAALQEAABAA AAAmBg8AFgD/////AABHAAAAjwIAABEBAADBAgAACAAAACYGDwAGAP////8BABwAAAD7AgAA AAAAAAAAAAAAAAAAAAAAAADyEgCUn/R3QAAAAPoGCtoHhvV3EIb1dwEAAAAAADAABAAAAC0B AwAFAAAACQIAAAACBQAAABQCAAAAAAUAAAACAQIAAAAQAAAAJgYPABYA/////wAARwEAAI8C AAB5AgAAwQIAAAgAAAAmBg8ABgD/////AQAFAAAACQIAAAACBQAAABQCAAAAABwAAAD7Au3/ AAAAAAAAkAEAAAAAAEAAIkFyaWFsAPR3QAAAAFUHCpEHhvV3EIb1dwEAAAAAADAABAAAAC0B BAAEAAAA8AEDAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAATAAAA MgqnAoUBCAAAAElFVEYgNTMgBgAMAAsADAAFAAoACwAFAAUAAAAuAQEAAAAFAAAAAgECAAAA BQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAAAkAAAAyCqcCzQEBAAAA LQAGAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAA BQAAAAIBAQAAABgAAAAyCqcC2AELAAAATWlubmVhcG9saXMADwAEAAoACgALAAoACwALAAQA BAAKAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAIBAgAAAAcAAAD8AgEAAAAAAAAABAAAAC0B AwAEAAAALQEBAAcAAAAbBGkBeQPwAEgABAAAAC0BAgAEAAAALQEAAAUAAAAJAgAAAAIFAAAA FAIAAAAAHAAAAPsCxf8AAAAAAACQAQAAAAAAQAAiQXJpYWwgQmxhY2sA+gYK3weG9XcQhvV3 AQAAAAAAMAAEAAAALQEFAAQAAADwAQQABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAA BQAAAAIBAQAAACIAAAAyChwBtAASAAAATWFuZGF0b3J5IFJlcGxpY2EgOAAnACcAJwAnABoA JwAaACQAFAAuACcAJwATABQAJwAnABMABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQIAAAAC BQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAAGAAAADIKYgERAQsAAABNYW5hZ2VtZW50 IAA4ACcAJwAnACcAJwA7ACcAJwAaABQABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAAAgECAAAA BAAAAC0BAwAEAAAALQEBAAcAAAAbBFECMQOYAZAABAAAAC0BAgAEAAAALQEAAAUAAAAJAgAA AAIFAAAAFAIAAAAAHAAAAPsC4P8AAAAAAAC8AgAAAAAAQAAxQ291cmllciBOZXcAVQcKnweG 9XcQhvV3AQAAAAAAMAAEAAAALQEEAAQAAADwAQUABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAA LgEYAAAABQAAAAIBAQAAAA8AAAAyCsYB6AAFAAAAZHJhZnQAEwATABMAEwATAAUAAAAuAQEA AAAFAAAAAgECAAAABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAAAkA AAAyCsYBRwEBAAAALQATAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAkCAAAAAgUAAAAUAgAA AAAFAAAALgEYAAAABQAAAAIBAQAAAA0AAAAyCsYBWgEEAAAAaWV0ZhMAEwAUABMABQAAAC4B AQAAAAUAAAACAQIAAAAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAA CQAAADIKxgGnAQEAAAAtABMABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQIAAAACBQAAABQC AAAAAAUAAAAuARgAAAAFAAAAAgEBAAAADQAAADIKxgG6AQQAAABsZHVwEwATABMAFAAFAAAA LgEBAAAABQAAAAIBAgAAAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEA AAAJAAAAMgrGAQcCAQAAAC0AEwAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAgAAAAIFAAAA FAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAMAAAAMgrGARoCAwAAAG1ybXATABMAEwAFAAAA LgEBAAAABQAAAAIBAgAAAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEA AAAJAAAAMgrGAVMCAQAAAC0AEwAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAgAAAAIFAAAA FAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAQAAAAMgrGAWYCBgAAADAxLnR4dBQAEwATABMA EwATAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAIBAgAAAAQAAAAtAQEABAAAAC0BAwAcAAAA +wIQAAcAAAAAALwCAAAAAAECAiJTeXN0ZW0AAAAACgAAAAQAAAAAAAUAAAABAAAAAAAwAAQA AAAtAQUABAAAAPABBAAPAAAAJgYPABQAVE5QUAQADAAAAAAAAAAAAAAAAAAJAAAAJgYPAAgA /////wEAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAAIA AAAAAAAAAAAAAAAAAAAAAAEAAAAC1c3VnC4bEJOXCAArLPmuMAAAAGADAAAQAAAAAQAAAIgA AAADAAAAkAAAAA8AAACoAAAABAAAALgAAAAGAAAAwAAAAAcAAADIAAAACAAAANAAAAAJAAAA 2AAAAAoAAADgAAAAFwAAAOgAAAALAAAA8AAAABAAAAD4AAAAEwAAAAABAAAWAAAACAEAAA0A AAAQAQAADAAAANoCAAACAAAA5AQAAB4AAAAPAAAAT24tc2NyZWVuIFNob3cAAB4AAAAFAAAA QVQmVAByZWUDAAAA7XUBAAMAAAA4AAAAAwAAAAsAAAADAAAAAAAAAAMAAAAAAAAAAwAAAAAA AAADAAAAMhEJAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAABEAAAAQAAAA VGltZXMgTmV3IFJvbWFuAAwAAABBcmlhbCBCbGFjawAGAAAAQXJpYWwADAAAAENvdXJpZXIg TmV3AA8AAABEZWZhdWx0IERlc2lnbgAQAAAAVklTSU8gNSBEcmF3aW5nAB4AAABNYW5kYXRv cnkgUmVwbGljYSBNYW5hZ2VtZW50IAATAAAAU3RydWN0dXJlIG9mIERyYWZ0AAcAAABJc3N1 ZXMAIQAAAE92ZXJsYXBwaW5nIEFyZWFzIG9mIFJlcGxpY2F0aW9uACEAAABPdmVybGFwcGlu ZyBBcmVhcyBvZiBSZXBsaWNhdGlvbgAQAAAAV2l0aG91dCBPdmVybGFwACEAAABPdmVybGFw cGluZyBBcmVhcyBvZiBSZXBsaWNhdGlvbgAoAAAAcmVwbGljYU9ubGluZSCWIERTQS1TcGVj aWZpYyBBdHRyaWJ1dGU/ACgAAABSZXBsaWNhdGlvbiBhZ3JlZW1lbnQgd2l0aG91dCByZXBs aWNhRE4AGgAAAFVwZGF0ZSBvZiBGYWlsb3ZlciBTZXJ2ZXIAHAAAAFdoZXJlIENhbiBTY2hl ZHVsZXMgUmVzaWRlPwAMEAAACAAAAB4AAAALAAAARm9udHMgVXNlZAADAAAABAAAAB4AAAAQ AAAARGVzaWduIFRlbXBsYXRlAAMAAAABAAAAHgAAABUAAABFbWJlZGRlZCBPTEUgU2VydmVy cwADAAAAAQAAAB4AAAANAAAAU2xpZGUgVGl0bGVzAAMAAAALAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPYPJQAAABQAAABfwJHj Ii4BAA0A9AMDAM0AUmljaGFyZCBIdWJlcggAAABSAGkAYwBoAGEAcgBkACAASAB1AGIAZQBy AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAA BwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQA AAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAA IgAAACMAAAD+////JQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwAAAAtAAAALgAAAC8A AAAwAAAAMQAAADIAAAAzAAAANAAAADUAAAA2AAAANwAAADgAAAA5AAAAOgAAADsAAAA8AAAA PQAAAD4AAAA/AAAAQAAAAEEAAABCAAAAQwAAAEQAAABFAAAARgAAAEcAAABIAAAASQAAAEoA AABLAAAATAAAAE0AAABOAAAATwAAAFAAAABRAAAAUgAAAFMAAABUAAAAVQAAAFYAAABXAAAA WAAAAFkAAABaAAAAWwAAAFwAAABdAAAAXgAAAF8AAABgAAAAYQAAAGIAAABjAAAAZAAAAGUA AABmAAAAZwAAAGgAAABpAAAAagAAAGsAAABsAAAAbQAAAG4AAABvAAAAcAAAAHEAAAByAAAA cwAAAHQAAAB1AAAAdgAAAHcAAAB4AAAAeQAAAHoAAAB7AAAAfAAAAH0AAAB+AAAAfwAAAIAA AACBAAAAggAAAIMAAACEAAAAhQAAAIYAAACHAAAAiAAAAIkAAACKAAAAiwAAAIwAAACNAAAA jgAAAI8AAACQAAAAkQAAAJIAAACTAAAAlAAAAJUAAACWAAAAlwAAAJgAAACZAAAAmgAAAJsA AACcAAAAnQAAAJ4AAACfAAAAoAAAAKEAAACiAAAAowAAAKQAAAClAAAApgAAAKcAAACoAAAA qQAAAKoAAACrAAAArAAAAK0AAACuAAAArwAAALAAAACxAAAAsgAAALMAAAC0AAAAtQAAALYA AAC3AAAAuAAAALkAAAC6AAAAuwAAAP7///+9AAAAvgAAAL8AAADAAAAAwQAAAMIAAADDAAAA /v///8UAAADGAAAAxwAAAMgAAADJAAAAygAAAMsAAAD+////zQAAAM4AAADPAAAA0AAAANEA AADSAAAA0wAAAP7////9/////f///9cAAAD+//////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAA EI2BZJtPzxGG6gCqALkp6AAAAAAAAAAAAAAAAAAAAAAAAAAA/v///wAAAAAAAAAAUABpAGMA dAB1AHIAZQBzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAABIAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAp0cAAAAAAABDAHUAcgByAGUAbgB0ACAAVQBzAGUAcgAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQEAAAD//////////wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAMwAAAAAEAAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4A ZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBAgAAAAUA AAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAvAAAAAAQAAAAAAAA UABvAHcAZQByAFAAbwBpAG4AdAAgAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAACgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAkAAAARi4BAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkA bgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAQQAAAD//////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMQAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= --------------057AA0EB879AC32FF5E25B18-- From owner-ietf-ldup@mail.imc.org Wed Mar 20 14:05:42 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10244 for ; Wed, 20 Mar 2002 14:05:42 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2KItIP04975 for ietf-ldup-bks; Wed, 20 Mar 2002 10:55:18 -0800 (PST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2KItG404971 for ; Wed, 20 Mar 2002 10:55:16 -0800 (PST) Received: from zx81.paf.se.ietf53.cw.net (ssh-sjc-1.cisco.com [171.68.225.134]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id TAA25500; Wed, 20 Mar 2002 19:55:09 +0100 (MET) Date: Wed, 20 Mar 2002 12:54:55 -0600 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: ietf-ldup@imc.org, ietf-ldapext@netscape.com, ietf-ldapbis@OpenLDAP.org cc: Ned Freed Subject: Design considerations for LDAPv3 Message-ID: <1226464.1016628895@localhost> X-Mailer: Mulberry/2.2.0b3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On the basis of point G9 in document draft-ietf-ldup-replica-req-11.txt, I suggest that the bullet is rewritten so it only is a requirement on the replication protocol itself, and the more generic requirement be included in a separate document which can inlude other design considerations. I further suggest that this new document is to be added as a work item to the LDPABIS wg, if the wg accept to take on that task. If not, I am sure we can find another home for this new document. Patrik Area Director, Applications Area From owner-ietf-ldup@mail.imc.org Tue Mar 26 10:46:26 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07449 for ; Tue, 26 Mar 2002 10:46:26 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2QFNd529047 for ietf-ldup-bks; Tue, 26 Mar 2002 07:23:39 -0800 (PST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2QFNb429030 for ; Tue, 26 Mar 2002 07:23:37 -0800 (PST) Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2QFNVm18328 for ; Tue, 26 Mar 2002 10:23:31 -0500 (EST) Received: from zcard04n.ca.nortel.com ([47.129.242.86]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HLCVY8WP; Tue, 26 Mar 2002 10:23:30 -0500 Received: from metasolv.com (mpana-1.ca.nortel.com [47.128.183.58]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HQL95D7M; Tue, 26 Mar 2002 10:23:31 -0500 Message-ID: <3CA092EF.8A919381@metasolv.com> Date: Tue, 26 Mar 2002 10:25:35 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: Mircea Pana Reply-To: mpana@metasolv.com Organization: Metasolv Software X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: IETF LDUP Subject: LCUP and PSearch on Sync-And-Persist Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Both LCUP and PSearch are unclear on the order of results sent back to a client in case of a sync-and-persist search request. An order seems to be suggested but not formally recommended. If a client issues a search requests with the appropriate control and specifies updateType=synchronizeAndPersist (LCUP) or changesOnly=FALSE (PSearch), in response the server will start by sending all the data needed to synchronize the client. If a change occurs to an entry which satisfy the search criteria while the server is still synchronizing the client then: 1. the server will pause the synchronization, sent that changed entry to the client and then resume the synchronization -or- 2 (suggested). the server will queue the changed entry and sent it to the client after the synchronization is completed -or- 3. the server will ignore the change Which one of the above is recommended by LCUP / PSearch? How is a client informed that the synchronization is complete and the only results that it may eventually receive are changes? Regards, Mircea Pana. From owner-ietf-ldup@mail.imc.org Wed Mar 27 17:44:15 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28297 for ; Wed, 27 Mar 2002 17:44:15 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2RMRtt11635 for ietf-ldup-bks; Wed, 27 Mar 2002 14:27:55 -0800 (PST) Received: from nexus.adacel.com (shelob.adacel.com.au [203.36.26.146] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g2RMRkm11626 for ; Wed, 27 Mar 2002 14:27:51 -0800 (PST) Received: (qmail 4951 invoked from network); 27 Mar 2002 22:25:15 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 27 Mar 2002 22:25:15 -0000 Reply-To: From: "Steven Legg" To: Cc: Subject: URP Report for LDUP WG Meeting, 53rd IETF Date: Thu, 28 Mar 2002 09:26:17 +1100 Message-ID: <005301c1d5de$6a0c6de0$a518200a@osmium.mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0054_01C1D63A.9D7E6C80" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0054_01C1D63A.9D7E6C80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Attached is the slide I used when reporting the status of the URP document for the LDUP WG meeting. ------=_NextPart_000_0054_01C1D63A.9D7E6C80 Content-Type: application/vnd.ms-powerpoint; name="ietf53-ldup-urp.ppt" Content-Disposition: attachment; filename="ietf53-ldup-urp.ppt" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAAQAAAAAAAAAA EAAAAgAAAAIAAAD+////AAAAAAAAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////9 ////EwAAABQAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8A AAAQAAAAEQAAABIAAAAVAAAA/v////7////+//////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////////1IA bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAWAAUA//////////8BAAAAEI2BZJtPzxGG6gCqALkp6AAAAAAAAAAAAAAAABAhBUqvy8EB AwAAAEAgAAAAAAAAUABvAHcAZQByAFAAbwBpAG4AdAAgAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACgAAgECAAAAAwAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAASg8AAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0 AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQQAAAD//////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD4AAABoDQAAAAAAAAUARABvAGMAdQBtAGUAbgB0 AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB//////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdAAAAOACAAAAAAAAAQAA AAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAA EAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAe AAAAHwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwA AAAtAAAALgAAAC8AAAAwAAAAMQAAADIAAAAzAAAANAAAADUAAAA2AAAANwAAADgAAAA5AAAAOgAA ADsAAAA8AAAAPQAAAP7///8/AAAAQAAAAEEAAABCAAAAQwAAAEQAAABFAAAARgAAAEcAAABIAAAA SQAAAEoAAABLAAAATAAAAE0AAABOAAAATwAAAFAAAABRAAAAUgAAAFMAAABUAAAAVQAAAFYAAABX AAAAWAAAAFkAAABaAAAAWwAAAFwAAABdAAAAXgAAAF8AAABgAAAAYQAAAGIAAABjAAAAZAAAAGUA AABmAAAAZwAAAGgAAABpAAAAagAAAGsAAABsAAAAbQAAAG4AAABvAAAAcAAAAHEAAAByAAAAcwAA AP7///91AAAAdgAAAHcAAAB4AAAAeQAAAHoAAAB7AAAAfAAAAH0AAAB+AAAAfwAAAP7///8PAOgD qQQAAAEA6QMoAAAAgBYAAOAQAAC6EAAASxgAAAUAAAAKAAAAAAAAAAAAAAABAAAAAAAAAQ8A8gM8 AQAALwDIDwwAAAAwANIPBAAAAAAAAAAPANUHmAAAAAAAtw9EAAAAVABpAG0AZQBzACAATgBlAHcA IABSAG8AbQBhAG4AAACctRIAnLUSAKixEgD40wMwzLESAAgAAADMsRIAftQDMAAABAAQALcPRAAA AEwAdQBjAGkAZABhACAAUwBhAG4AcwAgAFUAbgBpAGMAbwBkAGUAAACosRIA+NMDMMyxEgAIAAAA zLESAH7UAzAAAAYiAACpDwoAAAAHAAAAAgAJDAAAQACjD24AAAAFAP/9PwAAACIgAABkAAAAAAAA AGQAAAAAAAAAAABAAgAAAAACAAAA///vAAAAAAD///////8YAAAAAAEAAAAFAAAgASABAAAAAAAF AABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAA8ACwR0AAAADwAA8GwAAAAAAAbwIAAA AAIMAAADAAAACQAAAAIAAAABAAAABwAAAAIAAAAEAAAAYwAL8CQAAACBAQQAAAiDAQAAAAi/ARAA EADAAQEAAAj/AQgACAABAgIAAAhAAB7xEAAAAAQAAAgBAAAIAgAACPcAABAfAPAPHAAAAAAA8wMU AAAAAgAAAAAAAAAAAAAAAAAAgAAAAAAPANAHiwAAAA8A+gNnAAAAAAD+AwMAAAAAAQAAAP0DNAAA AEoAAABkAAAASgAAAGQAAADYsRIAftQDMNCxEgAIAAAAEBcAABQNAADK/P//uP///wEAAABwAPsD CAAAAAAAAABwCAAAcAD7AwgAAAABAAAAQAsAAB8A/wMUAAAAAgAABAwAAAAAAAAAAAAAAAIAAAA/ ANkPDAAAAAAA2g8EAAAAAAAlAA8A8A/eAQAAAADzAxQAAAADAAAAAAAAAAIAAAAAAQAAAAAAAAAA nw8EAAAAAAAAAAAAqA8yAAAAQ2hhbmdlcyB0byBVUlAgRG9jdW1lbnQLZHJhZnQtaWV0Zi1sZHVw LXVycC0wNi50eHQAAKEPHgAAADMAAAAAAAAAAAAyAAAAAAADAAEAJAABAAAAAAAAAAAAqg8KAAAA MwAAAAEAAAAAABAAnw8EAAAAAQAAAAAAqA/uAAAAU3RhdGUtYmFzZWQgZGVzY3JpcHRpb25zIHJl bW92ZWQNR2VuZXJhdGlvbiBvZiBwcmltaXRpdmVzIG1hZGUgYXRvbWljIHdpdGggdXNlciB1cGRh dGUNTm8gc3VwZXJzZWRpbmcgb2YgcHJpbWl0aXZlcw1Db3JyZWN0aXZlIGNoYW5nZXMgbWFkZSBl eHBsaWNpdA1GbGF3IGluIHRoZSBsb2dpYyBmb3IgcmVhc3NlcnRpbmcgZGlzdGluZ3Vpc2hlZCB2 YWx1ZXMgY29ycmVjdGVkDU1pbm9yIGVkaXRvcmlhbCBjaGFuZ2VzDQAAoQ8gAAAA7wAAAAAAAAAA AO4AAAAAAAMAAQAcAAEAAAAAAAIAHAAAAKoPEgAAAO4AAAABAAAAAAABAAAAAAAAAAAA6gMAAAAA DwD4A3UIAAACAO8DGAAAAAEAAAABAgcJCAAAAAAAAAAAAAAAAAAAAGAA8AcgAAAA////AAAAAACA gIAAAAAAAADMmQAzM8wAzMz/ALKysgBgAPAHIAAAAAAA/wD///8AAAAAAP//AAD/mQAAAP//AP8A AACWlpYAYADwByAAAAD//8wAAAAAAGZmMwCAgAAAM5kzAIAAAAAAM8wA/8xmAGAA8AcgAAAA//// AAAAAAAzMzMAAAAAAN3d3QCAgIAATU1NAOrq6gBgAPAHIAAAAP///wAAAAAAgICAAAAAAAD/zGYA AAD/AMwAzADAwMAAYADwByAAAAD///8AAAAAAICAgAAAAAAAwMDAAABm/wD/AAAAAJkAAGAA8Acg AAAA////AAAAAACAgIAAAAAAADOZ/wCZ/8wAzADMALKysgAAAKMPPgAAAAEA//0/AAAAIiAAAGQA AAAAAAEAZAAAAAAAAAAAAEACAAAAAAIAAAD//+8AAAAAAP///////ywAAAAAAwAAEACjD3wAAAAF AP/9PwABACIgAABkAAAAAAAAAGQAFAAAANgAAABAAgAAAAACAAAA///vAAAAAAD///////8gAAAA AAEAAIAFAAATINQBIAEAAAIAHACABQAAIiDQAkACAAACABgAgAUAABMg8ANgAwAAAgAUAIAFAAC7 ABAFgAQAAAAAIACjD24AAAAFAP/9PwAAACIgAABkAAAAAAAAAGQAHgAAAAAAAABAAgAAAAACAAAA ///vAAAAAAD///////8MAAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAAAAAFAABgA2ADAAAA AAAFAACABIAEAAAAAFAAow9SAAAABQAAAAEJAAAAAAEAAAAAAAAAAQABCQAAAAABACABAAAAAAIA AQkAAAAAAQBAAgAAAAADAAEJAAAAAAEAYAMAAAAABAABCQAAAAABAIAEAAAAAGAAow8MAAAAAQAA AAAAAAAAAAAAcACjDz4AAAAFAAAAAAAAAAAAAgAcAAEAAAAAAAAAAgAYAAIAAAAAAAAAAgAUAAMA AAAAAAAAAgASAAQAAAAAAAAAAgASAIAAow8+AAAABQAAAAAAAAAAAAIAGAABAAAAAAAAAAIAFAAC AAAAAAAAAAIAEgADAAAAAAAAAAIAEAAEAAAAAAAAAAIAEAAPAAwE0wQAAA8AAvDLBAAAEAAI8AgA AAAGAAAABgQAAA8AA/BjBAAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAA AAAEAAAFAAAADwAE8NIAAAASAArwCAAAAAIEAAAACgAAkwAL8DYAAAB/AAEAAQCAAAQegQCHAAEA AACBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAIABsAHQFFAEDwAR 8BAAAAAAAMMLCAAAAAAAAAABAIEADwAN8FQAAAAAAJ8PBAAAAAAAAAAAAKgPIAAAAENsaWNrIHRv IGVkaXQgTWFzdGVyIHRpdGxlIHN0eWxlAACiDwYAAAAhAAAAAAAAAKoPCgAAACEAAAABAAAAAAAP AATwFgEAABIACvAIAAAAAwQAAAAKAACDAAvwMAAAAH8AAQABAIAAZB6BAIEBBAAACIMBAAAACL8B AQARAMABAQAACP8BAQAJAAECAgAACAAAEPAIAAAA4ASwAdAUAA8PABHwEAAAAAAAwwsIAAAAAQAA AAIAgQAPAA3wngAAAAAAnw8EAAAAAQAAAAAAqA9SAAAAQ2xpY2sgdG8gZWRpdCBNYXN0ZXIgdGV4 dCBzdHlsZXMNU2Vjb25kIGxldmVsDVRoaXJkIGxldmVsDUZvdXJ0aCBsZXZlbA1GaWZ0aCBsZXZl bAAAog8eAAAAIQAAAAAADQAAAAEADAAAAAIADQAAAAMADAAAAAQAAACqDwoAAABTAAAAAQAAAAAA DwAE8LUAAAASAArwCAAAAAQEAAAACgAAgwAL8DAAAAB/AAEAAQCAAMQegQCBAQQAAAiDAQAAAAi/ AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAGAPsAFgBoAQDwAR8BAAAAAAAMMLCAAAAAIA AAAHAYEADwAN8D0AAAAAAJ8PBAAAAAQAAAAAAKgPAQAAACoAAKEPFAAAAAIAAAAAAAAAAAACAAAA AAACAA4AAAD4DwQAAAAAAAAADwAE8LcAAAASAArwCAAAAAUEAAAACgAAgwAL8DAAAAB/AAEAAQCA ACQfgQCBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAGAPsAfQDoAQ DwAR8BAAAAAAAMMLCAAAAAMAAAAJAoEADwAN8D8AAAAAAJ8PBAAAAAQAAAAAAKgPAQAAACoAAKEP FgAAAAIAAAAAAAAIAAABAAIAAAAAAAIADgAAAPoPBAAAAAAAAAAPAATwtwAAABIACvAIAAAABgQA AAAKAACDAAvwMAAAAH8AAQABAIAAhB+BAIEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAEC AgAACAAAEPAIAAAAYA8gENAUgBAPABHwEAAAAAAAwwsIAAAABAAAAAgCgQAPAA3wPwAAAAAAnw8E AAAABAAAAAAAqA8BAAAAKgAAoQ8WAAAAAgAAAAAAAAgAAAIAAgAAAAAAAgAOAAAA2A8EAAAAAAAA AA8ABPBIAAAAEgAK8AgAAAABBAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgA vwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADM zP8AsrKyAA8A7gPYAQAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACAAAAAAAcAAAAPAAwEiAEAAA8A AvCAAQAAIAAI8AgAAAADAAAAAwgAAA8AA/AYAQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAA AAAAAAACAArwCAAAAAAIAAAFAAAADwAE8GwAAAASAArwCAAAAAIIAAAgAgAAQwAL8BgAAACAAOQf gQC/AQAAAQD/AQAAAQABAwIEAAAAABDwCAAAAIABsAHQFFAEDwAR8BAAAAAAAMMLCAAAAAAAAAAN AIEADwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwbAAAABIACvAIAAAAAwgAACACAABDAAvwGAAAAIAA RCCBAL8BAAABAP8BAAABAAEDAwQAAAAAEPAIAAAA4ASwAdAUAA8PABHwEAAAAAAAwwsIAAAAAQAA AA4AgQAPAA3wDAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAABCAAAAAwAAIMAC/AwAAAA gQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD/ //8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAAAAchcQAAAAAQAwAAAAAACxBAAALg0AAAAA 9Q8cAAAAAAEAAIMVAAMAAAAADg8AAAEAAAADAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAEAAIAAAAAAAAAAAAAAAAAAAAAAAEA AADghZ/y+U9oEKuRCAArJ7PZMAAAADgNAAAMAAAAAQAAAGgAAAACAAAAcAAAAAQAAACsAAAACAAA ALwAAAAJAAAAzAAAABIAAADYAAAACgAAAPgAAAALAAAABAEAAAwAAAAQAQAADQAAABwBAAAPAAAA KAEAABEAAAAwAQAAAgAAAOQEAAAeAAAAMwAAAENoYW5nZXMgdG8gVVJQIERvY3VtZW50IGRyYWZ0 LWlldGYtbGR1cC11cnAtMDYudHh0AGkeAAAABQAAAGxlZ2cAZXMgHgAAAAUAAABsZWdnAGVzIB4A AAACAAAAMgBnZx4AAAAVAAAATWljcm9zb2Z0IFBvd2VyUG9pbnQAbnQgQAAAANB3HIUCAAAAQAAA AEDaxiGvy8EBQAAAAFCSKMmry8EBQAAAAFD5+0mvy8EBAwAAACoAAABHAAAAAAwAAP////8DAAAA CABvEE0MAAABAAkAAAP4BQAABgA9AAAAAAARAAAAJgYPABgA/////wAAEAAAAAAAAAAAALoDAADK AgAACQAAACYGDwAIAP////8CAAAAFwAAACYGDwAjAP////8EABsAVE5QUBQAyPAAMAAAAAAUAAAA RA2BAAAAAAAAAAoAAAAmBg8ACgBUTlBQAAACAPQDCQAAACYGDwAIAP////8DAAAADwAAACYGDwAU AFROUFAEAAwAAQAAAAEAAAAAAAAABQAAAAsCAAAAAAUAAAAMAsoCugMFAAAABAENAAAABwAAAPwC AAD///8AAAAEAAAALQEAAAgAAAD6AgUAAQAAAAAAAAAEAAAALQEBAAQAAAAtAQAACQAAAB0GIQDw ANACwAMAAAAABAAAAC0BAAAHAAAA/AIAAP///wAAAAQAAAAtAQIABAAAAPABAAAIAAAA+gIAAAAA AAAAAAAABAAAAC0BAAAQAAAAJgYPABYA/////wAARwAAAI8CAAARAQAAwQIAAAgAAAAmBg8ABgD/ ////AQAcAAAA+wIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAAP0BClulh+13roftd9Bn73f9AQpb AAAKAAQAAAAtAQMABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAAAgECAAAAEAAAACYGDwAWAP////8A AEcBAACPAgAAeQIAAMECAAAIAAAAJgYPAAYA/////wEABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAA AgECAAAABwAAAPwCAQAAAAAAAAAEAAAALQEEAAQAAAAtAQEABwAAABsEuQB5A0AASAAEAAAALQEC AAQAAAAtAQAABQAAAAkCAAAAAgUAAAAUAgAAAAAcAAAA+wLQ/wAAAAAAAJABAAAAAAAAACJMdWNp ZGEgU2FucyBVbmljb2RlANBn73esAgpvAAAKAAQAAAAtAQUABAAAAPABAwAFAAAACQIAAAACBQAA ABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAAKgAAADIKbACpABcAAABDaGFuZ2VzIHRvIFVSUCBE b2N1bWVudHchAB4AGwAdAB4AGwAZAA8AEgAdAA8AIgAeABsADwAkAB0AGQAeAC0AGgAeABIABQAA AC4BAQAAAAUAAAACAQIAAAAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAA LgAAADIKpQCoABoAAABkcmFmdC1pZXRmLWxkdXAtdXJwLTA2LnR4dB4AFAAaABIAEgAcAA4AGgAS ABIAHAAOAB4AHgAeABwAHgATAB4AHAAfAB4ADwASAB4AEgAFAAAALgEBAAAABQAAAAIBAgAAAAUA AAACAQIAAAAEAAAALQEEAAQAAAAtAQEABwAAABsEgQJ5A9AASAAEAAAALQECAAQAAAAtAQAABQAA AAkCAAAAAgUAAAAUAgAAAAAcAAAA+wLb/wAAAAAAAJABAAAAAAAAACJMdWNpZGEgU2FucyBVbmlj b2RlANBn73f9AQpcAAAKAAQAAAAtAQMABAAAAPABBQAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAu ARgAAAAFAAAAAgEBAAAACAAAADIK9QBSAAEAAACVAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAkC AAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAADcAAAAyCvUAdgAgAAAAU3RhdGUtYmFz ZWQgZGVzY3JpcHRpb25zIHJlbW92ZWQUAA4AFQAOABUAFQAYABUAEwAUABgADAAXABUAEwATABAA CgAYAA4ACwAXABcAEwAMAA8AFQAjABcAEwAVABcABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQIA AAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAACAAAADIKKwFSAAEAAACVAAUAAAAuAQEA AAAFAAAAAgECAAAABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAAD0AAAAy CisBdgAkAAAAR2VuZXJhdGlvbiBvZiBwcmltaXRpdmVzIG1hZGUgYXRvbWljGwAVABcAFQAPABUA DgALABcAFwAMABcADQAMABgADwALACMACwAOAAoAFAAVABMACwAjABUAFwAVAAwAFQAOABcAIwAK ABQABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAA AgEBAAAAHwAAADIKWAF2ABAAAAB3aXRoIHVzZXIgdXBkYXRlHQALAA4AFwAMABcAEwAVAA8ADAAX ABgAFwAVAA4AFQAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4B GAAAAAUAAAACAQEAAAAIAAAAMgqNAVIAAQAAAJUABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQIA AAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAAMQAAADIKjQF2ABwAAABObyBzdXBlcnNl ZGluZyBvZiBwcmltaXRpdmVzHAAXAAsAEwAYABcAFQAPABMAFQAYAAoAGAAXAAwAFwANAAwAGAAP AAsAIwALAA4ACgAUABUAEwAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAgAAAAIFAAAAFAIAAAAA BQAAAC4BGAAAAAUAAAACAQEAAAAIAAAAMgrDAVIAAQAAAJUABQAAAC4BAQAAAAUAAAACAQIAAAAF AAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAANwAAADIKwwF2ACAAAABDb3Jy ZWN0aXZlIGNoYW5nZXMgbWFkZSBleHBsaWNpdBoAFwAPABAAFAAUAA4ACgAUABUACwAUABcAFAAY ABcAFQATAAwAIgAVABgAFAAMABUAFwAXAAsACwATAAsADgAFAAAALgEBAAAABQAAAAIBAgAAAAUA AAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAIAAAAMgr5AVIAAQAAAJUABQAA AC4BAQAAAAUAAAACAQIAAAAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAA OQAAADIK+QF2ACEAAABGbGF3IGluIHRoZSBsb2dpYyBmb3IgcmVhc3NlcnRpbmcAFAALABUAHAAM AAsAFwAMAA4AFwAVAAwACwAXABcACwATAAwADgAXAA8ADAAPABUAFQATABMAFAAQAA4ACwAXABcA BQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEB AAAANAAAADIKJgJ2AB4AAABkaXN0aW5ndWlzaGVkIHZhbHVlcyBjb3JyZWN0ZWQYAAoAEwAOAAsA FwAYABcACwATABcAFQAXAAwAEwAVAAsAFwAVABMADAATABcADwAQABQAFAAOABQAGAAFAAAALgEB AAAABQAAAAIBAgAAAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAIAAAA MgpcAlIAAQAAAJUABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAu ARgAAAAFAAAAAgEBAAAAKgAAADIKXAJ2ABcAAABNaW5vciBlZGl0b3JpYWwgY2hhbmdlc3cgAAsA FwAXABAACwAVABgACwAOABcADwALABQACwAMABMAFwAVABcAGAAUABMABQAAAC4BAQAAAAUAAAAC AQIAAAAFAAAAAgECAAAABAAAAC0BAQAEAAAALQEEABwAAAD7AhAABwAAAAAAvAIAAAAAAQICIlN5 c3RlbQB3IQVmjAcAigEAAAoABwCKAQcAigEAAAoABAAAAC0BBQAEAAAA8AEDAA8AAAAmBg8AFABU TlBQBAAMAAAAAAAAAAAAAAAAAAkAAAAmBg8ACAD/////AQAAAAMAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAP7/AAAEAAIAAAAAAAAAAAAAAAAAAAAAAAIAAAAC1c3VnC4bEJOXCAArLPmuRAAA AAXVzdWcLhsQk5cIACss+a5IAgAABAIAABAAAAABAAAAiAAAAAMAAACQAAAADwAAAKgAAAAEAAAA zAAAAAYAAADUAAAABwAAANwAAAAIAAAA5AAAAAkAAADsAAAACgAAAPQAAAAXAAAA/AAAAAsAAAAE AQAAEAAAAAwBAAATAAAAFAEAABYAAAAcAQAADQAAACQBAAAMAAAAogEAAAIAAADkBAAAHgAAAA8A AABPbi1zY3JlZW4gU2hvdwAAHgAAABwAAABBREFDRUwgVEVDSE5PTE9HSUVTIExJTUlURUQAAwAA AEoPAAADAAAABwAAAAMAAAABAAAAAwAAAAAAAAADAAAAAAAAAAMAAAAAAAAAAwAAADEVCAALAAAA AAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAAEAAAAEAAAAFRpbWVzIE5ldyBSb21hbgAU AAAATHVjaWRhIFNhbnMgVW5pY29kZQAPAAAARGVmYXVsdCBEZXNpZ24AMwAAAENoYW5nZXMgdG8g VVJQIERvY3VtZW50IGRyYWZ0LWlldGYtbGR1cC11cnAtMDYudHh0AAwQAAAGAAAAHgAAAAsAAABG b250cyBVc2VkAAMAAAACAAAAHgAAABAAAABEZXNpZ24gVGVtcGxhdGUAAwAAAAEAAAAeAAAADQAA AFNsaWRlIFRpdGxlcwADAAAAAQAAAAAAmAAAAAMAAAAAAAAAIAAAAAEAAAA2AAAAAgAAAD4AAAAB AAAAAgAAAAoAAABfUElEX0dVSUQAAgAAAOQEAABBAAAATgAAAHsARABFADQAOAA0ADAANgAxAC0A MwA3ADkARgAtADEAMQBEADYALQBBADAARABBAC0AMAAwADgAMABDADgANABFADYAOQBGADUAfQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEMAdQByAHIAZQBuAHQAIABVAHMA ZQByAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIA//////////// ////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAACQAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////8AAPYPHAAAABQAAABfwJHjJg8AAAQA 9AMDABIAbGVnZwgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== ------=_NextPart_000_0054_01C1D63A.9D7E6C80-- From owner-ietf-ldup@mail.imc.org Fri Mar 29 17:13:18 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05313 for ; Fri, 29 Mar 2002 17:13:17 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2TM4rZ05749 for ietf-ldup-bks; Fri, 29 Mar 2002 14:04:53 -0800 (PST) Received: from dns-ext-3.cotelligent.com (dns-ext-3.cotelligent.com [66.7.140.66]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2TM4qm05745 for ; Fri, 29 Mar 2002 14:04:52 -0800 (PST) Received: from cotldom21.cotelligent.com (cotldom21.cotelligent.com [10.86.0.21]) by dns-ext-3.cotelligent.com (8.11.3/8.11.3) with ESMTP id g2TM89X29177; Fri, 29 Mar 2002 17:08:09 -0500 Received: by cotldom21.cotelligent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Mar 2002 17:01:59 -0500 Message-ID: <916EA44D78B4D2118FE100805FBB8A2E010BD31B@sfa-phl-1.cotelligent.com> From: "Apple, Chris" To: "'Richard Huber'" , Internet Drafts Editor , IETF LDUP Mailing List , =?iso-8859-1?Q?=22F=E4ltstr=F6m=2C_Patrik=22?= , "Freed, Ned" Cc: Ryan Moats , Ellen Stokes , Russel Weiser , "Apple, Chris" , "Strassner, John" Subject: RE: LDUP Requirements draft 12 Date: Fri, 29 Mar 2002 17:02:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g2TM4rm05746 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Rick is correct. The document is ready for IESG consideration for publication as an Informational RFC once its officially published. Chris. -----Original Message----- From: Richard Huber [mailto:rvh@att.com] Sent: Friday, March 29, 2002 5:02 PM To: Internet Drafts Editor; IETF LDUP Mailing List; Fältström, Patrik; Freed, Ned Cc: Ryan Moats; Ellen Stokes; Russel Weiser; Apple, Chris; Strassner, John Subject: LDUP Requirements draft 12 Internet Drafts Editor - Please publish the attached as draft-ietf-ldup-replica-req-12.txt. ADs, LDUP List - This version of the requirements reflects the discussion at the LDUP meeting in Minneapolis and also the discussion among Chris, Kurt, and the ADs as reported in Patrik's email. There are only three real changes (the rest are date and version number edits): 1.Change to G9 per the meeting among Chris, Kurt, and the ADs. 2.Change to Security Considerations per mailing list and discussion in Minneapolis. 3.Remove RFC 2820 from References since the revised Security Considerations no longer reference it. The other IESG comments were addressed in draft -11, so it seems the draft should go back to the IESG. Rick Huber From owner-ietf-ldup@mail.imc.org Fri Mar 29 17:14:01 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05335 for ; Fri, 29 Mar 2002 17:13:58 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2TM33k05719 for ietf-ldup-bks; Fri, 29 Mar 2002 14:03:03 -0800 (PST) Received: from kcmso2.proxy.att.com (kcmso2.att.com [192.128.134.71]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2TM30m05713 for ; Fri, 29 Mar 2002 14:03:00 -0800 (PST) Received: from qsun.mt.att.com ([135.16.12.1]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-3.0) with SMTP id g2TM22119664; Fri, 29 Mar 2002 16:02:02 -0600 (CST) Received: from att.com by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id RAA18408; Fri, 29 Mar 2002 17:01:59 -0500 Message-ID: <3CA4E444.60A76713@att.com> Date: Fri, 29 Mar 2002 17:01:40 -0500 From: Richard Huber X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Internet Drafts Editor , IETF LDUP Mailing List , "=?iso-8859-1?Q?F=E4ltstr=F6m?=, Patrik" , "Freed, Ned" CC: Ryan Moats , Ellen Stokes , Russel Weiser , "Apple, Chris" , "Strassner, John" Subject: LDUP Requirements draft 12 Content-Type: multipart/mixed; boundary="------------194DC79164089E66582BCBD2" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------194DC79164089E66582BCBD2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Internet Drafts Editor - Please publish the attached as draft-ietf-ldup-replica-req-12.txt. ADs, LDUP List - This version of the requirements reflects the discussion at the LDUP meeting in Minneapolis and also the discussion among Chris, Kurt, and the ADs as reported in Patrik's email. There are only three real changes (the rest are date and version number edits): 1.Change to G9 per the meeting among Chris, Kurt, and the ADs. 2.Change to Security Considerations per mailing list and discussion in Minneapolis. 3.Remove RFC 2820 from References since the revised Security Considerations no longer reference it. The other IESG comments were addressed in draft -11, so it seems the draft should go back to the IESG. Rick Huber --------------194DC79164089E66582BCBD2 Content-Type: text/plain; charset=us-ascii; name="draft-ietf-ldup-replica-req-12.txt" Content-Disposition: inline; filename="draft-ietf-ldup-replica-req-12.txt" Content-Transfer-Encoding: 7bit Internet-Draft Ellen J. Stokes LDAP Duplication/Replication/Update Tivoli Systems Protocols WG Russel F. Weiser Intended Category: Informational Digital Signature Trust Expires: September 2002 Ryan D. Moats Lemur Networks Richard V. Huber AT&T Laboratories March 2002 LDAPv3 Replication Requirements draft-ietf-ldup-replica-req-12.txt Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt. The list of Internet-Drafts Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document discusses the fundamental requirements for replication of data accessible via the Lightweight Directory Access Protocol (version 3) [RFC2251]. It is intended to be a gathering place for general replication requirements needed to provide interoperability between informational directories. Stokes, et al Expires September 2002 [Page 1] Internet-Draft LDAPv3 Replication Requirements March 2002 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Stokes, et al Expires September 2002 [Page 2] Internet-Draft LDAPv3 Replication Requirements March 2002 Table of Contents 1 Introduction.......................................................4 2 Terminology........................................................4 3 The Models.........................................................7 4 Requirements.......................................................8 4.1 General........................................................8 4.2 Model..........................................................9 4.3 Protocol......................................................10 4.4 Schema........................................................11 4.5 Single Master.................................................11 4.6 Multi-Master..................................................12 4.7 Administration and Management.................................12 4.8 Security......................................................13 5 Security Considerations...........................................14 6 Acknowledgements..................................................14 7 References........................................................14 A. APPENDIX A - Usage Scenarios....................................15 A.1. Extranet Example.............................................16 A.2. Consolidation Example........................................16 A.3. Replication Heterogeneous Deployment Example.................16 A.4. Shared Name Space Example....................................17 A.5. Supplier Initiated Replication...............................17 A.6. Consumer Initiated Replication...............................17 A.7. Prioritized attribute replication............................17 A.8. Bandwidth issues.............................................18 A.9. Interoperable Administration and Management..................18 A.10. Enterprise Directory Replication Mesh........................19 A.11. Failure of the Master in a Master-Slave Replicated Directory 19 A.12. Failure of a Directory Holding Critical Service Information..19 B. APPENDIX B - Rationale..........................................20 B.1. Meta-Data Implications.......................................20 B.2. Order of Transfer for Replicating Data.......................20 B.3. Schema Mismatches and Replication............................21 B.4. Detecting and Repairing Inconsistencies Among Replicas.......22 B.5. Some Test Cases for Conflict Resolution in Multi-Master Replication........................................................23 B.6. Data Confidentiality and Data Integrity During Replication...26 B.7. Failover in Single-Master Systems............................27 B.8. Including Operational Attributes in Atomic Operations........28 Authors' Addresses..................................................28 Full Copyright Statement............................................29 Stokes, et al Expires September 2002 [Page 3] Internet-Draft LDAPv3 Replication Requirements March 2002 1 Introduction Distributing directory information throughout the network provides a two-fold benefit: (1) it increases the reliability of the directory through fault tolerance, and (2) it brings the directory content closer to the clients using the data. LDAP's success as an access protocol for directory information is driving the need to distribute LDAP directory content within the enterprise and Internet. Currently, LDAP does not define a replication mechanism, and mentions LDAP shadow servers (see [RFC2251]) in passing. A standard mechanism for directory replication in a multi-vendor environment is critical to the continued success of LDAP in the market place. This document sets out the requirements for replication between multiple LDAP servers. While RFC 2251 and RFC 2252 [RFC2252] set forth the standards for communication between LDAP clients and servers there are additional requirements for server-to-server communication. Some of these are covered here. This document first introduces the terminology to be used, then presents the different replication models being considered. Requirements follow, along with security considerations. The reasoning that leads to the requirements is presented in the Appendices. This was done to provide a clean separation of the requirements from their justification. 2 Terminology The following terms are used in this document: Anonymous Replication - Replication where the endpoints are identified to each other but not authenticated. Also known as "unauthenticated replication". Area of replication - A whole or portion of a Directory Information Tree (DIT) that makes up a distinct unit of data to be replicated. An area of replication is defined by a replication base entry and includes all or some of the depending entries contained therein on a single server. It divides directory data into partitions whose propagation behavior may be independently configured from other partitions. Areas of replication may overlap or be nested. This is a subset of the definition of a "replicated area" in X.525 [X.525]. Stokes, et al Expires September 2002 [Page 4] Internet-Draft LDAPv3 Replication Requirements March 2002 Atomic operation - A set of changes to directory data which the LDAP standards guarantee will be treated as a unit; all changes will be made or all the changes will fail. Atomicity Information - Information about atomic operations passed as part of replication. Conflict - A situation that arises when changes are made to the same directory data on different directory servers before replication can synchronize the data on the servers. When the servers do synchronize, they have inconsistent data - a conflict. Conflict resolution - Deterministic procedures used to resolve change information conflicts that may arise during replication. Critical OID - Attributes or object classes defined in the replication agreement as being critical to the operation of the system. Changes affecting critical OIDs cause immediate initiation of a replica cycle. An example of a critical OID might be a password or certificate. Fractional replication - The capability to filter a subset of attributes for replication. Incremental Update - An update that contains only those attributes or entries that have changed. Master Replica - A replica that may be directly updated via LDAP operations. In a Master-Slave Replication system, the Master Replica is the only directly updateable replica in the replica-group. Master-Slave, or Single Master Replication - A replication model that assumes only one server, the master, allows LDAP write access to the replicated data. Note that Master-Slave replication can be considered a proper subset of multi-master replication. Meta-Data - Data collected by the replication system that describes the status/state of replication. Multi-Master Replication - A replication model where entries can be written and updated on any of several master replica copies without requiring communication with other master replicas before the write or update is performed. One-way Replication - The process of synchronization in a single direction where the authoritative source information is provided to a replica. Stokes, et al Expires September 2002 [Page 5] Internet-Draft LDAPv3 Replication Requirements March 2002 Partial Replication - Partial Replication is Fractional Replication, Sparse Replication, or both. Propagation Behavior - The behavior of the synchronization process between a consumer and a supplier. Replica - An instance of an area of replication on a server. Replica-Group - The servers that hold instances of a particular area of replication. A server may be part of several replica-groups. Replica (or Replication) Cycle - The interval during which update information is exchanged between two or more replicas. It begins during an attempt to push data to, or pull data from, another replica or set of replicas, and ends when the data has successfully been exchanged or an error is encountered. Replication - The process of synchronizing data distributed across directory servers and rectifying update conflicts. Replication Agreement - A collection of information describing the parameters of replication between two or more servers in a replica- group. Replication Base Entry - The distinguished name of the root vertex of a replicated area. Replication Initiation Conflict - A Replication Initiation Conflict is a situation where two sources want to update the same replica at the same time. Replication Session - A session set up between two servers in a replica-group to pass update information as part of a replica cycle. Slave (or Read-Only) Replica - A replica that cannot be directly updated via LDAP requests. Changes may only be made via replication from a master replica. Read-only replicas may occur in both single- and multi-master systems. Sparse Replication - The capability to filter some subset of entries (other than a complete collection) of an area of replication. Topology - The shape of the directed graph describing the relationships between replicas. Two-way Replication - The process of synchronization where change information flows bi-directionally between two replicas. Stokes, et al Expires September 2002 [Page 6] Internet-Draft LDAPv3 Replication Requirements March 2002 Unauthenticated Replication - See Anonymous Replication. Update Propagation - Protocol-based process by which directory replicas are reconciled. 3 The Models The objective is to provide an interoperable, LDAP v3 directory synchronization protocol that is simple, efficient and flexible; supporting both multi-master and master-slave replication. The protocol must meet the needs of both the Internet and enterprise environments. There are five data consistency models. Model 1: Transactional Consistency -- Environments that exhibit all four of the ACID properties (Atomicity, Consistency, Isolation, Durability) [ACID]. Model 2: Eventual (or Transient) Consistency -- Environments where definite knowledge of the topology is provided through predetermined replication agreements. Examples include X.500 Directories (the X.500 model is single-master only) [X.501, X.525], Bayou [XEROX], and NDS (Novell Directory Services) [NDS]. In this model, every update propagates to every replica that it can reach via a path of stepwise eventual connectivity. Model 3: Limited Effort Eventual (or Probabilistic) Consistency -- Environments that provide a statistical probability of convergence with knowledge of topology. An example is the Xerox Clearinghouse [XEROX2]. This model is similar to "Eventual Consistency", except where replicas may purge updates. Purging drops propagation changes when some replica time boundary is exceeded, thus leaving some changes replicated to only a portion of the topology. Transactional consistency is not preserved, though some weaker constraints on consistency are available. Model 4: Loosest Consistency -- Environments where information is provided from an opportunistic or simple cache until stale. Complete knowledge of topology may not be shared among all replicas. Model 5: Ad hoc -- A copy of a data store where no follow up checks are made for the accuracy/freshness of the data. Consistency models 1, 2 and 3 involve the use of prearranged replication agreements among servers. While model 1 may simplify support for atomicity in multi-master systems, the added complexity of the distributed 2-phase commit required for Model 1 is significant; Stokes, et al Expires September 2002 [Page 7] Internet-Draft LDAPv3 Replication Requirements March 2002 therefor, model 1 will not be considered at this time. Models 4 and 5 involve unregistered replicas that "pull" updates from another directory server without that server's knowledge. These models violate a directory's security policies. Models 2 and 3 illustrate two replication scenarios that must be handled: policy configuration through security management parameters (model 2), and hosting relatively static data and address information as in white-pages applications (model 3). Therefore, replication requirements are presented for models 2 and 3. Interoperability among directories using LDAP replication may be limited for implementations that add semantics beyond those specified by the LDAP core documents (RFC 2251-2256, 2829, 2830). In addition, the "core" specifications include numerous features which are not mandatory-to-implement (e.g. RECOMMENDED or OPTIONAL). There are also numerous elective extensions. Thus LDAP replication interoperability between independent implementations of LDAP which support different options may be limited. Use of applicability statements to improve interoperability in particular application spaces is RECOMMENDED. 4 Requirements 4.1 General G1. LDAP Replication MUST support models 2 (Eventual Consistency) and 3 (Limited Effort Eventual Consistency) above. G2. LDAP Replication SHOULD NOT preclude support for model 1 (Transactional Consistency) in the future. G3. LDAP replication SHOULD have minimal impact on system performance. G4. The LDAP Replication Standard SHOULD NOT limit the replication transaction rate. G5. The LDAP replication standard SHOULD NOT limit the size of an area of replication or a replica. G6. Meta-data collected by the LDAP replication mechanism MUST NOT grow without bound. G7. All policy and state data pertaining to replication MUST be accessible via LDAP. G8. LDAP replication MUST be capable of replicating the following: Stokes, et al Expires September 2002 [Page 8] Internet-Draft LDAPv3 Replication Requirements March 2002 - all userApplication attribute types - all directoryOperation and distributedOperation attribute types defined in the LDAP "core" specifications (RFC 2251- 2256, 2829-2830) - attribute subtypes - attribute description options (e.g. ";binary" and Language Tags) G9. LDAP replication SHOULD support replication of directoryOperation and distributedOperation attribute types defined in standards track LDAP extensions. G10. LDAP replication MUST NOT support replication of dsaOperation attribute types as such attributes are DSA-specific. G11. The LDAP replication system should limit impact on the network by minimizing the number of messages and the amount of traffic sent. 4.2 Model M1. The model MUST support the following triggers for initiation of a replica cycle: a) A configurable set of scheduled times b) Periodically, with a configurable period between replica cycles c) A configurable maximum amount of time between replica cycles d) A configurable number of accumulated changes e) Change in the value of a critical OID f) As the result of an automatic rescheduling after a replication initiation conflict g) A manual request for immediate replication With the exception of manual request, the specific trigger(s) and related parameters for a given server MUST be identified in a well- known place defined by the standard, e.g. the Replication Agreement(s). M2. The replication model MUST support both master-slave and multi- master relationships. M3. An attribute in an entry must eventually converge to the same set of values in every replica holding that entry. M4. LDAP replication MUST encompass schema definitions, attribute names and values, access control information, knowledge information, and name space information. Stokes, et al Expires September 2002 [Page 9] Internet-Draft LDAPv3 Replication Requirements March 2002 M5. LDAP replication MUST NOT require that all copies of the replicated information be complete, but MAY require that at least one copy be complete. The model MUST support Partial Replicas. M6. The determination of which OIDs are critical MUST be configurable in the replication agreement. M7. The parameters of the replication process among the members of the replica-group, including access parameters, necessary authentication credentials, assurances of confidentiality (encryption), and area(s) of replication MUST be defined in a standard location (e.g. the replication agreements). M8. The replication agreements SHOULD accommodate multiple servers receiving the same area of replication under a single predefined agreement. M9. LDAP replication MUST provide scalability to both enterprise and Internet environments, e.g. an LDAP server must be able to provide replication services to replicas within an enterprise as well as across the Internet. M10. While different directory implementations can support different/extended schema, schema mismatches between two replicating servers MUST be handled. One way of handling such mismatches might be to raise an error condition. M11. There MUST be a facility that can update, or totally refresh, a replica-group from a standard data format, such as LDIF format [RFC2849]. M12. An update received by a consumer more than once MUST NOT produce a different outcome than if the update were received only once. 4.3 Protocol P1. The replication protocol MUST provide for recovery and rescheduling of a replication session due to replication initiation conflicts (e.g. consumer busy replicating with other servers) and or loss of connection (e.g. supplier cannot reach a replica). P2. LDUP replication SHOULD NOT send an update to a consumer if the consumer has previously acknowledged that update. P3. The LDAP replication protocol MUST allow for full update to facilitate replica initialization and reset loading utilizing a standardized format such as LDIF [RFC2849] format. Stokes, et al Expires September 2002 [Page 10] Internet-Draft LDAPv3 Replication Requirements March 2002 P4. Incremental replication MUST be allowed. P5. The replication protocol MUST allow either a master or slave replica to initiate the replication process. P6. The protocol MUST preserve atomicity of LDAP operations as defined in RFC2251 [RFC2251]. In a multi-master environment this may lead to an unresolvable conflict. MM5 and MM6 discuss how to handle this situation. P7. The protocol MUST support a mechanism to report schema mismatches between replicas discovered during a replication session. 4.4 Schema SC1. A standard way to determine what replicas are held on a server MUST be defined. SC2. A standard schema for representing replication agreements MUST be defined. SC3. The semantics associated with modifying the attributes of replication agreements MUST be defined. SC4. A standard method for determining the location of replication agreements MUST be defined. SC5. A standard schema for publishing state information about a given replica MUST be defined. SC6. A standard method for determining the location of replica state information MUST be defined. SC7. It MUST be possible for appropriately authorized administrators, regardless of their network location, to access replication agreements in the DIT. SC8. Replication agreements of all servers containing replicated information MUST be accessible via LDAP. SC9. An entry MUST be uniquely identifiable throughout its lifetime. 4.5 Single Master SM1. A Single Master system SHOULD provide a fast method of promoting a slave replica to become the master replica. Stokes, et al Expires September 2002 [Page 11] Internet-Draft LDAPv3 Replication Requirements March 2002 SM2. The master replica in a Single Master system SHOULD send all changes to read-only replicas in the order in which the master applied them. 4.6 Multi-Master MM1. The replication protocol SHOULD NOT saturate the network with redundant or unnecessary entry replication. MM2. The initiator MUST be allowed to determine whether it will become a consumer or supplier during the synchronization startup process. MM3. During a replica cycle, it MUST be possible for the two servers to switch between the consumer and supplier roles. MM4. When multiple master replicas want to start a replica cycle with the same replica at the same time, the model MUST have an automatic and deterministic mechanism for resolving or avoiding replication initiation conflict. MM5. Multi-master replication MUST NOT lose information during replication. If conflict resolution would result in the loss of directory information, the replication process MUST store that information, notify the administrator of the nature of the conflict and the information that was lost, and provide a mechanism for possible override by the administrator. MM6. Multi-master replication MUST support convergence of the values of attributes and entries. Convergence may result in an event as described in MM5. MM7. Multi-master conflict resolution MUST NOT depend on the in-order arrival of changes at a replica to assure eventual convergence. MM8. Multi-master replication MUST support read-only replicas as well as read-write replicas. 4.7 Administration and Management AM1. Replication agreements MUST allow the initiation of a replica cycle to be administratively postponed to a more convenient period. AM2. Each copy of a replica MUST maintain audit history information of which servers it has replicated with and which servers have replicated with it. Stokes, et al Expires September 2002 [Page 12] Internet-Draft LDAPv3 Replication Requirements March 2002 AM3. Access to replication agreements, topologies, and policy attributes MUST be provided through LDAP. AM4. The capability to check the differences between two replicas for the same information SHOULD be provided. AM5. A mechanism to fix differences between replicas without triggering new replica cycles SHOULD be provided. AM6. The sequence of updates to access control information (ACI) and the data controlled by that ACI MUST be maintained by replication. AM7. It MUST be possible to add a 'blank' replica to a replica-group, and force a full update from (one of) the Master(s), for the purpose of adding a new directory server to the system. AM8. Vendors SHOULD provide tools to audit schema compatibility within a potential replica-group. 4.8 Security The terms "data confidentiality" and "data integrity" are defined in the Internet Security Glossary [RFC2828]. S1. The protocol MUST support mutual authentication of the source and the replica directories during initialization of a replication session. S2. The protocol MUST support mutual verification of authorization of the source to send and the replica to receive replicated data during initialization of a replication session. S3. The protocol MUST also support the initialization of anonymous replication sessions. S4. The replication protocol MUST support transfer of data with data integrity and data confidentiality. S5. The replication protocol MUST support the ability during initialization of a replication session for an authenticated source and replica to mutually decide to disable data integrity and data confidentiality within the context of and for the duration of that particular replication session. S6. To promote interoperability, there MUST be a mandatory-to- implement data confidentiality mechanism. Stokes, et al Expires September 2002 [Page 13] Internet-Draft LDAPv3 Replication Requirements March 2002 S7. The transport for administrative access MUST permit assurance of the integrity and confidentiality of all data transferred. S8. To support data integrity, there must be a mandatory-to-implement data integrity mechanism. 5 Security Considerations This document includes security requirements (listed in section 4.8 above) for the replication model and protocol. As noted in Section 3, interoperability may be impacted when replicating among servers that implement non-standard extensions to basic LDAP semantics. Security- related and general LDAP interoperability will be significantly impacted by the degree of consistency with which implementations support existing and future standards detailing LDAP security models, such as a future standard LDAP access control model. 6 Acknowledgements This document is based on input from IETF members interested in LDUP Replication. 7 References [ACID] T. Haerder, A. Reuter, "Principles of Transaction-Oriented Database Recovery", Computing Surveys, Vol. 15, No. 4 (December 1983), pp. 287-317. [NDS] Novell, "NDS Technical Overview", 104-000223-001, http://developer.novell.com/ndk/doc/ndslib/dsov_enu/data/h6tvg4z7.html, September, 2000. [RFC2119] S. Bradner, "Key Words for Use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol", RFC 2251, December 1997. [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997. [RFC2253] S. Kille, M. Wahl, and T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997. Stokes, et al Expires September 2002 [Page 14] Internet-Draft LDAPv3 Replication Requirements March 2002 [RFC2254] T. Howes, "The String Representation of LDAP Search Filters", RFC 2254, December 1997. [RFC2255] T. Howes, M. Smith, "The LDAP URL Format", RFC 2255, December 1997. [RFC2256] M. Wahl, "A Summary of the X.500(96) User Schema for use with LDAPv3", RFC 2256, December 1997. [RFC2828] R. Shirey, "Internet Security Glossary", RFC2828, May 2000. [RFC2829] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan. "Authentication Methods for LDAP", RFC 2829, May 2000. [RFC2830] J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security", RFC 2830, May 2000. [RFC2849] Gordon Good, "The LDAP Data Interchange Format (LDIF)", RFC 2849, June 2000. [X.501] ITU-T Recommendation X.501 (1993), | ISO/IEC 9594-2: 1993, Information Technology - Open Systems Interconnection - The Directory: Models. [X.525] ITU-T Recommendation X.525 (1997), | ISO/IEC 9594-9: 1997, Information Technology - Open Systems Interconnection - The Directory: Replication. [XEROX] C. Hauser, "Managing update conflicts in Bayou, a weakly connected replicated storage system". Palo Alto, CA: Xerox PARC, Computer Science Laboratory; 1995 August; CSL-95-4. [CSL-95-04] [XEROX2] Alan D. Demers, Mark Gealy, Daniel Greene, Carl Hauser, Wesley Irish, John Larson, Sue Manning, Scott Shenker, Howard Sturgis, Daniel Swinehart, Douglas Terry, Don Woods, "Epidemic Algorithms for Replicated Database Maintenance". Palo Alto, CA, Xerox PARC, January 1989. A. APPENDIX A - Usage Scenarios The following directory deployment examples are intended to validate our replication requirements. A heterogeneous set of directory implementations is assumed for all the cases below. This material is intended as background; no requirements are presented in this Appendix. Stokes, et al Expires September 2002 [Page 15] Internet-Draft LDAPv3 Replication Requirements March 2002 A.1. Extranet Example A company has a trading partner with whom it wishes to share directory information. This information may be as simple as a corporate telephone directory, or as complex as an extranet workflow application. For performance reasons, the company wishes to place a replica of its directory within the Partner Company, rather than exposing its directory beyond its firewall. The requirements that follow from this scenario are: - One-way replication, single mastered. - Authentication of clients. - Common access control and access control identification. - Secure transmission of updates. - Selective attribute replication (Fractional Replication), so that only partial entries can be replicated. A.2. Consolidation Example Company A acquires company B. Each company has an existing directory. During the transition period, as the organizations are merged, both directory services must coexist. Company A may wish to attach company B's directory to its own. The requirements that follow from this scenario are: - Multi-Master replication. - Common access control model. Access control model identification. - Secure transmission of updates. - Replication between DITs with potentially differing schema. A.3. Replication Heterogeneous Deployment Example An organization may choose to deploy directory implementations from multiple vendors, to enjoy the distinguishing benefits of each. In this case, multi-master replication is required to ensure that the multiple replicas of the DIT are synchronized. Some vendors may provide directory clients, which are tied to their own directory service. The requirements that follow from this scenario are: - Multi-Master replication - Common access control model and Access control model identification. - Secure transmission of updates. - Replication among DITs with potentially differing schemas. Stokes, et al Expires September 2002 [Page 16] Internet-Draft LDAPv3 Replication Requirements March 2002 A.4. Shared Name Space Example Two organizations may choose to cooperate on some venture and need a shared name space to manage their operation. Both organizations will require administrative rights over the shared name space. The requirements that follow from this scenario are: - Multi-Master replication. - Common access control model and Access control model identification. - Secure transmission of updates. A.5. Supplier Initiated Replication This is a single master environment that maintains a number of replicas of the DIT by pushing changes based on a defined schedule. The requirements that follow from this scenario are: - Single-master environment. - Supplier-initiated replication. - Secure transmission of updates. A.6. Consumer Initiated Replication Again a single mastered replication topology, but the slave replica initiates the replication exchange rather than the master. An example of this is a replica that resides on a laptop computer that may run disconnected for a period of time. The requirements that follow from this scenario are: - Single-master environment. - Consumer initiated replication. - Open scheduling (anytime). A.7. Prioritized attribute replication The password attribute can provide an example of the requirement for prioritized attribute replication. A user is working in Utah and the administrator resides in California. The user has forgotten his password. So the user calls or emails the administrator to request a new password. The administrator provides the updated password (a change). Under normal conditions, the directory replicates to a number of different locations overnight. But corporate security policy states that passwords are critical and the new value must be available Stokes, et al Expires September 2002 [Page 17] Internet-Draft LDAPv3 Replication Requirements March 2002 immediately (e.g. shortly) after any change. Replication needs to occur immediately for critical attributes/entries. The requirements that follow from this scenario are: - Incremental replication of changes. - Immediate replication on change of certain attributes. - Replicate based on time/attribute semantics. A.8. Bandwidth issues The replication of Server (A) R/W replica (a) in Kathmandu is handled via a dial up phone link to Paris where server (B) R/W replica of (a) resides. Server (C) R/W replica of (a) is connected by a T1 connection to server (B). Each connection has a different performance characteristic. The requirements that follow from this scenario are: - Minimize repetitive updates when replicating from multiple replication paths. - Incremental replication of changes. - Provide replication cycles to delay and/or retry when connections cannot be reached. - Allowances for consumer initiated or supplier initiated replication. A.9. Interoperable Administration and Management The administrator with administrative authority of the corporate directory which is replicated by numerous geographically dispersed LDAP servers from different vendors notices that the replication process is not completing correctly as the change log is continuing to grow and/or error message informs him. The administrator uses his $19.95 RepCo LDAP directory replication diagnostics tools to look at Root DSE replica knowledge on server 17 and determines that server 42 made by LDAP'RUS Inc. is not replicating properly due to an Object conflict. Using his Repco Remote repair tools he connects to server 42 and resolves the conflict on the remote server. The requirements that follow from this scenario are: - Provides replication audit history. - Provisions for managing conflict resolution. - Provide LDAP access to predetermined agreements, topology and policy attributes. - Provide operations for comparing replica's content for validity. - Provide LDAP access to status and audit information. Stokes, et al Expires September 2002 [Page 18] Internet-Draft LDAPv3 Replication Requirements March 2002 A.10. Enterprise Directory Replication Mesh A Corporation builds a mesh of directory servers within the enterprise utilizing LDAP servers from various vendors. Five servers are holding the same area of replication. The predetermined replication agreement(s) for the enterprise mesh are under a single management, and the security domain allows a single predetermined replication agreement to manage the 5 servers' replication. The requirements that follow from this scenario are: - One predefined replication agreement that manages a single area of replication that is held on numerous servers. - Common support of replication management knowledge across vendor implementation. - Rescheduling and continuation of a replication cycle when one server in a replica-group is busy and/or unavailable. A.11. Failure of the Master in a Master-Slave Replicated Directory A company has a corporate directory that is used by the corporate email system. The directory is held on a mesh of servers from several vendors. A corporate relocation results in the closing of the location where the master copy of the directory is located. Employee information (such as mailbox locations and employee certificate information) must be kept up to date or mail cannot be delivered. The requirements that follow from this scenario are: - An existing slave replica must be "promote-able" to become the new master. - The "promotion" must be done without significant downtime, since updates to the directory will continue. A.12. Failure of a Directory Holding Critical Service Information An ISP uses a policy management system that uses a directory as the policy data repository. The directory is replicated in several different sites on different vendors' products to avoid single points of failure. It is imperative that the directory be available and be updateable even if one site is disconnected from the network. Changes to the data must be traceable, and it must be possible to determine how changes made from different sites interacted. The requirements that follow from this scenario are: - Multi-master replication - Ability to reschedule replication sessions Stokes, et al Expires September 2002 [Page 19] Internet-Draft LDAPv3 Replication Requirements March 2002 - Support for manual review and override of replication conflict resolution B. APPENDIX B - Rationale This Appendix gives some of the background behind the requirements. It is included to help the protocol designers understand the thinking behind some of the requirements and to present some of the issues that should be considered during design. With the exception of section B.8, which contains a suggested requirement for the update to RFC 2251, this Appendix does not state any formal requirements. B.1. Meta-Data Implications Requirement G4 states that meta-data must not grow without bound. This implies that meta-data must, at some point, be purged from the system. This, in turn, raises concerns about stability. Purging meta-data before all replicas have been updated may lead to incomplete replication of change information and inconsistencies among replicas. Therefore, care must be taken setting up the rules for purging meta- data from the system while still ensuring that meta-data will not grow forever. B.2. Order of Transfer for Replicating Data Situations may arise where it would be beneficial to replicate data out-of-order (e.g. send data to consumer replicas in a different order than it was processed at the supplier replica). One such case might occur if a large bulk load was done on the master server in a single- master environment and then a single change to a critical OID (a password change, for example) was then made. Rather than wait for all the bulk data to be sent to the replicas, the password change might be moved to the head of the queue and be sent before all the bulk data was transferred. Other cases where this might be considered are schema changes or changes to critical policy data stored in the directory. While there are practical benefits to allowing out-of-order transfer, there are some negative consequences as well. Once out-of-order transfers are permitted, all receiving replicas must be prepared to deal with data and schema conflicts that might arise. As an example, assume that schema changes are critical and must be moved to the front of the replication queue. Now assume that a schema change deletes an attribute for some object class. It is possible that some of the operations ahead of the schema change in the queue are operations to delete values of the soon-to-be-deleted attribute so that the schema change can be done with no problems. If the schema change Stokes, et al Expires September 2002 [Page 20] Internet-Draft LDAPv3 Replication Requirements March 2002 moves to the head of the queue, the consumer servers might have to delete an attribute that still has values, and then receive requests to delete the values of an attribute that is no longer defined. In the multi-master case, similar situations can arise when simultaneous changes are made to different replicas. Thus, multi- master systems must have conflict resolution algorithms in place to handle such situations. But in the single-master case conflict resolution is not needed unless the master is allowed to send data out- of-order. This is the reasoning behind requirement SM2, which recommends that data always be sent in order in single-master replication. Note that even with this restriction, the concept of a critical OID is still useful in single-master replication. An example of its utility can be found in section A.7. B.3. Schema Mismatches and Replication Multi-vendor environments are the primary area of interest for LDAP replication standards. Some attention must thus be paid to the issue of schema mismatches, since they can easily arise when vendors deliver slightly different base schema with their directory products. Even when both products meet the requirements of the standards [RFC2252], the vendors may have included additional attributes or object classes with their products. When two different vendors' products attempt to replicate, these additions can cause schema mismatches. Another potential cause of schema mismatches is discussed in section A.3. There are only a few possible responses when a mismatch is discovered. - Raise an error condition and ignore the data. This should always be allowed and is the basis for requirement P8 and the comment on M10. - Map/convert the data to the form required by the consuming replica. A system may choose this course; requirement M10 is intended to allow this option. The extent of the conversion is up to the implementation; in the extreme it could support use of the replication protocol in meta-directories. - Quietly ignore (do not store on the consumer replica and do not raise an error condition) any data that does not conform to the schema at the consumer. Requirement M10 is intended to exclude the last option. Requirement AM8 suggests that vendors should provide tools to help discover schema mismatches when replication is being set up. But schema will change after the initial setup, so the replication system must be prepared to handle unexpected mismatches. Stokes, et al Expires September 2002 [Page 21] Internet-Draft LDAPv3 Replication Requirements March 2002 Normal IETF practice in protocol implementation suggests that one be strict in what one sends and be flexible in what one receives. The parallel in this case is that a supplier should be prepared to receive an error notification for any schema mismatch, but a consumer may choose to do a conversion instead. The other option that can be considered in this situation is the use of fractional replication. If replication is set up so only the common attributes are replicated, mismatches can be avoided. One additional consideration here is replication of the schema itself. M4 requires that it be possible to replicate schema. If a consumer replica is doing conversion, extreme care should be taken if schema elements are replicated since some attributes are intended to have different definitions on different replicas. For fractional replication, the protocol designers and implementors should give careful consideration to the way they handle schema replication. Some options for schema replication include: - All schema elements are replicated. - Schema elements are replicated only if they are used by attributes that are being replicated. - Schema are manually configured on the servers involved in fractional replication; schema elements are not replicated via the protocol. B.4. Detecting and Repairing Inconsistencies Among Replicas Despite the best efforts of designers, implementors, and operators, inconsistencies will occasionally crop up among replicas in production directories. Tools will be needed to detect and to correct these inconsistencies. A special client may accomplish detection through periodic comparisons of replicas. This client would typically read two replicas of the same replication base entry and compare the answers, possibly by BINDing to each of the two replicas to be compared and reading them both. In cases where the directory automatically reroutes some requests (e.g. chaining), mechanisms to force access to a particular replica should be supplied. Alternatively, the server could support a special request to handle this situation. A client would invoke an operation at some server. It would cause that server to extract the contents from some other server it has a replication agreement with and report the differences back to the client as the result Stokes, et al Expires September 2002 [Page 22] Internet-Draft LDAPv3 Replication Requirements March 2002 If an inconsistency is found, it needs to be repaired. To determine the appropriate repair, the administrator will need access to the replication history to figure out how the inconsistency occurred and what the correct repair should be. When a repair is made, it should be restricted to the replica that needs to be fixed; the repair should not cause new replication events to be started. This may require special tools to change the local data store without triggering replication. Requirements AM2, AM4, and AM5 address these needs. B.5. Some Test Cases for Conflict Resolution in Multi-Master Replication Use of multi-master replication inevitably leads to the possibility that incompatible changes will be made simultaneously on different servers. In such cases, conflict resolution algorithms must be applied. As a guiding principle, conflict resolution should avoid surprising the user. One way to do this is to adopt the principle that, to the extent possible, conflict resolution should mimic the situation that would happen if there were a single server where all the requests were handled. While this is a useful guideline, there are some situations where it is impossible to implement. Some of these cases are examined in this section. In particular, there are some cases where data will be "lost" in multi-master replication that would not be lost in a single-server configuration. In the examples below, assume that there are three replicas, A, B, and C. All three replicas are updateable. Changes are made to replicas A and B before replication allows either replica to see the change made on the other. In discussion of the multi-master cases, we assume that the change to A takes precedence using whatever rules are in force for conflict resolution. B.5.1. Create-Create A user creates a new entry with distinguished name DN on A. At the same time, a different user adds an entry with the same distinguished name on B. In the single-server case, one of the create operations would have occurred before the other, and the second request would have failed. Stokes, et al Expires September 2002 [Page 23] Internet-Draft LDAPv3 Replication Requirements March 2002 In the multi-master case, each create was successful on its originating server. The problem is not detected until replication takes place. When a replication request to create a DN that already exists arrives at one of the servers, conflict resolution is invoked. (Note that the two requests can be distinguished even though they have the same DN because every entry has some sort of unique identifier per requirement SC9.) As noted above, in these discussions we assume that the change from replica A has priority based on the conflict resolution algorithm. Whichever change arrives first, requirement MM6 says that the values from replica A must be those in place on all replicas at the end of the replication cycle. Requirement MM5 states that the system cannot quietly ignore the values from replica B. The values from replica B might be logged with some notice to the administrators, or they might be added to the DIT with a machine generated DN (again with notice to the administrators). If they are stored with a machine generated DN, the same DN must be used on all servers in the replica-group (otherwise requirement M3 would be violated). Note that in the case where the entry in question is a container, storage with a machine generated DN provides a place where descendent entries may be stored if any descendents were generated before the replication cycle was completed. In any case, some mechanism must be provided to allow the administrator to reverse the conflict resolution algorithm and force the values originally created on B into place on all replicas if desired. B.5.2. Rename-Rename On replica A, an entry with distinguished name DN1 is renamed to DN. At the same time on replica B, an entry with distinguished name DN2 is renamed to DN. In the single-server case, one rename operation would occur before the other and the second would fail since the target name already exists. In the multi-master case, each rename was successful on its originating server. Assuming that the change on A has priority in the conflict resolution sense, DN will be left with the values from DN1 in all replicas and DN1 will no longer exist in any replica. The question is what happens to DN2 and its original values. Requirement MM5 states that these values must be stored somewhere. They might be logged, they might be left in the DIT as the values of DN2, or they might be left in the DIT as the values of some machine generated DN. Leaving them as the values of DN2 is attractive since it Stokes, et al Expires September 2002 [Page 24] Internet-Draft LDAPv3 Replication Requirements March 2002 is the same as the single-server case, but if a new DN2 has already been created before the replica cycle finishes, there are some very complex cases to resolve. Any of the solutions described in this paragraph would be consistent with requirement MM5. B.5.3. Locking Based on Atomicity of ModifyRequest There is an entry with distinguished name DN that contains attributes X, Y, and Z. The value of X is 1. On replica A, a ModifyRequest is processed which includes modifications to change that value of X from 1 to 0 and to set the value of Y to "USER1". At the same time, replica B processes a ModifyRequest which includes modifications to change the value of X from 1 to 0 and to set the value of Y to "USER2" and the value of Z to 42. The application in this case is using X as a lock and is depending on the atomic nature of ModifyRequests to provide mutual exclusion for lock access. In the single-server case, the two operations would have occurred sequentially. Since a ModifyRequest is atomic, the entire first operation would succeed. The second ModifyRequest would fail, since the value of X would be 0 when it was attempted, and the modification changing X from 1 to 0 would thus fail. The atomicity rule would cause all other modifications in the ModifyRequest to fail as well. In the multi-master case, it is inevitable that at least some of the changes will be reversed despite the use of the lock. Assuming the changes from A have priority per the conflict resolution algorithm, the value of X should be 0 and the value of Y should be "USER1" The interesting question is the value of Z at the end of the replication cycle. If it is 42, the atomicity constraint on the change from B has been violated. But for it to revert to its previous value, grouping information must be retained and it is not clear when that information can be safely discarded. Thus, requirement G6 may be violated. B.5.4. General Principles With multi-master replication there are a number of cases where a user or application will complete a sequence of operations with a server but those actions are later "undone" because someone else completed a conflicting set of operations at another server. To some extent, this can happen in any multi-user system. If a user changes the value of an attribute and later reads it back, intervening operations by another user may have changed the value. In the multi- master case, the problem is worsened, since techniques used to resolve the problem in the single-server case won't work as shown in the examples above. Stokes, et al Expires September 2002 [Page 25] Internet-Draft LDAPv3 Replication Requirements March 2002 The major question here is one of intended use. In LDAP standards work, it has long been said that replication provides "loose consistency" among replicas. At several IETF meetings and on the mailing list, usage examples from finance where locking is required have been declared poor uses for LDAP. Requirement G1 is consistent with this history. But if loose consistency is the goal, the locking example above is an inappropriate use of LDAP, at least in a replicated environment. B.5.5. Avoiding the Problem The examples above discuss some of the most difficult problems that can arise in multi-master replication. While they can be dealt with, dealing with them is difficult and can lead to situations that are quite confusing to the application and to users. The common characteristics of the examples are: - Several directory users/applications are changing the same data. - They are changing the data before previous changes have replicated. - They are using different directory servers to make these changes. - They are changing data that are parts of a distinguished name or they are using ModifyRequest to both read and write a given attribute value in a single atomic request. If any one of these conditions is reversed, the types of problems described above will not occur. There are many useful applications of multi-master directories where at least one of the above conditions does not occur. For cases where all four do occur, application designers should be aware of the possible consequences. B.6. Data Confidentiality and Data Integrity During Replication Directories will frequently hold proprietary information. Policy information, name and address information, and customer lists can be quite proprietary and are likely to be stored in directories. Such data must be protected against intercept or modification during replication. In some cases, the network environment (e.g. a private network) may provide sufficient data confidentiality and integrity for the application. In other cases, the data in the directory may be public and not require protection. For these reasons data confidentiality and integrity were not made requirements for all replication sessions. But there are a substantial number of applications that will need data confidentiality and integrity for replication, so there is a requirement (S4) that the protocol allow for data confidentiality and Stokes, et al Expires September 2002 [Page 26] Internet-Draft LDAPv3 Replication Requirements March 2002 integrity in those cases where they are needed. Typically, the policy on the use of confidentiality and integrity measures would be held in the replication agreement per requirement M7. This leaves the question of what mechanism(s) to use. While this is ultimately a design/implementation decision, replication across different vendors' directory products is an important goal of the LDAP replication work at the IETF. If different vendors choose to support different data confidentiality and integrity mechanisms, the advantages of a standard replication protocol would be lost. Thus there is a requirement (S6) for mandatory-to-implement data confidentiality and integrity mechanisms. Anonymous replication (requirement S3) is supported since it may be useful in the same sorts of situations where data integrity and data confidentiality protection are not needed. B.7. Failover in Single-Master Systems In a single-master system, all modifications must originate at the master. The master is therefore a single point of failure for modifications. This can cause concern when high availability is a requirement for the directory system. One way to reduce the problem is to provide a failover process that converts a slave replica to master when the original master fails. The time required to execute the failover process then becomes a major factor in availability of the system as a whole. Factors that designers and implementors should consider when working on failover include: - If the master replica contains control information or meta-data that is not part of the slave replica(s), this information will have to be inserted into the slave that is being "promoted" to master as part of the failover process. Since the old master is presumably unavailable at this point, it may be difficult to obtain this data. For example, if the master holds the status information of all replicas, but each slave replica only holds its own status information, failover would require that the new master get the status of all existing replicas, presumably from those replicas. Similar issues could arise for replication agreements if the master is the only system that holds a complete set. - If data privacy mechanisms (e.g. encryption) are in use during replication, the new master would need to have the necessary key information to talk to all of the slave replicas. Stokes, et al Expires September 2002 [Page 27] Internet-Draft LDAPv3 Replication Requirements March 2002 - It is not only the new master that needs to be reconfigured. The slaves also need to have their configurations updated so they know where updates should come from and where they should refer modifications. - The failover mechanism should be able to handle a situation where the old master is "broken" but not "dead". The slave replicas should ignore updates from the old master after failover is initiated. - The old master will eventually be repaired and returned to the replica-group. It might join the group as a slave and pick up the changes it has "missed" from the new master, or there might be some mechanism to bring it into sync with the new master and then let it take over as master. Some resynchronization mechanism will be needed. - Availability would be maximized if the whole failover process could be automated (e.g. failover is initiated by an external system when it determines that the original master is not functioning properly). B.8. Including Operational Attributes in Atomic Operations LDAPv3 [RFC2251] declares that some operations are atomic (e.g. all of the modifications in a single ModifyRequest). It also defines several operational attributes that store information about when changes are made to the directory (createTimestamp, etc.) and which ID was responsible for a given change (modifiersName, etc.). Currently, there is no statement in RFC2251 requiring that changes to these operational attributes be atomic with the changes to the data. It is RECOMMENDED that this requirement be added during the revision of RFC2251. In the interim, replication SHOULD treat these operations as though such a requirement were in place. Authors' Addresses Russel F. Weiser Digital Signature Trust Co. 1095 East 2100 South Suite #201 Salt Lake City, Utah 84106 USA E-mail: rweiser@trustdst.com Telephone: +1 801 326 5421 Fax: +1 801 326 5421 Ellen J. Stokes Stokes, et al Expires September 2002 [Page 28] Internet-Draft LDAPv3 Replication Requirements March 2002 Tivoli Systems 9442 Capital of Texas Hwy N Austin, TX 78759 USA E-mail: estokes@tivoli.com Telephone: +1 512 436 9098 Fax: +1 512 436 1190 Ryan D. Moats Lemur Networks 15621 Drexel Circle Omaha, NE 68135 USA E-Mail: rmoats@lemurnetworks.net Telephone: +1 402 894 9456 Richard V. Huber Room C3-3B30 AT&T Laboratories 200 Laurel Avenue South Middletown, NJ 07748 USA E-Mail: rvh@att.com Telephone: +1 732 420 2632 Fax: +1 732 368 1690 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Stokes, et al Expires September 2002 [Page 29] Internet-Draft LDAPv3 Replication Requirements March 2002 This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Stokes, et al Expires September 2002 [Page 30] --------------194DC79164089E66582BCBD2--