From owner-ietf-ldup@mail.imc.org Mon Apr 3 02:51:17 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13928 for ; Mon, 3 Apr 2000 02:51:16 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id XAA06431 for ietf-ldup-bks; Sun, 2 Apr 2000 23:13:34 -0700 (PDT) Received: from iganotes.intelligroup.co.in ([196.12.47.144]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA06426 for ; Sun, 2 Apr 2000 23:13:20 -0700 (PDT) Received: from narry ([10.244.1.37]) by corpnotes.intelligroup.co.in (Lotus Domino Build v50.a_1) with SMTP id 2000040311330374:1868 ; Mon, 3 Apr 2000 11:33:03 +0530 From: "NareshKumar" To: Cc: Date: Mon, 3 Apr 2000 11:37:48 +0530 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-MIMETrack: Itemize by SMTP Server on corpnotes/Intelligroup Asia(Release 5.0a (Intl)|4 May 1999) at 04/03/2000 11:33:03 AM, Serialize by Router on iganotes/Intelligroup Asia(Release 5.0.1b (Intl)|30 September 1999) at 04/03/2000 11:43:20 AM, Serialize complete at 04/03/2000 11:43:20 AM Message-ID: <010e01bf9d32$efd1e860$2501f40a@narry> Content-Type: multipart/alternative; boundary="----=_NextPart_000_010B_01BF9D61.0971BA60" 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_010B_01BF9D61.0971BA60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable subscribe Thanks, With Regards Naresh Kumar Div : EIP Work: 91-40-6517377 Ext : 4501 & 4503 SeraNova. ------=_NextPart_000_010B_01BF9D61.0971BA60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
subscribe

Thanks,
 
With Regards
Naresh = Kumar
Div :=20 EIP
Work: 91-40-6517377
Ext : 4501 &=20 4503
SeraNova.
------=_NextPart_000_010B_01BF9D61.0971BA60-- From owner-ietf-ldup@mail.imc.org Wed Apr 5 22:07:39 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20098 for ; Wed, 5 Apr 2000 22:07:38 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA16911 for ietf-ldup-bks; Wed, 5 Apr 2000 18:38:21 -0700 (PDT) Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA16898 for ; Wed, 5 Apr 2000 18:38:18 -0700 (PDT) Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id LAA15397 for ; Thu, 6 Apr 2000 11:40:52 +1000 (EST) Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpd0hoIeW; Thu Apr 6 11:40:32 2000 Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id LAA12414 for ; Thu, 6 Apr 2000 11:40:31 +1000 (EST) Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpdtu3IB_; Thu Apr 6 11:39:34 2000 Received: from ntmsg0028.corpmail.telstra.com.au (ntmsg0028.corpmail.telstra.com.au [192.168.174.24]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id LAA22725 for ; Thu, 6 Apr 2000 11:39:34 +1000 (EST) Message-Id: <200004060139.LAA22725@mail.cdn.telstra.com.au> Received: by ntmsg0028.corpmail.telstra.com.au with Internet Mail Service (5.5.2650.21) id <2KZQFH30>; Thu, 6 Apr 2000 11:39:07 +1000 From: "Payne, Alison" To: "'ietf list'" Subject: draft-ietf-ldup-model-03.txt : Comments Date: Thu, 6 Apr 2000 11:44:00 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi John, Ed, Uppili, A couple of quick corrections to the document in Section 10.5 (Update Resolution Procedures). - Section 10.5.1 - Both entries have the UID recorded in the RDN, not just the "most recently named". Only naming the second in this way would make the outcome dependent on processing order. - Section 10.5.2 - Suggest the used of "orphaned" in the text rather than abandoned. Abandoned suggests to me that nothing further will be done to these entries, however, they are still actively participating in any replication activities. - Section 10.5.3 - The current draft of URP does not support the semantics described here. The distinguished not present value has been removed from the draft. Section 12.2 of URP describes the semantics. Regards, Alison From owner-ietf-ldup@mail.imc.org Mon Apr 10 06:13:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04281 for ; Mon, 10 Apr 2000 06:13:36 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id CAA06944 for ietf-ldup-bks; Mon, 10 Apr 2000 02:07:04 -0700 (PDT) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA06936 for ; Mon, 10 Apr 2000 02:06:58 -0700 (PDT) Received: from jstrassnlap (sj-dial-4-22.cisco.com [171.68.181.151]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id CAA27401; Mon, 10 Apr 2000 02:09:44 -0700 (PDT) Message-ID: <007c01bfa2cc$a671d7d0$97b544ab@cisco.com> From: "John Strassner" To: Cc: , , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Subject: Draft Minutes for the LDUP WG meeting Date: Sun, 9 Apr 2000 18:56:03 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_06D0_01BFA255.4135ADA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 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_06D0_01BFA255.4135ADA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please review and comment asap. regards, John ------=_NextPart_000_06D0_01BFA255.4135ADA0 Content-Type: text/plain; name="LDUP Meeting Minutes.txt" Content-Disposition: attachment; filename="LDUP Meeting Minutes.txt" Content-Transfer-Encoding: quoted-printable LDUP Meeting Minutes for the 47th Meeting of the IETF Minutes recorded by John Strassner First and most importantly, humble thanks to all working group participants (which was the overwhelming majority) that stayed over 20 minutes late in order to finish our agenda. The agenda was discussed. We inserted one change to the agenda, the discussion of an alternate proposal to the URP draft. This alternative was presented to the group at the start of the meeting, and the agenda was changed to accommodate it due to its potential ramifications if the working group accepts the work. The revised agenda is below (note that all file names should be prefixed with http://www.ietf.org/internet-drafts): 1) Agenda Bashing 2) Brief Discussion of Alternate URP Proposal (This is the new item) 3) General Admonishment for Authors Being Late ;-) 4) LDAP Replication Architecture file: draft-ietf-ldup-model-02.txt 5) LDAP V3 Replication Requirements file: draft-ietf-ldup-replica-req-02.txt 6) LDUP Replication Information Model file: draft-ietf-ldup-infomod-00.txt 7) LDUP Update Reconciliation Procedures file: draft-ietf-ldup-urp-02.txt 8) LDAP Subentry Schema file: draft-ietf-ldup-subentry-01.txt 9) The LDUP Replication Update Protocol file: draft-ietf-ldup-protocol-00.txt 10) Drafts that are Missing In Action: LDAPv3 Mandatory Replica Management I-D=20 LDAPv3 Master-Slave Replication Profile I_D LDAPv3 Multi-Master Replication Profile I-D 11) Discussion of addition of LBURP to the Charter 12) Discussion of addition of LCUP Work to the Charter 1. Discussion of Agenda Items (John Strassner) The agenda was discussed. A new item was added: discussion of a new alternate URP proposal and its effects on the requirements document. The rest of the agenda remained unchanged. 2. Brief Discussion of an alternate URP Proposal (moderated by John) This item came up because the LDUP Replication Requirement Document completed WG last call, and actually should have gone to IETF Last Call. We had decided to put this document to IETF Last Call at the meeting. However, there was one major objection raised by Mr. Langer. He was concerned that the requirements are too open and subject to interpretation in one specific area (atomicity of updates), and that his alternative method for update resolution would therefore be ruled out. It was decided to do the following: - since nothing can be formally considered by the working group until it is in the form of an Internet Draft, we decided to wait one week (till 7 April) to allow Mr. Langer to publish his URP alternate approach as an individual submission - in addition, Mr. Langer should write a brief e-mail that explicitly defines the problem with the requirement doc. Note that this does NOT mean that Mr. Langer has to redo and/or present an alternate requirements draft. Once these two steps have been completed, the working group will discuss the points on the mailing list. We would like to decide by the end of the month at the latest whether to go forward with the existing requirements draft and URP proposal, or to delay these while we adjust the requirements document and then either add Mr. Langer=92s URP document, or to replace our existing document with that of Mr. Langer. 3. General Admonishment ;-) (John) Your co-chairs are concerned that we're showing the signs of starting to die a flailing death. So, if this work is important for your LDAP implementations, please redouble your efforts to move these drafts along. Your co-chairs are here to help and facilitate this. We will be collecting expected times of updating the drafts today, so that we can update our charter. Working groups have, can, and will be killed for lack of activity, so please try and keep these new sets of dates. =20 4) LDAP Replication Architecture (Uppilli) file: draft-ietf-ldup-model-02.txt (Intro from John) This draft completed working group last call. The lone item to fix was a removal of references to other WG deliverables (per joint recommendation of the WG Chairs and the Applications Area Directors). This is because this document, being an architecture document, is supposed to stand on its own and not be held up waiting for other deliverables to clear IESG Review, IETF Last Call, and the RFC Editor. (Uppilli) The current status is that the above changes were made and the document was resubmitted. The authors tried to decouple references, but in their opinion additional work needs to be done to ensure that those documents are tightly coupled to this architecture document. In addition, Helmut pointed out that there are some errors with respect to naming contexts. He also pointed out that since some things operate fundamentally differently in a multi-master environment, this should be pointed out and affect the architecture document. A brief call for input was taken, and other people are willing to add requirements. Plus, the other architecture authors should also contribute. It was decided to solicit general comments up to 24 April, and then reissue this document in mid-May. 5) LDAP V3 Replication Requirements (Ellen) file: draft-ietf-ldup-replica-req-02.txt This document also successfully completed working group last call, but has not yet been sent to an IETF last call. And now, we have an objection from Mr. Langer. The basic problem is that Mr. Langer wants to offer up an alternate replication method, one that is different from URP. He is worried that the replication requirements draft, in its current form, would prohibit his document from being considered. This is because, in his view, the document is ambiguous. The ambiguity lies in the fact that although transactions are beyond the scope of the current work, nothing will be done to add in transactions. In addition, the term atomic update as implemented in a single master means that you were reading just that entry, and that no interleaved operations carried out. The replication requirements document (in its present form) allows interleaving of operations, in anticipation of multi-master operation. Recommendation of the chair and AD: Until an Internet draft is an RFC there is always time to discuss things. However, it is not fruitful to discuss anything until a formal counter-proposal, in the form of an Internet Draft, is submitted (as an individual submission) for consideration by the working group. Thus, it is incumbent on Mr. Langer to produce such an Internet Draft. Once this new draft is submitted, the working group will consider it. The first order of business is for the replication requirements team and authors to respond on the mail list, and then for the working group to consider whether Mr. Langer=92s concerns are justified. If they are, then the requirements draft will have to be modified to take this into account, and another working group last call issued. If not, then the requirements draft will go to IETF last call either as is, or with a small editorial modification that further clarifies the requirements draft in response to Mr. Langer=92s objections. The working group will make a decision by Easter. Note that this is independent of the URP decision. 6) LDUP Replication Information Model (Ed) file: draft-ietf-ldup-infomod-00.txt (Chair intro): This was supposed to go through WG Last Call a while ago. However, it is doubtful that it is ready to go in its current form. (Ed): The Engineering Team met and is simplifying this draft even more. The UUID spec was a dangling reference, but the working group decided (thanks Harald for chipping in here) that we can use the UUID ISO spec. The reference for this spec is: http://www.opengroup.org/onlinepubs/009629399/apdxa.htm=20 Ed notes that the process of trying to describe scheduled policy is really hard. We can start to do this by perhaps defining a cron-like process with hysteriesis. However, it isn=92t clear that this is suitable for all applications. In fact, the Engineering Team is favoring leaving this undefined. If we do this, then there are two classes and a lot of attributes that don=92t need to be specified in this document. The current proposal is to define a (may) DN attribute that may point to a scheduler class. When absent, the default is to send the replication immediately. In Washington, we decided to eliminate ldapAccessPoint in favor of replicaURI. We moved the replicaID translation table to the protocol spec. This is one of the things that we need to ensure is updated in all of the appropriate draft. The current draft is defined so that the replication agreement subentries use name subordination to define whose replica this is. This brought up a discussion on which naming attributes to use. Here is a summary: Mark notes that some vendors have objected to using cn for naming ldapSubEntry entries in the directory. The primary objection is that these entries are not normally visible to users and administrators. Thus, you get the rather ugly problem that naming clashes with other entries named by cn will occur, and the administrator or user won=92t have a clue as to why this is happening.=20 In addition, many ldapSubEntry entries will be created automatically by software. If this is to succeed, then we must guarantee that name clashes are avoided. The group defined the following possible solutions: 1) define a new attribute (name TBD) of type DirectoryString, for exclusive use of naming ldapSubEntry entries 2) leave supplying of the naming attribute to developers who use an ldapSubEntry class to hold their information, but this seems to have problems because the ldapSubEntry class is a structural class and therefore probably requires a specific naming rule that will end up interfering with user definitions 3) punt, and leave it the way X.500 defines it, and leave experiments surrounding solving this problem to future innovators. 4) keep cn as the naming attribute but recommend a specific convention for naming subentries that makes a name clash unlikely. A brief summary of the opinions of the group is: 1) Option 1 moves this farther away from the X.500 definition, which is OK if that is really what we want to do. However, it doesn=92t seem that we should change just for the sake of changing. So if someone really wants this option, it is incumbent on them to come up with a compelling reason (last sentence from Editor). 2) Option 2 seems an even further departure from X.500, and seems to be recommending that ldapSubEntry be an AUXILIARY, not a STRUCTURAL, class. 3) Option 3 seems to be a safe decision. If people can=92t come up with compelling scenarios, then there is no need to change. 4) This option seems next most feasible, though there is some concern as to how the naming convention can be specified so as to always avoid collisions. 7) LDUP Update Reconciliation Procedures (Steven) file: draft-ietf-ldup-urp-02.txt This draft did seem ready for last call, but now we may need to reconsider it given Mr. Langer=92s alternate proposal. The authors are looking at making a future revision to accommodate the updating of partial replicas. Steven and Alison point out that the main difference between URP and other approaches is whether conflicts are merged or resolved immediately. Steven and Alison also note that this subject keeps coming up. Therefore, Steven and Alison have volunteered to write up a new document that describes why URP ended up the way it did. The working group members that that this was a good idea, and Patrick OKed it. Chairs to revise the charter and send to list. 8 LDAP Subentry Schema (Ed) file: draft-ietf-ldup-subentry-01.txt This document is ready for last call, but LDAPEXT wants additional information and guidance stating that auxiliary classes should be used wherever possible instead of structural classes (editor=92s note: remember that this document is going through a joint last call between the LDUP and LDAPEXT working groups). When that is revised, this doc should be ready for last call. However, the naming problem discussed above rears its ugly head here too. So if we change the naming convention, then we need to update this document. So at the very least we need some weasel words to allow this. Conclusion: this last issue needs to be taken to the list. Ed to write mail message, everyone please respond and help, else we will use X.500=92s definition. Target date for new publication: end of May 9) The LDUP Replication Update Protocol file: draft-ietf-ldup-protocol-00.txt and file: draft-ietf-ldup-framing-00.txt The main change since the last issue of this draft is to split the ldup-protocol-00.txt draft into 2 drafts: Ldup-protocol-01.txt and ldup-framing-00.txt The framing draft defines four framing operations: start framed protocol request and response, and end framed protocol request and response. This is intended to group together a set of related operations. For example, in URP, there would be a series of URP actions. Note that a session is defined as Start framed protocol request contains a protocol OID and a protocol-specific payload. LBURP, for example, specifies this protocol OID and specifies the payload format. Framing does not address push or pull models that are a function of the protocol implementation.=20 Open questions: - Does protocol-01.txt enumerate all necessary error conditions (probably not) - Anything else? (replica ID translation table,=20 advertisement) A general question was raised as to why the framing document is necessary (i.e., why not just use an extended response)? The concern is that you might need more semantics than just a Start doing something, and then tell me when you=92re done. Also, there is concern that since we only have 2 customers, we might not get it right. Conclusion: take this to the list. Discussion period should go no later than middle of May. Then, we need a damage assessment, and to decide if we merge the drafts back into one, or keep them separate. 10) Drafts that are missing in action=20 10a) LDAPv3 Mandatory Replica Management I-D (Mark) The LDAPv3 Mandatory Replica Management I-D is being turned over to Ed Reed because Mark has negative cycles ;-) . Ed's target date for revising this document is the end of June (to ensure time to finish the other important work that he is already committed to). 10b) LDAPv3 Master-Slave Replication Profile I-D (Uppilli/Ed) These documents will be combined into one, with Uppilli taking the lead. Solicited and received help to fill out some of the sections. New time frame is the end of June to release this document. 10c) LDAPv3 Multi-Master Replication Profile I-D (Uppilli/Ed) This draft has stagnated somewhat because it is still unclear how applications will make use of this information. The original motivation of this draft was to be able to answer questions on configuration, and guide the implementor in making decisions that support the configuration of the directory server to single or multi-master replication. After some discussion, we decided that this should be tied closely to the requirements document, and to have use cases drive their functionality. Also, we should talk about who should use single- vs. multi-master replication, and how the inherent differences between these two modes affect the applications that use them. Uppilli needs more input as to what type of applications would use this and how this could break an application. Alison will help, as will the co-chairs. Purpose: see what types of operations are different between single- and multi-master. This will be written as one document, not two. Time frame: end of June. 11) Discuss LBURP (Roger) The latest version of this draft include using the LDUP Framing draft, removing LDUPisms (e.g. replica update vectors), adding sequencing (to help implementation we need to determine which updates were sent in what order), and adding grouping of updates (for better wire efficiency, especially on responses) Remaining questions: Need to tighten error handling procedures (what happens if an error occurs in the middle of a set of operations). Also need to consider how much parallelism is desired between LDUP and LBURP. Should this be added as a WG item? Unclear right now. Roger to revise it again and we will ask again on or before the next IETF meeting. 12) Discuss addition of LCUP to charter (Olga) The purpose of LCUP is to synchronize LDAP clients with content stored by LDAP servers. As such, there are three main problem areas that are addressed: (1) mobile clients that maintain local data caches, (2) meta-directory applications, and (3) event triggers (both triggered as well as persistent search). Problem areas that are not addressed include server to server synchronization (addressed by LDUP). LCUP combines features of DirSync, Persistent search and Triggered search. Its motivation is that the ideal solution needs parts of each of these solutions. So, LCUP is intended to replace persistent and triggered search. DirSync has a number of desirable features that are included in LCUP for convenience sake, but LCUP does not have all of the functionality of DirSync. The protocol supports one-way synchronization only. Server does not maintain any state info on behalf of the clients. Clients maintain the state information passed to them by the server in=20 a cookie. A key point is that LCUP does not support pre-defined agreements. Rather, it is up to the client to decide from which server and when to get the information. Thus, the client always initiates the synchronization session, and the client is always responsible for pulling data from the server that it selects. The specific protocol elements proposed include four extended operations: a client update control, an entry update control, a client update done control, and a stop client update.=20 There are three basic ways of using LCUP: event triggering, non-persistent, and persistent synchronization. Please see the draft for more specific information. There are a number of features under discussion. These are features that have been proposed in one or more of the persistent search, triggered search, and dirSync proposals, but which are not currently implemented in LCUP. The reason is that each of these are very difficult to implement, and so we are trying to avoid implementing these unless there is an important need for these. They are as follows: Persistent search defines a change type. This is defined in persistent search. It defines a reason for return to each entry sent to the client. Hard to implement for historical reasons. Sending changes: present in DirSync; only modified attributes (as opposed to all attributes) are sent. Size limit: present in DirSync; specifying amount of data that can be sent to the client. LCUP prefers to use a standard LDAP mechanism instead. Data ordering: present in DirSync; guarantees that parent is sent before child for adds and vice-versa for deletes. Very hard to implement, may not catch all problems (e.g., DN pointers). LCUP is scoped by a single LDUP replica.=20 One thing that needs better definition is access control (e.g., if access control changes, how does that affect the client?). Note that a number of items are currently unspecified, such as: - Access control enforcement on the data - How to restrict the use of the protocol to trusted clients - Mechanism to identify and disconnect malicious clients - Server behavior is not specified for the case where data visibility changes due to access control changes - Proper behavior is not guaranteed if access control on the data is changed from a more restrictive to a less restrictive one Disposition? Mark would like to see this be done in LDUP, but is willing to accept it as a formal work item if this working group doesn=92t want to accept it. Poll of the room showed overwhelming majority in favor of accepting this. Chairs to describe this work in new charter, which is to be discussed in the list. ------=_NextPart_000_06D0_01BFA255.4135ADA0-- From owner-ietf-ldup@mail.imc.org Mon Apr 10 07:34:51 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05597 for ; Mon, 10 Apr 2000 07:34:51 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id EAA12119 for ietf-ldup-bks; Mon, 10 Apr 2000 04:00:31 -0700 (PDT) Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA12113 for ; Mon, 10 Apr 2000 04:00:29 -0700 (PDT) Received: from langfjella.Alvestrand.no (langfjella.maxware.no [10.128.1.46]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id NAA02450; Mon, 10 Apr 2000 13:03:44 +0200 Message-Id: <4.3.1.2.20000410125735.107f57f0@dokka.kvatro.no> X-Sender: hta@dokka.maxware.no X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 10 Apr 2000 13:02:54 +0200 To: "John Strassner" , From: Harald Tveit Alvestrand Subject: Re: Draft Minutes for the LDUP WG meeting Cc: , , Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , In-Reply-To: <007c01bfa2cc$a671d7d0$97b544ab@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 18:56 09.04.2000 -0700, John Strassner wrote: >Please review and comment asap. One note, which is to substance, not to minutes (which seem fine): >Ed notes that the process of trying to describe scheduled >policy is really hard. We can start to do this by perhaps >defining a cron-like process with hysteriesis. However, it >isn't clear that this is suitable for all applications. In >fact, the Engineering Team is favoring leaving this >undefined. OTOH, a specification that allows repeating events, but with no way to specify their repetition, is incomplete. Incomplete specs are bad, because we then guarantee noninteroperability. I suggest stealing a repetition definition from CALSCH, if necessary limiting it to something easy to implement. (Didn't CALSCH have a draft on how to represent appointments in LDAP entries?) If necessary, steal it from the man page of cron(1). Harald Harald -- Harald Tveit Alvestrand, EDB Maxware, Norway Harald.Alvestrand@edb.maxware.no From owner-ietf-ldup@mail.imc.org Mon Apr 10 11:18:20 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17091 for ; Mon, 10 Apr 2000 11:18:19 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA15291 for ietf-ldup-bks; Mon, 10 Apr 2000 07:46:44 -0700 (PDT) Received: from etrn.xmission.com (root@etrn.xmission.com [198.60.22.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15287 for ; Mon, 10 Apr 2000 07:46:43 -0700 (PDT) Received: from [166.70.104.61] (helo=mail.oncalldba.com) by etrn.xmission.com with smtp (Exim 2.12 #1) id 12efVp-0004TH-00 for ietf-ldup@imc.org; Mon, 10 Apr 2000 08:50:01 -0600 Received: from RMINC_DOM-Message_Server by mail.oncalldba.com with Novell_GroupWise; Mon, 10 Apr 2000 08:48:47 -0600 Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Mon, 10 Apr 2000 08:48:05 -0600 From: "Ed Reed" To: , , Cc: , , , Subject: Re: Draft Minutes for the LDUP WG meeting 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 ns.secondary.com id HAA15288 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit It's actually the cron(1) directory schema I was hoping to avoid, or at least to punt towards a separate document. The rationale is this... 1) replicationAgreements may be scheduled in any number of different ways; 2) replicas who initiate replication sessions need to know how to interpret the schedule policy elements which govern their session initiaion behavior - others do not need to interpret such data, though it would be usefule for management purposes for others to set or read such policy information, it's not necessary for LDUP 3) schedule policy information may take many different forms, and each be represented in many ways - defining just one seems too limiting, and if there are more than one, each should be in it's own document. So - that's what's going through my head. On the one hand, this is an easy place to reduce scope of the LDUP schema document - refer to schema policy information entries whose schema is defined elsewhere. On the other hand, is there some real interoperability issue? It doesn't "feel" like it to me - ftp doesn't have an interoperability problem because the schedule by which file transfers are initiated can't be inspected or set via ftp protocols. Why then replication? Thus, my proposal: scheduling policy information MAY be described in published schema and be referenced by replicationAgreementSubentries governed by entries (or groups of entries) using such schema descriptions, but such schema descriptions are outside the scope of LDUP, and will generally be implementation specific until concensus develops on what constitutes good schema design for them. It's a stretch, I know - I'd like to have a couple of schedule policy information schemes defined to encourage their use...but again, to have them defined outside the infomod document itself. Ed ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.OnCallDBA.COM >>> Harald Tveit Alvestrand 04/10/00 05:02AM >>> At 18:56 09.04.2000 -0700, John Strassner wrote: >Please review and comment asap. One note, which is to substance, not to minutes (which seem fine): >Ed notes that the process of trying to describe scheduled >policy is really hard. We can start to do this by perhaps >defining a cron-like process with hysteriesis. However, it >isn't clear that this is suitable for all applications. In >fact, the Engineering Team is favoring leaving this >undefined. OTOH, a specification that allows repeating events, but with no way to specify their repetition, is incomplete. Incomplete specs are bad, because we then guarantee noninteroperability. I suggest stealing a repetition definition from CALSCH, if necessary limiting it to something easy to implement. (Didn't CALSCH have a draft on how to represent appointments in LDAP entries?) If necessary, steal it from the man page of cron(1). Harald Harald -- Harald Tveit Alvestrand, EDB Maxware, Norway Harald.Alvestrand@edb.maxware.no From owner-ietf-ldup@mail.imc.org Mon Apr 10 14:21:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28873 for ; Mon, 10 Apr 2000 14:21:01 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA18854 for ietf-ldup-bks; Mon, 10 Apr 2000 10:36:12 -0700 (PDT) Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA18850 for ; Mon, 10 Apr 2000 10:36:10 -0700 (PDT) Received: from langfjella.Alvestrand.no ([10.128.167.143]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id TAA06145; Mon, 10 Apr 2000 19:38:32 +0200 Message-Id: <4.3.1.2.20000410193217.0920d630@dokka.kvatro.no> X-Sender: hta@dokka.maxware.no X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 10 Apr 2000 19:34:44 +0200 To: "Ed Reed" , , From: Harald Tveit Alvestrand Subject: Re: Draft Minutes for the LDUP WG meeting Cc: , , , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 08:48 10.04.2000 -0600, Ed Reed wrote: >On the other hand, is there some real interoperability issue? It doesn't >"feel" like >it to me - ftp doesn't have an interoperability problem because the >schedule by >which file transfers are initiated can't be inspected or set via ftp >protocols. Why >then replication? Because replication is trying to define consistency between LDAP servers. FTP got into a lot of trouble as a basis for mirroring arrangements because they did not determine the syntax of a date. If you don't provide at least one format of a schedule, you say that a client from one vendor has no standard way to define a schedule for a product from another vendor. And that means that it has no way of controlling the consistency between the servers involved. That's bad. Harald -- Harald Tveit Alvestrand, EDB Maxware, Norway Harald.Alvestrand@edb.maxware.no From owner-ietf-ldup@mail.imc.org Tue Apr 11 16:03:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19108 for ; Tue, 11 Apr 2000 16:03:08 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA25298 for ietf-ldup-bks; Tue, 11 Apr 2000 12:28:56 -0700 (PDT) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA25292 for ; Tue, 11 Apr 2000 12:28:50 -0700 (PDT) Received: from jstrassnlap (sj-dial-3-64.cisco.com [171.68.180.65]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id MAA00510; Tue, 11 Apr 2000 12:31:48 -0700 (PDT) Message-ID: <028501bfa3ec$b7c00f90$41b444ab@cisco.com> From: "John Strassner" To: Cc: , , =?Windows-1252?Q?Patrik_F=E4ltstr=F6m?= Subject: Fw: I-D ACTION:draft-langer-ldup-mdcr-00.txt Date: Tue, 11 Apr 2000 12:32:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit LDUPers, as mentioned in the draft minutes from our latest meeting in Adelaide, here is the announcement of Albert's draft. Please do read this as soon as possible (but not before you send comments on the minutes ;-) ) and let's start discussing this on this list. Remember, the goal is to reach a consensus as to what actions to take by the end of this month (that would be April, by the way ;-) ). The questions on the floor that this draft addresses are: 1) is the requirements document as currently written too vague? That is, should we delay sending it to IETF last call? Please read sections 1 and 3 of this draft to answer this question. 2) should we add this draft as another possible conflict resolution method, or should we replace URP with this draft, or should URP stay as the only method of conflict resolution. regards, John ----- Original Message ----- From: To: Sent: Tuesday, April 11, 2000 3:52 AM Subject: I-D ACTION:draft-langer-ldup-mdcr-00.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : LDUP Multiple Draft Conflict Resolution (MDCR) > Author(s) : A. Langer > Filename : draft-langer-ldup-mdcr-00.txt > Pages : 19 > Date : 10-Apr-00 > > Concurrent changes in a Multi-Master directory are a partially > ordered tree. 'LDUP Update Reconciliation Procedures' (URP) uses > timestamps to impose a strict linear order on this tree, and merges > changes to fit that imposed order. Merged changes violate the > semantics of the LDAP/X.500 data model. No specific 'modifierName' > can be assigned to a merged change and requirements to support audit > trails and access controls and not to break applications or impede > future work on transactions cannot be met. The current LDUP > requirements draft avoids dealing with these critical issues. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-langer-ldup-mdcr-0 0.txt > > 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-langer-ldup-mdcr-00.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-langer-ldup-mdcr-00.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. > From owner-ietf-ldup@mail.imc.org Wed Apr 12 10:41:59 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22713 for ; Wed, 12 Apr 2000 10:41:58 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA07116 for ietf-ldup-bks; Wed, 12 Apr 2000 07:00:08 -0700 (PDT) Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA07112 for ; Wed, 12 Apr 2000 07:00:06 -0700 (PDT) Received: from qsun.mt.att.com ([135.16.12.1]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with SMTP id KAA14844 for ; Wed, 12 Apr 2000 10:03:05 -0400 (EDT) Received: from schooner by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id KAA20027; Wed, 12 Apr 2000 10:03:01 -0400 From: "Ryan Moats" To: Subject: RE: I-D ACTION:draft-langer-ldup-mdcr-00.txt Date: Wed, 12 Apr 2000 09:03:10 -0500 Message-ID: <001e01bfa487$d62a4d60$e3c8090a@schooner.local.windrose.omaha.ne.us> 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 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 In-Reply-To: <028501bfa3ec$b7c00f90$41b444ab@cisco.com> Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Well, since nobody has said anything yet, I'll take the plunge: I've read the MDCR draft, and the introduction discusses various attributes being broken by URP. Now, the only way that I can see these problems occurring is if URP does not maintain atomicity of LDAP operations across replications. I thought it did, but I'll admit that a quick glance at the URP draft didn't turn up "chapter and verse". If somebody can quote the portion of the URP draft that shows that atomicity is maintained, please do. Otherwise, the URP draft needs to be edited to make this concept explicit. Once we've shown that URP maintains atomicity of LDAP changes, I really don't see what else the MDCR draft is looking for... Ryan Moats | LDUPers, | | as mentioned in the draft minutes from our latest meeting in | Adelaide, here is the announcement of Albert's draft. Please | do read this as soon as possible (but not before you send | comments on the minutes ;-) ) and let's start discussing | this on this list. Remember, the goal is to reach a | consensus as to what actions to take by the end of this | month (that would be April, by the way ;-) ). | | The questions on the floor that this draft addresses are: | | 1) is the requirements document as currently written | too vague? That is, should we delay sending it to | IETF last call? Please read sections 1 and 3 of | this draft to answer this question. | 2) should we add this draft as another possible | conflict resolution method, or should we replace | URP with this draft, or should URP stay as the | only method of conflict resolution. | | regards, | John From owner-ietf-ldup@mail.imc.org Wed Apr 12 18:40:58 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04801 for ; Wed, 12 Apr 2000 18:40:57 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA20747 for ietf-ldup-bks; Wed, 12 Apr 2000 15:01:19 -0700 (PDT) Received: from etrn.xmission.com (root@etrn.xmission.com [198.60.22.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA20743 for ; Wed, 12 Apr 2000 15:01:18 -0700 (PDT) Received: from [166.70.104.61] (helo=mail.oncalldba.com) by etrn.xmission.com with smtp (Exim 2.12 #1) id 12fVFp-0006Ru-00 for ietf-ldup@imc.org; Wed, 12 Apr 2000 16:04:57 -0600 Received: from RMINC_DOM-Message_Server by mail.oncalldba.com with Novell_GroupWise; Wed, 12 Apr 2000 16:03:38 -0600 Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Wed, 12 Apr 2000 16:03:22 -0600 From: "Ed Reed" To: , Cc: , , , Subject: Re: Draft Minutes for the LDUP WG meeting - UUID 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 ns.secondary.com id PAA20744 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Harald - I've tracked down the ISO/IEC 11578:1996 spec, available from ANSI in the USA over the web for a mere $280. I'm not amused. You indicated I need to suck it up and buy the spec so we can verify the reference we'll be making to it. Honestly, I'd rather refer to the OpenGroup document, published online without charge to the reader, instead. Puullleeezzzz? Ed ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.OnCallDBA.COM >>> "John Strassner" 04/09/00 07:56PM >>> Please review and comment asap. regards, John From owner-ietf-ldup@mail.imc.org Thu Apr 13 05:22:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25169 for ; Thu, 13 Apr 2000 05:22:12 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA06073 for ietf-ldup-bks; Thu, 13 Apr 2000 01:44:42 -0700 (PDT) Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA06069 for ; Thu, 13 Apr 2000 01:44:39 -0700 (PDT) Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id SAA25262; Thu, 13 Apr 2000 18:47:46 +1000 (EST) Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpd0dS20O; Thu Apr 13 18:47:30 2000 Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id SAA04937; Thu, 13 Apr 2000 18:47:29 +1000 (EST) Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpdOSZSm_; Thu Apr 13 18:47:02 2000 Received: from ntmsg0028.corpmail.telstra.com.au (ntmsg0028.corpmail.telstra.com.au [192.168.174.24]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id SAA15284; Thu, 13 Apr 2000 18:47:01 +1000 (EST) Received: by ntmsg0028.corpmail.telstra.com.au with Internet Mail Service (5.5.2650.21) id <2PA159Z3>; Thu, 13 Apr 2000 18:46:33 +1000 Message-ID: <231DAA6464F5D311B0A30008C7F9073548EB6E@NTMSG0134> From: "Payne, Alison" To: "'John Strassner'" , ietf-ldup@imc.org Cc: johns@cisco.com, capple@att.com, Patrik Faltstrom Subject: RE: I-D ACTION:draft-langer-ldup-mdcr-00.txt Date: Thu, 13 Apr 2000 18:38:35 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi John, Some thoughts on your questions. > 1) is the requirements document as currently written > too vague? That is, should we delay sending it to > IETF last call? Please read sections 1 and 3 of > this draft to answer this question. Is it possible to state as a requirement that it is undesirable to have the following happen? : - update is accepted at DSA 1, - administrator leaves terminal thinking that update has occurred, - conflict later detected at DSA x and update is "rolled back" (i.e. return to the previous state) - administrator comes back and notices that entry is back to the state prior to the update done some time ago. The other issue with the requirements is whether reducing the complexity of implementation is important. We have made some hard choices about consistency in the interests of getting a workable solution. > 2) should we add this draft as another possible > conflict resolution method, or should we replace > URP with this draft, or should URP stay as the > only method of conflict resolution. A couple of quick comments about the alternative to URP : - We went part of the way along this track but attempted to reduce the detected conflicts to conflicts which really occur. This becomes quite a complex exercise of comparison between operations/states requiring additional information to be stored to be able to track what has happened and resolve it consistently. Albert has chosen to make the conflict detection fairly simple - as I understand it, any two operations which occur on the same entry without knowledge of each other conflict and one won't take effect. Again, its a trade off. - I think that the proposed mechanism doesn't propose a solution to some of the conflicts on parent nodes etc so we would still need to use URP for them. How do we integrate the two if Albert's proposal takes over only the entry attribute conflicts? Cheers, Alison From owner-ietf-ldup@mail.imc.org Thu Apr 13 06:36:22 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25846 for ; Thu, 13 Apr 2000 06:36:20 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id CAA06940 for ietf-ldup-bks; Thu, 13 Apr 2000 02:05:23 -0700 (PDT) Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA06924 for ; Thu, 13 Apr 2000 02:05:17 -0700 (PDT) Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id TAA03010; Thu, 13 Apr 2000 19:07:54 +1000 (EST) Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpdf0ZbZ_; Thu Apr 13 19:07:46 2000 Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id TAA15456; Thu, 13 Apr 2000 19:07:44 +1000 (EST) Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpd0XP_6H; Thu Apr 13 19:07:25 2000 Received: from ntmsg0028.corpmail.telstra.com.au (ntmsg0028.corpmail.telstra.com.au [192.168.174.24]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id TAA23105; Thu, 13 Apr 2000 19:07:24 +1000 (EST) Received: by ntmsg0028.corpmail.telstra.com.au with Internet Mail Service (5.5.2650.21) id <2PA1502W>; Thu, 13 Apr 2000 19:06:57 +1000 Message-ID: <231DAA6464F5D311B0A30008C7F9073548EB70@NTMSG0134> From: "Payne, Alison" To: "'Srinivasan, Uppili'" Cc: ietf-ldup@imc.org Subject: Contribution to Profiles Document (Consistency Discussion) Date: Thu, 13 Apr 2000 19:06:53 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BFA527.9D83B3E8" 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_000_01BFA527.9D83B3E8 Content-Type: text/plain; charset="iso-8859-1" Uppili & LDUP, Attached please find the promised contribution to the profiles document. It discusses the consistency offered by URP in some detail and in the various deployment configurations which may be used. Cheers, Alison ------_=_NextPart_000_01BFA527.9D83B3E8 Content-Type: text/plain; name="ldupprof.txt" Content-Disposition: attachment; filename="ldupprof.txt" Content-Transfer-Encoding: quoted-printable LDUP Profiles Contribution from Alison Payne 13/04/2000 1 Introduction The original "profiles" document was intended to define the subset of = features which could be implemented if a vendor wished to provide = either single master or multimaster replication. This aim does not = make sense in the framework of the current replication specification = since no such subset can be easily separated for either form of = replication. Since it is not possible for vendors to reduce the replication offering = they provide, this document changes the intent of the profiles document = from that stated above. This document now details deployment = considerations. The focus is currently on the consistency implications = of deploying either single master or multimaster directories, but may = broaden. The document begins by detailing the "givens" in current non-replicated = LDAP deployments. Following this, a brief overview of the fundamentals = of Multimaster replication are given, including the potential changes = in consistency due to fully operational multimaster replication. = Finally, various deployment strategies and their implications on = consistency are discussed. 2. Fundamentals of a Non-replicated LDAP Directory The consistency maintained by a non-replicated LDAP Directory can be = described as follows : * Serialised Operations (SO) : The DIT state can be reconstructed by = applying every operation which has occurred in the directory up until = this point in time in sequence. That is, the state of a particular = entry reflects a sequence of operations on that entry. It should be noted that there is no possibility within the LDAP = Directory Information Model to specify specific constraints over = directory state : * between entries. That is, operations on different entries cannot be = formed into transactions. For example, it is not possible to ensure = transfers between bank accounts occur atomically. * between attributes of a single entry. That is, it is not possible to = require that operations on a particular entry always maintain = particular internal relationships between attributes in that entry. = For example, that pay is always 2*age/hour. =20 * between states of an entry. That is, operations on the same entry = cannot be formed into transactions. For example, an operation on a = counter style attribute cannot assume that another operation has not = separately incremented the same counter without its knowledge. If an application is currently operating in a single application = environment, it is possible that it has assumed all of the above, and = it is performing transaction processing and maintaining inherent or = explicit constraints. If an application is currently operating in a multi-application = environment , then particular transaction processing and constraints = may have been negotiated between all applications, and the each of the = applications are explicitly maintaining transaction processing and = constraints. If an application is currently operating in a multi-applicaiton = environment but has not negotiated common transaction processing and = constraint handling with other applications, then it is only luck if = any of the required transaction processing and constraints are being = maintained. 3. Fundamentals of a Multimaster LDAP Directory A multimaster LDAP directory provides quite a different environment to = a single LDAP directory. Some of the major differences are as follows = : * DSAs owned and operated by different authorities, * Wide range of application requirements, * Variable service level guarantees for individual DSAs, * Variable communications quality and delays, * Connection between DSAs via replication agreements, and often = "informal" arrangements between individual DSAs via third party = replication agreements. These differences mean that a group of DSAs who cooperate on a common = multimastered replication area cannot be assumed to have reliable = availability or communications links. The fundamental approach is as = follows : 1. Operations are allowed to go ahead on a particular DSA if no = internal LDAP constraints are broken. 2. Operation results (i.e. the change of state caused by the = operation) are expressed as a series of state changes (primitives). 3. These primitives are exchanged between DSAs who cooperate under = replication agreements. These replication agreements may have onchange = or periodic scheduling of the exchange of primitives. 4. When a DSA receives the primitives, it applies the requested state = changes to its own DIT. The application of the requested state changes must follow particular = processing rules (the URP algorithms) to ensure that a common result is = achieved at all DSAs which receive the state change. The basic = approach followed is * Latest Known Wins (LKW) as described in Section 3.1. In some cases, the blind application of the requested state change may = cause a "constraint violation" to occur. For example, an entry might = be orphaned. Standard "constraint violation" handling is applied = which creates occasional=20 * Extraordinary States (ES) as described in Section 3.2. Both of the above mechanisms can create directory states which are not = the result of a serialisable set of atomically applied operations. The = impact of this is quantifiable as described in Sections 3.1 and 3.2. = Possible mechanisms to reduce the occurrence of these states are also = discussed in these sections. Additionally, particular deployment choices (e.g. single master/multi = master) can reduce or remove the possibility of these states occurring. = These are discussed in Section 4. 3.1 Latest Known Wins Consistency The "Latest Known Wins" approach has the outcome that all attributes = will "eventually" reach the latest value entered into the system. = During the "eventuality" being reached, intermediate states reflecting = a combination of states which have existed over time may be held by an = individual DSA. These intermediate states are best described using an = example. Two operations, T1 at time 1 and T2 at time 2, occur on an = entry updating attributes A and B. This may be viewed as follows : T0 T1 T2 A0 A1 A2 B0 B1 B2 "Latest Known Wins" consistency has the semantics that all directories = will eventually have the state A2, B2 (providing no further operations = in the distributed system affect attributes A and B). However, at = times between either update occurring and this "eventuality", the = directory state may be any combination of the individual states of A = and B depending on the primitives currently received and processed by = each=20 DSA. That is, any of the following states may exist : * A0, B0 (Neither Operation has yet occurred) * A0, B1 (Partial completion of Operation 1) * A0, B2 (Partial completion of Operation 2) * A1, B0 (Partial completion of Operation 1) * A1, B1 (Operation 1 has occurred) * A1, B2 (Operation 1 completed, Partial completion of Operation 2) * A2, B0 (Partial completion of Operation 2) * A2, B1 (Operation 1 completed, Partial completion of Operation 2) * A2, B2 (Operation 2 has occurred) The length of time for "eventuality" to be reached is dependent on * replication agreement structure, (e.g. does the overall topology = supported by all relevant replication agreements allow ease of = communication between all DSAs?)=20 * scheduling policies, (e.g. are changes made onchange, or via periodic = policies (e.g. one per day?)) * DSA reliability, (e.g. are any DSAs bottlenecks in the transition of = updates from one network area to another?) * communications links reliability. (e.g. are any DSAs separated from = the remainder of the DSAs through slow or unreliable communications = links?) Additionally, the above also influences the number and duration of = these intermediate states occupied by a DSA. It is possible within a small community of reliable DSAs with reliable = communications links to greatly minimise the period of time spent in = these intermediate states. 3.2 Extraordinary States The second implication of the multimaster replication approach is the = creation of "extraordinary states" during the resolution of requested = state changes with the current DIT structure. These states result from = corrective actions taken by the replica to maintain the DIT = constraints. These extraordinary states include the following : * Lost and Found : An entry which is found to have a naming anomoly may = be placed under the Lost and Found node. For example, an entry which = no longer has a parent will have a glue entry as the parent which in = turn has a parent of the lost and found node. * Conflicting Siblings : An entry which is found to "share" a name with = a fellow sibling has its UID appended to its Relative Distinguished = Name. Additionally, the sibling with the conflicting name has the same = occur. * Implicit Name Changes: An entry which has had a recent change of name = may be impacted by other DSAs which were unaware of the name change. = The eventual name of the entry will reflect all of the actions in this = time (including attribute removes on naming attributes). It is = possible that an entry is left with an empty name. In this case, an = entry is given its UID as an RDN. The window of time during which these constraint violations can occur = causing the extraordinary states is mainly due to replication = agreements, scheduling policies, DSA and communications link = reliability. It is again possible for a small community of DSAs to = greatly minimise the probability of these problems occuring through = care in deployment. Additionally, these constraint violations may arise temporarily (?) due = to the processing of primitives in an order other than that which = occurred at the originating DSA. =20 * Transient Extraordinary States (TES), extraordinary states due to = reordering rather than real world consistency violations. While in most circumstances, vendor implementations will maintain the = original ordering and therefore minimise the chances of this occurring, = the algorithms provide the flexibility to cope with misorderings at the = slightly increased risk of temporary constraint violations. Administration interfaces accessing the directory will need to be able = to detect that such an extraordinary state has been created and allow = the administrator to fix the problem. 3.3 Using Weighted Voting in the Negotiation Phase The algorithms developed to date have assumed that NO COMMUNICATION can = occur between masters at the time of accepting an operation at a DSA. = It is possible that small communities of DSAs may be able to have = reliable communications links and high negotiated service levels. For this specific community, a more suitable intermediate form of = multimaster replication may be able to be developed within the current = multimaster framework. The approach would allow a negotiation phase = during which entries are locked at a subset of participating masters = (i.e. normal weighted voting decision), and then unlocked at the = conclusion of the operation occurring at the originating DSA. As part = of the locking process, any changes which have already occurred at the = other DSAs would need to be integrated into this DSA state. Procedures = would then revert to normal LDAP multimaster replication through = primitives to all other DSAs. The approach would remove all Extraordinary States. 3.4 Serialisability by Stealth The approach described above may be additionally extended to provide = full two phase locking using the mechanisms developed for the = negotiation phase. The approach would introduce all of the issues = which have been dealt with in Weighted Voting style algorithms, = including performance and durations of entries being unavailable (NB = Depending on configuration, weighted voting schemes can continue to = operate even when some DSAs are unavailable). With appropriate design to fit into the current framework, this = approach would remove all LKW and ES consistency issues. 4. Deployment Strategies for Multimaster LDAP. Deployment of multimaster a multimaster LDAP directory may be performed = in a number of different configurations. The following issues were = identified in Section 3.1 : * replication agreement structure,=20 * scheduling policies,=20 * DSA reliability,=20 * communications links reliability. These design choices clearly influence the ability of the multimaster = replication procedures to reduce consistency problems during operation. Additionally, the deployer of a multimaster directory has an additional = factor at their disposal to influence possible consistency problems. = The deployment may include not only * Multimasters, but also * Single Masters, and * Read-Only Replicas. Deployment strategies using the above may consist of : 1. Single Master 2. Single Master with Read Only replicas 3. Multiple Masters 4. Multiple Masters with Read Only replicas Additionally, an additional deployment strategy is to deploy in = configuration 1 or 2 above, but allow multimaster replication to take = over for a limited period of time on particular occurences, that is, = during failure or network partition with the original Single Master. = This period of time may be limited by either the reattachment of the = original Single Master or by undergoing negotiation between the = remaining masters to elect a new Single Master. This strategy is : 5. Single Master with Multimaster Backup=20 A. Single Master Phase B. Multimaster Backup Phase It should also be noted for deployment purposes that the multimaster = replication algorithms have been designed so that the following hold : * Clock synchronisation between replicas is not required. It is = however recommended, and the impact of a clock being out of = synchronisation is that the updates from this replica will either fall = behind or overrun their real world order. * Algorithms continue despite Network partitioning. Updates will = "resolve" themselves when the network partition is mended, however, the = longer the partition persists, the more conflicts are likely to occur = in resolution. 4.1 Consistency Implications of Deployment Strategy The following table summarises the consistency implications of each of = the possible deployment strategies. Abbreviations are as follows : * SM : Single Master * RO : Read Only * MM : Multimaster * SO : Serialised Operations * LKW : Last Known Wins * ES : Extraordinary States * TES : Transient Extraordinary States * na : Not applicable Rows represent the deployment style (e.g. Single Master etc as = described in the beginning of Section 4 - numbering is consistent with = this section). The columns represent the type of DSA in this = deployment configuration. The entries in the table represent the type = of consistency which can be expected in this deployment style at this = particular type of replica in the deployment style. SM MM RO =20 ------------------------------------------------------------------------= 1. SM SO na na =20 ------------------------------------------------------------------------= 2. SM/RO SO na LKW TES ------------------------------------------------------------------------= 3. MM na LKW na ES ------------------------------------------------------------------------= 4. MM/RO na LKW LKW ES ES ------------------------------------------------------------------------= 5.A. SM/MM SO LKW LKW TES TES ------------------------------------------------------------------------= 5.B. SM/MM na LKW LKW ES ES ------------------------------------------------------------------------= 4.2 Improving Consistency through Cooperation It is possible for a set of applications to cooperate to provide higher = levels of consistency within a multimaster environment than is = available by default if * they have exclusive access to a particular area of the DIT * nominate one of the DSAs participating as a master in the multimaster = approach as a preferred master. This approach, Multimaster with Primary (MMP), has the following = characteristics : Preferred MM RO =20 ------------------------------------------------------------------------= 6. MMP SO LKW LKW TES TES =20 ------------------------------------------------------------------------= In this case, these applications are able to ensure Single Master = levels of consistency within the multimaster environment 4.3 Possible Future Deployment Strategies For interest only at this stage, the following table shows the expected = gains from using a weighted voting negotiation phase (WVN), and also = full weighted voting (WV) (Sections 3.3 and 3.4) : SM MM RO =20 ------------------------------------------------------------------------= WVN na LKW LKW ------------------------------------------------------------------------= WV na SO LKW TES ------------------------------------------------------------------------= ------_=_NextPart_000_01BFA527.9D83B3E8 Content-Type: application/msword; name="ldupprof.doc" Content-Disposition: attachment; filename="ldupprof.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAASwAAAAAAAAAA EAAATQAAAAEAAAD+////AAAAAEoAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAcQAJBAAAABK/AAAAAAAAEAAAAAAABAAA+EcAAA4AYmpianQrdCsAAAAAAAAAAAAAAAAAAAAA AAAJBBYAIl4AABZBAQAWQQEA+EMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAF0AAAAAACgBAAAAAAAAKAEAACgB AAAAAAAAKAEAAAAAAAAoAQAAAAAAACgBAAAAAAAAKAEAABQAAAAAAAAAAAAAADwBAAAAAAAAPAEA AAAAAAA8AQAAAAAAADwBAAAAAAAAPAEAAAwAAABIAQAAPAAAADwBAAAAAAAAsw8AALYAAACYAQAA AAAAAJgBAAAAAAAAmAEAAAAAAACYAQAAAAAAAJgBAAAAAAAAmAEAAAAAAACYAQAAAAAAAJgBAAAA AAAAiAwAAAIAAACKDAAAAAAAAIoMAAAAAAAAigwAAFAAAADaDAAAUAEAACoOAABQAQAAeg8AACQA AABpEAAA9AEAAF0SAABoAAAAng8AABUAAAAAAAAAAAAAAAAAAAAAAAAAKAEAAAAAAACYAQAAAAAA AAAAAAAAAAAAAAAAAAAAAACYAQAAAAAAAJgBAAAAAAAAmAEAAAAAAACYAQAAAAAAAJ4PAAAAAAAA PgkAAAAAAAAoAQAAAAAAACgBAAAAAAAAmAEAAAAAAAAAAAAAAAAAAJgBAAAAAAAAmAEAAAAAAAA+ CQAAAAAAAD4JAAAAAAAAPgkAAAAAAACYAQAA+gMAACgBAAAAAAAAmAEAAAAAAAAoAQAAAAAAAJgB AAAAAAAAiAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAEAAAAAAAA8AQAAAAAAACgBAAAAAAAAKAEA AAAAAAAoAQAAAAAAACgBAAAAAAAAmAEAAAAAAACIDAAAAAAAAD4JAABKAwAAPgkAAAAAAAAAAAAA AAAAAIgMAAAAAAAAKAEAAAAAAAAoAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiAwAAAAAAACYAQAAAAAAAIQBAAAUAAAAoNozwCWl vwE8AQAAAAAAADwBAAAAAAAAkgUAAKwDAACIDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATERV UCBQcm9maWxlcyBDb250cmlidXRpb24gZnJvbSBBbGlzb24gUGF5bmUgIDEzLzA0LzIwMDANDTEg IEludHJvZHVjdGlvbg0NVGhlIG9yaWdpbmFsICJwcm9maWxlcyIgZG9jdW1lbnQgd2FzIGludGVu ZGVkIHRvIGRlZmluZSB0aGUgc3Vic2V0IG9mIGZlYXR1cmVzIHdoaWNoIGNvdWxkIGJlIGltcGxl bWVudGVkIGlmIGEgdmVuZG9yIHdpc2hlZCB0byBwcm92aWRlIGVpdGhlciBzaW5nbGUgbWFzdGVy IG9yIG11bHRpbWFzdGVyIHJlcGxpY2F0aW9uLiAgVGhpcyBhaW0gZG9lcyBub3QgbWFrZSBzZW5z ZSBpbiB0aGUgZnJhbWV3b3JrIG9mIHRoZSBjdXJyZW50IHJlcGxpY2F0aW9uIHNwZWNpZmljYXRp b24gc2luY2Ugbm8gc3VjaCBzdWJzZXQgY2FuIGJlIGVhc2lseSBzZXBhcmF0ZWQgZm9yIGVpdGhl ciBmb3JtIG9mIHJlcGxpY2F0aW9uLg0NU2luY2UgaXQgaXMgbm90IHBvc3NpYmxlIGZvciB2ZW5k b3JzIHRvIHJlZHVjZSB0aGUgcmVwbGljYXRpb24gb2ZmZXJpbmcgdGhleSBwcm92aWRlLCB0aGlz IGRvY3VtZW50IGNoYW5nZXMgdGhlIGludGVudCBvZiB0aGUgcHJvZmlsZXMgZG9jdW1lbnQgZnJv bSB0aGF0IHN0YXRlZCBhYm92ZS4gIFRoaXMgZG9jdW1lbnQgbm93IGRldGFpbHMgZGVwbG95bWVu dCBjb25zaWRlcmF0aW9ucy4gIFRoZSBmb2N1cyBpcyBjdXJyZW50bHkgb24gdGhlIGNvbnNpc3Rl bmN5IGltcGxpY2F0aW9ucyBvZiBkZXBsb3lpbmcgZWl0aGVyIHNpbmdsZSBtYXN0ZXIgb3IgbXVs dGltYXN0ZXIgZGlyZWN0b3JpZXMsIGJ1dCBtYXkgYnJvYWRlbi4NDVRoZSBkb2N1bWVudCBiZWdp bnMgYnkgZGV0YWlsaW5nIHRoZSAiZ2l2ZW5zIiBpbiBjdXJyZW50IG5vbi1yZXBsaWNhdGVkIExE QVAgZGVwbG95bWVudHMuICBGb2xsb3dpbmcgdGhpcywgYSBicmllZiBvdmVydmlldyBvZiB0aGUg ZnVuZGFtZW50YWxzIG9mIE11bHRpbWFzdGVyIHJlcGxpY2F0aW9uIGFyZSBnaXZlbiwgaW5jbHVk aW5nIHRoZSBwb3RlbnRpYWwgY2hhbmdlcyBpbiBjb25zaXN0ZW5jeSBkdWUgdG8gZnVsbHkgb3Bl cmF0aW9uYWwgbXVsdGltYXN0ZXIgcmVwbGljYXRpb24uICBGaW5hbGx5LCB2YXJpb3VzIGRlcGxv eW1lbnQgc3RyYXRlZ2llcyBhbmQgdGhlaXIgaW1wbGljYXRpb25zIG9uIGNvbnNpc3RlbmN5IGFy ZSBkaXNjdXNzZWQuDQ0yLiAgRnVuZGFtZW50YWxzIG9mIGEgTm9uLXJlcGxpY2F0ZWQgTERBUCBE aXJlY3RvcnkNDVRoZSBjb25zaXN0ZW5jeSBtYWludGFpbmVkIGJ5IGEgbm9uLXJlcGxpY2F0ZWQg TERBUCBEaXJlY3RvcnkgY2FuIGJlIGRlc2NyaWJlZCBhcyBmb2xsb3dzIDoNKiBTZXJpYWxpc2Vk IE9wZXJhdGlvbnMgKFNPKSA6IFRoZSBESVQgc3RhdGUgY2FuIGJlIHJlY29uc3RydWN0ZWQgYnkg YXBwbHlpbmcgZXZlcnkgb3BlcmF0aW9uIHdoaWNoIGhhcyBvY2N1cnJlZCBpbiB0aGUgZGlyZWN0 b3J5IHVwIHVudGlsIHRoaXMgcG9pbnQgaW4gdGltZSBpbiBzZXF1ZW5jZS4gIFRoYXQgaXMsIHRo ZSBzdGF0ZSBvZiBhIHBhcnRpY3VsYXIgZW50cnkgcmVmbGVjdHMgYSBzZXF1ZW5jZSBvZiBvcGVy YXRpb25zIG9uIHRoYXQgZW50cnkuDQ1JdCBzaG91bGQgYmUgbm90ZWQgdGhhdCB0aGVyZSBpcyBu byBwb3NzaWJpbGl0eSB3aXRoaW4gdGhlIExEQVAgRGlyZWN0b3J5IEluZm9ybWF0aW9uIE1vZGVs IHRvIHNwZWNpZnkgc3BlY2lmaWMgY29uc3RyYWludHMgb3ZlciBkaXJlY3Rvcnkgc3RhdGUgOg0q IGJldHdlZW4gZW50cmllcy4gIFRoYXQgaXMsIG9wZXJhdGlvbnMgb24gZGlmZmVyZW50IGVudHJp ZXMgY2Fubm90IGJlIGZvcm1lZCBpbnRvIHRyYW5zYWN0aW9ucy4gIEZvciBleGFtcGxlLCBpdCBp cyBub3QgcG9zc2libGUgdG8gZW5zdXJlIHRyYW5zZmVycyBiZXR3ZWVuIGJhbmsgYWNjb3VudHMg b2NjdXIgYXRvbWljYWxseS4NKiBiZXR3ZWVuIGF0dHJpYnV0ZXMgb2YgYSBzaW5nbGUgZW50cnku ICBUaGF0IGlzLCBpdCBpcyBub3QgcG9zc2libGUgdG8gcmVxdWlyZSB0aGF0IG9wZXJhdGlvbnMg b24gYSBwYXJ0aWN1bGFyIGVudHJ5IGFsd2F5cyBtYWludGFpbiBwYXJ0aWN1bGFyIGludGVybmFs IHJlbGF0aW9uc2hpcHMgYmV0d2VlbiBhdHRyaWJ1dGVzIGluIHRoYXQgZW50cnkuICBGb3IgZXhh bXBsZSwgdGhhdCBwYXkgaXMgYWx3YXlzIDIqYWdlL2hvdXIuICANKiBiZXR3ZWVuIHN0YXRlcyBv ZiBhbiBlbnRyeS4gIFRoYXQgaXMsIG9wZXJhdGlvbnMgb24gdGhlIHNhbWUgZW50cnkgY2Fubm90 IGJlIGZvcm1lZCBpbnRvIHRyYW5zYWN0aW9ucy4gIEZvciBleGFtcGxlLCBhbiBvcGVyYXRpb24g b24gYSBjb3VudGVyIHN0eWxlIGF0dHJpYnV0ZSBjYW5ub3QgYXNzdW1lIHRoYXQgYW5vdGhlciBv cGVyYXRpb24gaGFzIG5vdCBzZXBhcmF0ZWx5IGluY3JlbWVudGVkIHRoZSBzYW1lIGNvdW50ZXIg d2l0aG91dCBpdHMga25vd2xlZGdlLg0NSWYgYW4gYXBwbGljYXRpb24gaXMgY3VycmVudGx5IG9w ZXJhdGluZyBpbiBhIHNpbmdsZSBhcHBsaWNhdGlvbiBlbnZpcm9ubWVudCwgaXQgaXMgcG9zc2li bGUgdGhhdCBpdCBoYXMgYXNzdW1lZCBhbGwgb2YgdGhlIGFib3ZlLCBhbmQgaXQgaXMgcGVyZm9y bWluZyB0cmFuc2FjdGlvbiBwcm9jZXNzaW5nIGFuZCBtYWludGFpbmluZyBpbmhlcmVudCBvciBl eHBsaWNpdCBjb25zdHJhaW50cy4NDUlmIGFuIGFwcGxpY2F0aW9uIGlzIGN1cnJlbnRseSBvcGVy YXRpbmcgaW4gYSBtdWx0aS1hcHBsaWNhdGlvbiBlbnZpcm9ubWVudCAsIHRoZW4gcGFydGljdWxh ciB0cmFuc2FjdGlvbiBwcm9jZXNzaW5nIGFuZCBjb25zdHJhaW50cyBtYXkgaGF2ZSBiZWVuIG5l Z290aWF0ZWQgYmV0d2VlbiBhbGwgYXBwbGljYXRpb25zLCBhbmQgdGhlIGVhY2ggb2YgdGhlIGFw cGxpY2F0aW9ucyBhcmUgZXhwbGljaXRseSBtYWludGFpbmluZyB0cmFuc2FjdGlvbiBwcm9jZXNz aW5nIGFuZCBjb25zdHJhaW50cy4NDUlmIGFuIGFwcGxpY2F0aW9uIGlzIGN1cnJlbnRseSBvcGVy YXRpbmcgaW4gYSBtdWx0aS1hcHBsaWNhaXRvbiBlbnZpcm9ubWVudCBidXQgaGFzIG5vdCBuZWdv dGlhdGVkIGNvbW1vbiB0cmFuc2FjdGlvbiBwcm9jZXNzaW5nIGFuZCBjb25zdHJhaW50IGhhbmRs aW5nIHdpdGggb3RoZXIgYXBwbGljYXRpb25zLCB0aGVuIGl0IGlzIG9ubHkgbHVjayBpZiBhbnkg b2YgdGhlIHJlcXVpcmVkIHRyYW5zYWN0aW9uIHByb2Nlc3NpbmcgYW5kIGNvbnN0cmFpbnRzIGFy ZSBiZWluZyBtYWludGFpbmVkLg0NMy4gIEZ1bmRhbWVudGFscyBvZiBhIE11bHRpbWFzdGVyIExE QVAgRGlyZWN0b3J5DQ1BIG11bHRpbWFzdGVyIExEQVAgZGlyZWN0b3J5IHByb3ZpZGVzIHF1aXRl IGEgZGlmZmVyZW50IGVudmlyb25tZW50IHRvIGEgc2luZ2xlIExEQVAgZGlyZWN0b3J5LiAgU29t ZSBvZiB0aGUgbWFqb3IgZGlmZmVyZW5jZXMgYXJlIGFzIGZvbGxvd3MgOg0qIERTQXMgb3duZWQg YW5kIG9wZXJhdGVkIGJ5IGRpZmZlcmVudCBhdXRob3JpdGllcywNKiBXaWRlIHJhbmdlIG9mIGFw cGxpY2F0aW9uIHJlcXVpcmVtZW50cywNKiBWYXJpYWJsZSBzZXJ2aWNlIGxldmVsIGd1YXJhbnRl ZXMgZm9yIGluZGl2aWR1YWwgRFNBcywNKiBWYXJpYWJsZSBjb21tdW5pY2F0aW9ucyBxdWFsaXR5 IGFuZCBkZWxheXMsDSogQ29ubmVjdGlvbiBiZXR3ZWVuIERTQXMgdmlhIHJlcGxpY2F0aW9uIGFn cmVlbWVudHMsIGFuZCBvZnRlbiAiaW5mb3JtYWwiIGFycmFuZ2VtZW50cyBiZXR3ZWVuIGluZGl2 aWR1YWwgRFNBcyB2aWEgdGhpcmQgcGFydHkgcmVwbGljYXRpb24gYWdyZWVtZW50cy4NDVRoZXNl IGRpZmZlcmVuY2VzIG1lYW4gdGhhdCBhIGdyb3VwIG9mIERTQXMgd2hvIGNvb3BlcmF0ZSBvbiBh IGNvbW1vbiBtdWx0aW1hc3RlcmVkIHJlcGxpY2F0aW9uIGFyZWEgY2Fubm90IGJlIGFzc3VtZWQg dG8gaGF2ZSByZWxpYWJsZSBhdmFpbGFiaWxpdHkgb3IgY29tbXVuaWNhdGlvbnMgbGlua3MuICAg VGhlIGZ1bmRhbWVudGFsIGFwcHJvYWNoIGlzIGFzIGZvbGxvd3MgOg0xLiAgT3BlcmF0aW9ucyBh cmUgYWxsb3dlZCB0byBnbyBhaGVhZCBvbiBhIHBhcnRpY3VsYXIgRFNBIGlmIG5vIGludGVybmFs IExEQVAgY29uc3RyYWludHMgYXJlIGJyb2tlbi4NMi4gIE9wZXJhdGlvbiByZXN1bHRzIChpLmUu IHRoZSBjaGFuZ2Ugb2Ygc3RhdGUgY2F1c2VkIGJ5IHRoZSBvcGVyYXRpb24pIGFyZSBleHByZXNz ZWQgYXMgYSBzZXJpZXMgb2Ygc3RhdGUgY2hhbmdlcyAocHJpbWl0aXZlcykuDTMuICBUaGVzZSBw cmltaXRpdmVzIGFyZSBleGNoYW5nZWQgYmV0d2VlbiBEU0FzIHdobyBjb29wZXJhdGUgdW5kZXIg cmVwbGljYXRpb24gYWdyZWVtZW50cy4gIFRoZXNlIHJlcGxpY2F0aW9uIGFncmVlbWVudHMgbWF5 IGhhdmUgb25jaGFuZ2Ugb3IgcGVyaW9kaWMgc2NoZWR1bGluZyBvZiB0aGUgZXhjaGFuZ2Ugb2Yg cHJpbWl0aXZlcy4NNC4gIFdoZW4gYSBEU0EgcmVjZWl2ZXMgdGhlIHByaW1pdGl2ZXMsIGl0IGFw cGxpZXMgdGhlIHJlcXVlc3RlZCBzdGF0ZSBjaGFuZ2VzIHRvIGl0cyBvd24gRElULg0NVGhlIGFw cGxpY2F0aW9uIG9mIHRoZSByZXF1ZXN0ZWQgc3RhdGUgY2hhbmdlcyBtdXN0IGZvbGxvdyBwYXJ0 aWN1bGFyIHByb2Nlc3NpbmcgcnVsZXMgKHRoZSBVUlAgYWxnb3JpdGhtcykgdG8gZW5zdXJlIHRo YXQgYSBjb21tb24gcmVzdWx0IGlzIGFjaGlldmVkIGF0IGFsbCBEU0FzIHdoaWNoIHJlY2VpdmUg dGhlIHN0YXRlIGNoYW5nZS4gIFRoZSBiYXNpYyBhcHByb2FjaCBmb2xsb3dlZCBpcw0qIExhdGVz dCBLbm93biBXaW5zIChMS1cpIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuMS4NDUluIHNvbWUg Y2FzZXMsIHRoZSBibGluZCBhcHBsaWNhdGlvbiBvZiB0aGUgcmVxdWVzdGVkIHN0YXRlIGNoYW5n ZSBtYXkgY2F1c2UgYSAiY29uc3RyYWludCB2aW9sYXRpb24iIHRvIG9jY3VyLiAgRm9yIGV4YW1w bGUsIGFuIGVudHJ5IG1pZ2h0IGJlIG9ycGhhbmVkLiAgIFN0YW5kYXJkICJjb25zdHJhaW50IHZp b2xhdGlvbiIgaGFuZGxpbmcgaXMgYXBwbGllZCB3aGljaCBjcmVhdGVzIG9jY2FzaW9uYWwgDSog RXh0cmFvcmRpbmFyeSBTdGF0ZXMgKEVTKSBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjIuDQ1C b3RoIG9mIHRoZSBhYm92ZSBtZWNoYW5pc21zIGNhbiBjcmVhdGUgZGlyZWN0b3J5IHN0YXRlcyB3 aGljaCBhcmUgbm90IHRoZSByZXN1bHQgb2YgYSBzZXJpYWxpc2FibGUgc2V0IG9mIGF0b21pY2Fs bHkgYXBwbGllZCBvcGVyYXRpb25zLiAgVGhlIGltcGFjdCBvZiB0aGlzIGlzIHF1YW50aWZpYWJs ZSBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbnMgMy4xIGFuZCAzLjIuICBQb3NzaWJsZSBtZWNoYW5p c21zIHRvIHJlZHVjZSB0aGUgb2NjdXJyZW5jZSBvZiB0aGVzZSBzdGF0ZXMgYXJlIGFsc28gZGlz Y3Vzc2VkIGluIHRoZXNlIHNlY3Rpb25zLg0NQWRkaXRpb25hbGx5LCBwYXJ0aWN1bGFyIGRlcGxv eW1lbnQgY2hvaWNlcyAoZS5nLiBzaW5nbGUgbWFzdGVyL211bHRpIG1hc3RlcikgY2FuIHJlZHVj ZSBvciByZW1vdmUgdGhlIHBvc3NpYmlsaXR5IG9mIHRoZXNlIHN0YXRlcyBvY2N1cnJpbmcuICBU aGVzZSBhcmUgZGlzY3Vzc2VkIGluIFNlY3Rpb24gNC4NDTMuMSAgTGF0ZXN0IEtub3duIFdpbnMg Q29uc2lzdGVuY3kNDVRoZSAiTGF0ZXN0IEtub3duIFdpbnMiIGFwcHJvYWNoIGhhcyB0aGUgb3V0 Y29tZSB0aGF0IGFsbCBhdHRyaWJ1dGVzIHdpbGwgImV2ZW50dWFsbHkiIHJlYWNoIHRoZSBsYXRl c3QgdmFsdWUgZW50ZXJlZCBpbnRvIHRoZSBzeXN0ZW0uICBEdXJpbmcgdGhlICJldmVudHVhbGl0 eSIgYmVpbmcgcmVhY2hlZCwgaW50ZXJtZWRpYXRlIHN0YXRlcyByZWZsZWN0aW5nIGEgY29tYmlu YXRpb24gb2Ygc3RhdGVzIHdoaWNoIGhhdmUgZXhpc3RlZCBvdmVyIHRpbWUgbWF5IGJlIGhlbGQg YnkgYW4gaW5kaXZpZHVhbCBEU0EuICBUaGVzZSBpbnRlcm1lZGlhdGUgc3RhdGVzIGFyZSBiZXN0 IGRlc2NyaWJlZCB1c2luZyBhbiBleGFtcGxlLiAgVHdvIG9wZXJhdGlvbnMsIFQxIGF0IHRpbWUg MSBhbmQgVDIgYXQgdGltZSAyLCBvY2N1ciBvbiBhbiBlbnRyeSB1cGRhdGluZyBhdHRyaWJ1dGVz IEEgYW5kIEIuICAgVGhpcyBtYXkgYmUgdmlld2VkIGFzIGZvbGxvd3MgOg1UMCAgICAgVDEgICAg IFQyDUEwICAgICBBMSAgICAgQTINQjAgICAgIEIxICAgICBCMg0NIkxhdGVzdCBLbm93biBXaW5z IiBjb25zaXN0ZW5jeSBoYXMgdGhlIHNlbWFudGljcyB0aGF0IGFsbCBkaXJlY3RvcmllcyB3aWxs IGV2ZW50dWFsbHkgaGF2ZSB0aGUgc3RhdGUgQTIsIEIyIChwcm92aWRpbmcgbm8gZnVydGhlciBv cGVyYXRpb25zIGluIHRoZSBkaXN0cmlidXRlZCBzeXN0ZW0gYWZmZWN0IGF0dHJpYnV0ZXMgQSBh bmQgQikuICBIb3dldmVyLCBhdCB0aW1lcyBiZXR3ZWVuIGVpdGhlciB1cGRhdGUgb2NjdXJyaW5n IGFuZCB0aGlzICJldmVudHVhbGl0eSIsIHRoZSBkaXJlY3Rvcnkgc3RhdGUgbWF5IGJlIGFueSBj b21iaW5hdGlvbiBvZiB0aGUgaW5kaXZpZHVhbCBzdGF0ZXMgb2YgQSBhbmQgQiBkZXBlbmRpbmcg b24gdGhlIHByaW1pdGl2ZXMgY3VycmVudGx5IHJlY2VpdmVkIGFuZCBwcm9jZXNzZWQgYnkgZWFj aCANIERTQS4gIFRoYXQgaXMsIGFueSBvZiB0aGUgZm9sbG93aW5nIHN0YXRlcyBtYXkgZXhpc3Qg Og0qICBBMCwgQjAgKE5laXRoZXIgT3BlcmF0aW9uIGhhcyB5ZXQgb2NjdXJyZWQpDSogQTAsIEIx IChQYXJ0aWFsIGNvbXBsZXRpb24gb2YgT3BlcmF0aW9uIDEpDSogQTAsIEIyIChQYXJ0aWFsIGNv bXBsZXRpb24gb2YgT3BlcmF0aW9uIDIpDSogQTEsIEIwIChQYXJ0aWFsIGNvbXBsZXRpb24gb2Yg T3BlcmF0aW9uIDEpDSogQTEsIEIxIChPcGVyYXRpb24gMSBoYXMgb2NjdXJyZWQpDSogQTEsIEIy IChPcGVyYXRpb24gMSBjb21wbGV0ZWQsIFBhcnRpYWwgY29tcGxldGlvbiBvZiBPcGVyYXRpb24g MikNKiBBMiwgQjAgKFBhcnRpYWwgY29tcGxldGlvbiBvZiBPcGVyYXRpb24gMikNKiBBMiwgQjEg KE9wZXJhdGlvbiAxIGNvbXBsZXRlZCwgUGFydGlhbCBjb21wbGV0aW9uIG9mIE9wZXJhdGlvbiAy KQ0qIEEyLCBCMiAoT3BlcmF0aW9uIDIgaGFzIG9jY3VycmVkKQ0NIFRoZSBsZW5ndGggb2YgdGlt ZSBmb3IgImV2ZW50dWFsaXR5IiB0byBiZSByZWFjaGVkIGlzIGRlcGVuZGVudCBvbg0qIHJlcGxp Y2F0aW9uIGFncmVlbWVudCBzdHJ1Y3R1cmUsIChlLmcuIGRvZXMgdGhlIG92ZXJhbGwgdG9wb2xv Z3kgc3VwcG9ydGVkIGJ5IGFsbCByZWxldmFudCByZXBsaWNhdGlvbiBhZ3JlZW1lbnRzIGFsbG93 IGVhc2Ugb2YgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIGFsbCBEU0FzPykgDSogc2NoZWR1bGluZyBw b2xpY2llcywgKGUuZy4gYXJlIGNoYW5nZXMgbWFkZSBvbmNoYW5nZSwgb3IgdmlhIHBlcmlvZGlj IHBvbGljaWVzIChlLmcuIG9uZSBwZXIgZGF5PykpDSogRFNBIHJlbGlhYmlsaXR5LCAoZS5nLiBh cmUgYW55IERTQXMgYm90dGxlbmVja3MgaW4gdGhlIHRyYW5zaXRpb24gb2YgdXBkYXRlcyBmcm9t IG9uZSBuZXR3b3JrIGFyZWEgdG8gYW5vdGhlcj8pDSogY29tbXVuaWNhdGlvbnMgbGlua3MgcmVs aWFiaWxpdHkuIChlLmcuIGFyZSBhbnkgRFNBcyBzZXBhcmF0ZWQgZnJvbSB0aGUgcmVtYWluZGVy IG9mIHRoZSBEU0FzIHRocm91Z2ggc2xvdyBvciB1bnJlbGlhYmxlIGNvbW11bmljYXRpb25zIGxp bmtzPykNQWRkaXRpb25hbGx5LCB0aGUgYWJvdmUgYWxzbyBpbmZsdWVuY2VzIHRoZSBudW1iZXIg YW5kIGR1cmF0aW9uIG9mIHRoZXNlIGludGVybWVkaWF0ZSBzdGF0ZXMgb2NjdXBpZWQgYnkgYSBE U0EuDQ1JdCBpcyBwb3NzaWJsZSB3aXRoaW4gYSBzbWFsbCBjb21tdW5pdHkgb2YgcmVsaWFibGUg RFNBcyB3aXRoIHJlbGlhYmxlIGNvbW11bmljYXRpb25zIGxpbmtzIHRvIGdyZWF0bHkgbWluaW1p c2UgdGhlIHBlcmlvZCBvZiB0aW1lIHNwZW50IGluIHRoZXNlIGludGVybWVkaWF0ZSBzdGF0ZXMu DQ0zLjIgIEV4dHJhb3JkaW5hcnkgU3RhdGVzDQ1UaGUgc2Vjb25kIGltcGxpY2F0aW9uIG9mIHRo ZSBtdWx0aW1hc3RlciByZXBsaWNhdGlvbiBhcHByb2FjaCBpcyB0aGUgY3JlYXRpb24gb2YgImV4 dHJhb3JkaW5hcnkgc3RhdGVzIiBkdXJpbmcgdGhlIHJlc29sdXRpb24gb2YgcmVxdWVzdGVkIHN0 YXRlIGNoYW5nZXMgd2l0aCB0aGUgY3VycmVudCBESVQgc3RydWN0dXJlLiAgVGhlc2Ugc3RhdGVz IHJlc3VsdCBmcm9tIGNvcnJlY3RpdmUgYWN0aW9ucyB0YWtlbiBieSB0aGUgcmVwbGljYSB0byBt YWludGFpbiB0aGUgRElUIGNvbnN0cmFpbnRzLiAgVGhlc2UgZXh0cmFvcmRpbmFyeSBzdGF0ZXMg aW5jbHVkZSB0aGUgZm9sbG93aW5nIDoNKiBMb3N0IGFuZCBGb3VuZCA6IEFuIGVudHJ5IHdoaWNo IGlzIGZvdW5kIHRvIGhhdmUgYSBuYW1pbmcgYW5vbW9seSBtYXkgYmUgcGxhY2VkIHVuZGVyIHRo ZSBMb3N0IGFuZCBGb3VuZCBub2RlLiAgRm9yIGV4YW1wbGUsIGFuIGVudHJ5IHdoaWNoIG5vIGxv bmdlciBoYXMgYSBwYXJlbnQgd2lsbCBoYXZlIGEgZ2x1ZSBlbnRyeSBhcyB0aGUgcGFyZW50IHdo aWNoIGluIHR1cm4gaGFzIGEgcGFyZW50IG9mIHRoZSBsb3N0IGFuZCBmb3VuZCBub2RlLg0qIENv bmZsaWN0aW5nIFNpYmxpbmdzIDogQW4gZW50cnkgd2hpY2ggaXMgZm91bmQgdG8gInNoYXJlIiBh IG5hbWUgd2l0aCBhIGZlbGxvdyBzaWJsaW5nIGhhcyBpdHMgVUlEIGFwcGVuZGVkIHRvIGl0cyBS ZWxhdGl2ZSBEaXN0aW5ndWlzaGVkIE5hbWUuICBBZGRpdGlvbmFsbHksIHRoZSBzaWJsaW5nIHdp dGggdGhlIGNvbmZsaWN0aW5nIG5hbWUgaGFzIHRoZSBzYW1lIG9jY3VyLg0qIEltcGxpY2l0IE5h bWUgQ2hhbmdlczogQW4gZW50cnkgd2hpY2ggaGFzIGhhZCBhIHJlY2VudCBjaGFuZ2Ugb2YgbmFt ZSBtYXkgYmUgaW1wYWN0ZWQgYnkgb3RoZXIgRFNBcyB3aGljaCB3ZXJlIHVuYXdhcmUgb2YgdGhl IG5hbWUgY2hhbmdlLiAgVGhlIGV2ZW50dWFsIG5hbWUgb2YgdGhlIGVudHJ5IHdpbGwgcmVmbGVj dCBhbGwgb2YgdGhlIGFjdGlvbnMgaW4gdGhpcyB0aW1lIChpbmNsdWRpbmcgYXR0cmlidXRlIHJl bW92ZXMgb24gbmFtaW5nIGF0dHJpYnV0ZXMpLiAgSXQgaXMgcG9zc2libGUgdGhhdCBhbiBlbnRy eSBpcyBsZWZ0IHdpdGggYW4gZW1wdHkgbmFtZS4gIEluIHRoaXMgY2FzZSwgYW4gZW50cnkgaXMg Z2l2ZW4gaXRzIFVJRCBhcyBhbiBSRE4uDQ1UaGUgd2luZG93IG9mIHRpbWUgZHVyaW5nIHdoaWNo IHRoZXNlIGNvbnN0cmFpbnQgdmlvbGF0aW9ucyBjYW4gb2NjdXIgY2F1c2luZyB0aGUgZXh0cmFv cmRpbmFyeSBzdGF0ZXMgaXMgbWFpbmx5IGR1ZSB0byByZXBsaWNhdGlvbiBhZ3JlZW1lbnRzLCBz Y2hlZHVsaW5nIHBvbGljaWVzLCBEU0EgYW5kIGNvbW11bmljYXRpb25zIGxpbmsgcmVsaWFiaWxp dHkuICAgIEl0IGlzIGFnYWluIHBvc3NpYmxlIGZvciBhIHNtYWxsIGNvbW11bml0eSBvZiBEU0Fz IHRvIGdyZWF0bHkgbWluaW1pc2UgdGhlIHByb2JhYmlsaXR5IG9mIHRoZXNlIHByb2JsZW1zIG9j Y3VyaW5nIHRocm91Z2ggY2FyZSBpbiBkZXBsb3ltZW50Lg0NQWRkaXRpb25hbGx5LCB0aGVzZSBj b25zdHJhaW50IHZpb2xhdGlvbnMgbWF5IGFyaXNlIHRlbXBvcmFyaWx5ICg/KSBkdWUgdG8gdGhl IHByb2Nlc3Npbmcgb2YgcHJpbWl0aXZlcyBpbiBhbiBvcmRlciBvdGhlciB0aGFuIHRoYXQgd2hp Y2ggb2NjdXJyZWQgYXQgdGhlIG9yaWdpbmF0aW5nIERTQS4gIA0qIFRyYW5zaWVudCBFeHRyYW9y ZGluYXJ5IFN0YXRlcyAoVEVTKSwgZXh0cmFvcmRpbmFyeSBzdGF0ZXMgZHVlIHRvIHJlb3JkZXJp bmcgcmF0aGVyIHRoYW4gcmVhbCB3b3JsZCBjb25zaXN0ZW5jeSB2aW9sYXRpb25zLg0NV2hpbGUg aW4gbW9zdCBjaXJjdW1zdGFuY2VzLCB2ZW5kb3IgaW1wbGVtZW50YXRpb25zIHdpbGwgbWFpbnRh aW4gdGhlIG9yaWdpbmFsIG9yZGVyaW5nIGFuZCB0aGVyZWZvcmUgbWluaW1pc2UgdGhlIGNoYW5j ZXMgb2YgdGhpcyBvY2N1cnJpbmcsIHRoZSBhbGdvcml0aG1zIHByb3ZpZGUgdGhlIGZsZXhpYmls aXR5IHRvIGNvcGUgd2l0aCBtaXNvcmRlcmluZ3MgYXQgdGhlIHNsaWdodGx5IGluY3JlYXNlZCBy aXNrIG9mIHRlbXBvcmFyeSBjb25zdHJhaW50IHZpb2xhdGlvbnMuDQ1BZG1pbmlzdHJhdGlvbiBp bnRlcmZhY2VzIGFjY2Vzc2luZyB0aGUgZGlyZWN0b3J5IHdpbGwgbmVlZCB0byBiZSBhYmxlIHRv IGRldGVjdCB0aGF0IHN1Y2ggYW4gZXh0cmFvcmRpbmFyeSBzdGF0ZSBoYXMgYmVlbiBjcmVhdGVk IGFuZCBhbGxvdyB0aGUgYWRtaW5pc3RyYXRvciB0byBmaXggdGhlIHByb2JsZW0uDQ0zLjMgIFVz aW5nIFdlaWdodGVkIFZvdGluZyBpbiB0aGUgTmVnb3RpYXRpb24gUGhhc2UNDVRoZSBhbGdvcml0 aG1zIGRldmVsb3BlZCB0byBkYXRlIGhhdmUgYXNzdW1lZCB0aGF0IE5PIENPTU1VTklDQVRJT04g Y2FuIG9jY3VyIGJldHdlZW4gbWFzdGVycyBhdCB0aGUgdGltZSBvZiBhY2NlcHRpbmcgYW4gb3Bl cmF0aW9uIGF0IGEgRFNBLiAgSXQgaXMgcG9zc2libGUgdGhhdCBzbWFsbCBjb21tdW5pdGllcyBv ZiBEU0FzIG1heSBiZSBhYmxlIHRvIGhhdmUgcmVsaWFibGUgY29tbXVuaWNhdGlvbnMgbGlua3Mg YW5kIGhpZ2ggbmVnb3RpYXRlZCBzZXJ2aWNlIGxldmVscy4NDUZvciB0aGlzIHNwZWNpZmljIGNv bW11bml0eSwgYSBtb3JlIHN1aXRhYmxlIGludGVybWVkaWF0ZSBmb3JtIG9mIG11bHRpbWFzdGVy IHJlcGxpY2F0aW9uIG1heSBiZSBhYmxlIHRvIGJlIGRldmVsb3BlZCB3aXRoaW4gdGhlIGN1cnJl bnQgbXVsdGltYXN0ZXIgZnJhbWV3b3JrLiAgVGhlIGFwcHJvYWNoIHdvdWxkIGFsbG93IGEgbmVn b3RpYXRpb24gcGhhc2UgZHVyaW5nIHdoaWNoIGVudHJpZXMgYXJlIGxvY2tlZCBhdCBhIHN1YnNl dCBvZiBwYXJ0aWNpcGF0aW5nIG1hc3RlcnMgKGkuZS4gbm9ybWFsIHdlaWdodGVkIHZvdGluZyBk ZWNpc2lvbiksIGFuZCB0aGVuIHVubG9ja2VkIGF0IHRoZSBjb25jbHVzaW9uIG9mIHRoZSBvcGVy YXRpb24gb2NjdXJyaW5nIGF0IHRoZSBvcmlnaW5hdGluZyBEU0EuICBBcyBwYXJ0IG9mIHRoZSBs b2NraW5nIHByb2Nlc3MsIGFueSBjaGFuZ2VzIHdoaWNoIGhhdmUgYWxyZWFkeSBvY2N1cnJlZCBh dCB0aGUgb3RoZXIgRFNBcyB3b3VsZCBuZWVkIHRvIGJlIGludGVncmF0ZWQgaW50byB0aGlzIERT QSBzdGF0ZS4gIFByb2NlZHVyZXMgd291bGQgdGhlbiByZXZlcnQgdG8gbm9ybWFsIExEQVAgbXVs dGltYXN0ZXIgcmVwbGljYXRpb24gdGhyb3VnaCBwcmltaXRpdmVzIHRvIGFsbCBvdGhlciBEU0Fz Lg0NVGhlIGFwcHJvYWNoIHdvdWxkIHJlbW92ZSBhbGwgRXh0cmFvcmRpbmFyeSBTdGF0ZXMuDQ0z LjQgIFNlcmlhbGlzYWJpbGl0eSBieSBTdGVhbHRoDQ1UaGUgYXBwcm9hY2ggZGVzY3JpYmVkIGFi b3ZlIG1heSBiZSBhZGRpdGlvbmFsbHkgZXh0ZW5kZWQgdG8gcHJvdmlkZSBmdWxsIHR3byBwaGFz ZSBsb2NraW5nIHVzaW5nIHRoZSBtZWNoYW5pc21zIGRldmVsb3BlZCBmb3IgdGhlIG5lZ290aWF0 aW9uIHBoYXNlLiAgVGhlIGFwcHJvYWNoIHdvdWxkIGludHJvZHVjZSBhbGwgb2YgdGhlIGlzc3Vl cyB3aGljaCBoYXZlIGJlZW4gZGVhbHQgd2l0aCBpbiBXZWlnaHRlZCBWb3Rpbmcgc3R5bGUgYWxn b3JpdGhtcywgaW5jbHVkaW5nIHBlcmZvcm1hbmNlIGFuZCBkdXJhdGlvbnMgb2YgZW50cmllcyBi ZWluZyB1bmF2YWlsYWJsZSAoTkIgIERlcGVuZGluZyBvbiBjb25maWd1cmF0aW9uLCB3ZWlnaHRl ZCB2b3Rpbmcgc2NoZW1lcyBjYW4gY29udGludWUgdG8gb3BlcmF0ZSBldmVuIHdoZW4gc29tZSBE U0FzIGFyZSB1bmF2YWlsYWJsZSkuDQ1XaXRoIGFwcHJvcHJpYXRlIGRlc2lnbiB0byBmaXQgaW50 byB0aGUgY3VycmVudCBmcmFtZXdvcmssIHRoaXMgYXBwcm9hY2ggd291bGQgcmVtb3ZlIGFsbCBM S1cgYW5kIEVTIGNvbnNpc3RlbmN5IGlzc3Vlcy4NDTQuICBEZXBsb3ltZW50IFN0cmF0ZWdpZXMg Zm9yIE11bHRpbWFzdGVyIExEQVAuDQ1EZXBsb3ltZW50IG9mIG11bHRpbWFzdGVyIGEgbXVsdGlt YXN0ZXIgTERBUCBkaXJlY3RvcnkgbWF5IGJlIHBlcmZvcm1lZCBpbiBhIG51bWJlciBvZiBkaWZm ZXJlbnQgY29uZmlndXJhdGlvbnMuICBUaGUgZm9sbG93aW5nIGlzc3VlcyB3ZXJlIGlkZW50aWZp ZWQgaW4gU2VjdGlvbiAzLjEgOg0qIHJlcGxpY2F0aW9uIGFncmVlbWVudCBzdHJ1Y3R1cmUsIA0q IHNjaGVkdWxpbmcgcG9saWNpZXMsIA0qIERTQSByZWxpYWJpbGl0eSwgDSogY29tbXVuaWNhdGlv bnMgbGlua3MgcmVsaWFiaWxpdHkuDVRoZXNlIGRlc2lnbiBjaG9pY2VzIGNsZWFybHkgaW5mbHVl bmNlIHRoZSBhYmlsaXR5IG9mIHRoZSBtdWx0aW1hc3RlciByZXBsaWNhdGlvbiBwcm9jZWR1cmVz IHRvIHJlZHVjZSBjb25zaXN0ZW5jeSBwcm9ibGVtcyBkdXJpbmcgb3BlcmF0aW9uLg0NQWRkaXRp b25hbGx5LCB0aGUgZGVwbG95ZXIgb2YgYSBtdWx0aW1hc3RlciBkaXJlY3RvcnkgaGFzIGFuIGFk ZGl0aW9uYWwgZmFjdG9yIGF0IHRoZWlyIGRpc3Bvc2FsIHRvIGluZmx1ZW5jZSBwb3NzaWJsZSBj b25zaXN0ZW5jeSBwcm9ibGVtcy4gICBUaGUgZGVwbG95bWVudCBtYXkgaW5jbHVkZSBub3Qgb25s eQ0qIE11bHRpbWFzdGVycywgYnV0IGFsc28NKiBTaW5nbGUgTWFzdGVycywgYW5kDSogUmVhZC1P bmx5IFJlcGxpY2FzLg0NRGVwbG95bWVudCBzdHJhdGVnaWVzIHVzaW5nIHRoZSBhYm92ZSBtYXkg Y29uc2lzdCBvZiA6DTEuICBTaW5nbGUgTWFzdGVyDTIuICBTaW5nbGUgTWFzdGVyIHdpdGggUmVh ZCBPbmx5IHJlcGxpY2FzDTMuICBNdWx0aXBsZSBNYXN0ZXJzDTQuICBNdWx0aXBsZSBNYXN0ZXJz IHdpdGggUmVhZCBPbmx5IHJlcGxpY2FzDQ1BZGRpdGlvbmFsbHksIGFuIGFkZGl0aW9uYWwgZGVw bG95bWVudCBzdHJhdGVneSBpcyB0byBkZXBsb3kgaW4gY29uZmlndXJhdGlvbiAxIG9yIDIgYWJv dmUsIGJ1dCBhbGxvdyBtdWx0aW1hc3RlciByZXBsaWNhdGlvbiB0byB0YWtlIG92ZXIgZm9yIGEg bGltaXRlZCBwZXJpb2Qgb2YgdGltZSBvbiBwYXJ0aWN1bGFyIG9jY3VyZW5jZXMsIHRoYXQgaXMs IGR1cmluZyBmYWlsdXJlIG9yIG5ldHdvcmsgcGFydGl0aW9uIHdpdGggdGhlIG9yaWdpbmFsIFNp bmdsZSBNYXN0ZXIuICBUaGlzIHBlcmlvZCBvZiB0aW1lIG1heSBiZSBsaW1pdGVkIGJ5IGVpdGhl ciB0aGUgcmVhdHRhY2htZW50IG9mIHRoZSBvcmlnaW5hbCBTaW5nbGUgTWFzdGVyIG9yIGJ5IHVu ZGVyZ29pbmcgbmVnb3RpYXRpb24gYmV0d2VlbiB0aGUgcmVtYWluaW5nIG1hc3RlcnMgdG8gZWxl Y3QgYSBuZXcgU2luZ2xlIE1hc3Rlci4gICBUaGlzIHN0cmF0ZWd5IGlzIDoNNS4gIFNpbmdsZSBN YXN0ZXIgd2l0aCBNdWx0aW1hc3RlciBCYWNrdXAgDSAgICAgICBBLiAgU2luZ2xlIE1hc3RlciBQ aGFzZQ0gICAgICAgQi4gIE11bHRpbWFzdGVyIEJhY2t1cCBQaGFzZQ0NSXQgc2hvdWxkIGFsc28g YmUgbm90ZWQgZm9yIGRlcGxveW1lbnQgcHVycG9zZXMgdGhhdCB0aGUgbXVsdGltYXN0ZXIgcmVw bGljYXRpb24gYWxnb3JpdGhtcyBoYXZlIGJlZW4gZGVzaWduZWQgc28gdGhhdCB0aGUgZm9sbG93 aW5nIGhvbGQgOg0qICBDbG9jayBzeW5jaHJvbmlzYXRpb24gYmV0d2VlbiByZXBsaWNhcyBpcyBu b3QgcmVxdWlyZWQuICBJdCBpcyBob3dldmVyIHJlY29tbWVuZGVkLCBhbmQgdGhlIGltcGFjdCBv ZiBhIGNsb2NrIGJlaW5nIG91dCBvZiBzeW5jaHJvbmlzYXRpb24gaXMgdGhhdCB0aGUgdXBkYXRl cyBmcm9tIHRoaXMgcmVwbGljYSB3aWxsIGVpdGhlciBmYWxsIGJlaGluZCBvciBvdmVycnVuIHRo ZWlyIHJlYWwgd29ybGQgb3JkZXIuDSogQWxnb3JpdGhtcyBjb250aW51ZSBkZXNwaXRlIE5ldHdv cmsgcGFydGl0aW9uaW5nLiAgVXBkYXRlcyB3aWxsICJyZXNvbHZlIiB0aGVtc2VsdmVzIHdoZW4g dGhlIG5ldHdvcmsgcGFydGl0aW9uIGlzIG1lbmRlZCwgaG93ZXZlciwgdGhlIGxvbmdlciB0aGUg cGFydGl0aW9uIHBlcnNpc3RzLCB0aGUgbW9yZSBjb25mbGljdHMgYXJlIGxpa2VseSB0byBvY2N1 ciBpbiByZXNvbHV0aW9uLg0NNC4xICBDb25zaXN0ZW5jeSBJbXBsaWNhdGlvbnMgb2YgRGVwbG95 bWVudCBTdHJhdGVneQ0NVGhlIGZvbGxvd2luZyB0YWJsZSBzdW1tYXJpc2VzIHRoZSBjb25zaXN0 ZW5jeSBpbXBsaWNhdGlvbnMgb2YgZWFjaCBvZiB0aGUgcG9zc2libGUgZGVwbG95bWVudCBzdHJh dGVnaWVzLiAgQWJicmV2aWF0aW9ucyBhcmUgYXMgZm9sbG93cyA6DSogIFNNICA6IFNpbmdsZSBN YXN0ZXINKiBSTyA6IFJlYWQgT25seQ0qIE1NIDogTXVsdGltYXN0ZXINKiBTTyA6IFNlcmlhbGlz ZWQgT3BlcmF0aW9ucw0qIExLVyA6IExhc3QgS25vd24gV2lucw0qIEVTIDogRXh0cmFvcmRpbmFy eSBTdGF0ZXMNKiBURVMgOiBUcmFuc2llbnQgRXh0cmFvcmRpbmFyeSBTdGF0ZXMNKiBuYSA6IE5v dCBhcHBsaWNhYmxlDVJvd3MgcmVwcmVzZW50IHRoZSBkZXBsb3ltZW50IHN0eWxlIChlLmcuIFNp bmdsZSBNYXN0ZXIgZXRjIGFzIGRlc2NyaWJlZCBpbiB0aGUgYmVnaW5uaW5nIG9mIFNlY3Rpb24g NCCWIG51bWJlcmluZyBpcyBjb25zaXN0ZW50IHdpdGggdGhpcyBzZWN0aW9uKS4gIFRoZSBjb2x1 bW5zIHJlcHJlc2VudCB0aGUgdHlwZSBvZiBEU0EgaW4gdGhpcyBkZXBsb3ltZW50IGNvbmZpZ3Vy YXRpb24uICBUaGUgZW50cmllcyBpbiB0aGUgdGFibGUgcmVwcmVzZW50IHRoZSB0eXBlIG9mIGNv bnNpc3RlbmN5IHdoaWNoIGNhbiBiZSBleHBlY3RlZCBpbiB0aGlzIGRlcGxveW1lbnQgc3R5bGUg YXQgdGhpcyBwYXJ0aWN1bGFyIHR5cGUgb2YgcmVwbGljYSBpbiB0aGUgZGVwbG95bWVudCBzdHls ZS4NICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU00gICAgIE1NICAgICBSTyAgICAgDS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0xLiBTTQkgICAgICAgICAgICAgU08gICAgIG5hICAgICAgICAgbmEgICAg ICANLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDTIuICBTTS9STyAgICAgICAgICAgU08gICAgICAgbmEgICAgICAg ICBMS1cNICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFRFUw0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NMy4gIE1NICAgICAgICAgICAgICAgICBuYSAgICAgICBM S1cgICAgbmENICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBFUw0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NNC4gTU0vUk8gICAgICAgICAgIG5hICAgICAgIExLVyAgICAgTEtXDSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRVMgICAgICAgICAgRVMNLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDTUuQS4gU00vTU0gICAgICBTTyAgICAgIExLVyAgICAgTEtXDSAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRFUyAgICAgICBURVMNLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDTUuQi4gIFNNL01NICAgICAgbmEgICAgICBMS1cgICAgIExLVw0gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBFUyAgICAgICAgICBFUw0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N DTQuMiAgSW1wcm92aW5nIENvbnNpc3RlbmN5IHRocm91Z2ggQ29vcGVyYXRpb24NDUl0IGlzIHBv c3NpYmxlIGZvciBhIHNldCBvZiBhcHBsaWNhdGlvbnMgdG8gY29vcGVyYXRlIHRvIHByb3ZpZGUg aGlnaGVyIGxldmVscyBvZiBjb25zaXN0ZW5jeSB3aXRoaW4gYSBtdWx0aW1hc3RlciBlbnZpcm9u bWVudCB0aGFuIGlzIGF2YWlsYWJsZSBieSBkZWZhdWx0IGlmDSogdGhleSBoYXZlIGV4Y2x1c2l2 ZSBhY2Nlc3MgdG8gYSBwYXJ0aWN1bGFyIGFyZWEgb2YgdGhlIERJVA0qIG5vbWluYXRlIG9uZSBv ZiB0aGUgRFNBcyBwYXJ0aWNpcGF0aW5nIGFzIGEgbWFzdGVyIGluIHRoZSBtdWx0aW1hc3RlciBh cHByb2FjaCBhcyBhIHByZWZlcnJlZCBtYXN0ZXIuDQ1UaGlzIGFwcHJvYWNoLCBNdWx0aW1hc3Rl ciB3aXRoIFByaW1hcnkgKE1NUCksIGhhcyB0aGUgZm9sbG93aW5nIGNoYXJhY3RlcmlzdGljcyA6 DSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFByZWZlcnJlZCAgICAgTU0gICAgIFJPICAg ICANLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDTYuIE1NUAkgICAgICAgICAgICAgU08gICAgCUxLVyAgICAgTEtX DSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRFUyAgICAg ICAgVEVTICAgICAgDS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0NSW4gdGhpcyBjYXNlLCB0aGVzZSBhcHBsaWNh dGlvbnMgYXJlIGFibGUgdG8gZW5zdXJlIFNpbmdsZSBNYXN0ZXIgbGV2ZWxzIG9mIGNvbnNpc3Rl bmN5IHdpdGhpbiB0aGUgbXVsdGltYXN0ZXIgZW52aXJvbm1lbnQNDTQuMyAgUG9zc2libGUgRnV0 dXJlIERlcGxveW1lbnQgU3RyYXRlZ2llcw0NRm9yIGludGVyZXN0IG9ubHkgYXQgdGhpcyBzdGFn ZSwgdGhlIGZvbGxvd2luZyB0YWJsZSBzaG93cyB0aGUgZXhwZWN0ZWQgZ2FpbnMgZnJvbSB1c2lu ZyBhIHdlaWdodGVkIHZvdGluZyBuZWdvdGlhdGlvbiBwaGFzZSAoV1ZOKSwgYW5kIGFsc28gZnVs bCB3ZWlnaHRlZCB2b3RpbmcgKFdWKSAoU2VjdGlvbnMgMy4zIGFuZCAzLjQpIDoNDSAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFNNICAgICBNTSAgICAgUk8gICAgIA0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NV1ZOCSAgICAgICAgICAgICBuYSAgICAgICAgTEtXICAgICBMS1cNLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DVdWICAgICAgICAgICAgICAgICAgICAgIG5hICAgICAgICBTTyAgICAgICAgIExLVwsgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVEVTDS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAEAAASIwAAEyMAALwnAAC9JwAA4i8AAOMvAAD4RwAA/fn9+f35 /QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAdCKgZtSAkMBG1ICQwHAAQAADkEAAA6BAAASgQAAEsEAACpBQAAqgUAAA8HAAAQBwAAhAgA AIUIAAC5CAAAuggAABYJAAAcCgAAHQoAALAKAABuCwAAZwwAAHQNAAB1DQAAVg4AAFcOAABzDwAA dA8AAI8QAACQEAAAwRAAAMIQAABSEQAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAQAAAB0ABAAAOQQAADoEAABKBAAASwQAAKkFAACqBQAADwcAABAHAACECAAA hQgAALkIAAC6CAAAFgkAABwKAAAdCgAAsAoAAG4LAABnDAAAdA0AAHUNAABWDgAAVw4AAHMPAAB0 DwAAjxAAAJAQAADBEAAAwhAAAFIRAACGEQAAsBEAAOkRAAAXEgAArxIAALASAACJEwAA8BMAAHIU AAA0FQAAkxUAAJQVAAB3FgAArhYAAK8WAACZFwAA0hcAANMXAAALGQAADBkAAL0ZAAC+GQAA4RkA AOIZAADJGwAA2hsAAOsbAAD8GwAA/RsAAKEdAADZHQAACB4AADUeAABiHgAAjx4AALMeAAD3HgAA JB8AAGgfAACMHwAAjR8AANEfAAB1IAAA2yAAAE0hAADfIQAATyIAAFAiAAD3IgAA+CIAABIjAAAT IwAAZCQAAGUlAABAJgAAvCcAAL0nAAAcKQAAHSkAAMopAABIKgAASSoAAFsrAABcKwAADywAABAs AABELAAARSwAAFgtAABZLQAA4i8AAOMvAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAZVIRAACGEQAAsBEAAOkRAAAXEgAArxIAALASAACJEwAA8BMAAHIUAAA0 FQAAkxUAAJQVAAB3FgAArhYAAK8WAACZFwAA0hcAANMXAAALGQAADBkAAL0ZAAC+GQAA4RkAAOIZ AADJGwAA2hsAAOsbAAD8GwAA/RsAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAEAAAAd/RsAAKEdAADZHQAACB4AADUeAABiHgAAjx4AALMeAAD3HgAAJB8AAGgf AACMHwAAjR8AANEfAAB1IAAA2yAAAE0hAADfIQAATyIAAFAiAAD3IgAA+CIAABIjAAATIwAAZCQA AGUlAABAJgAAvCcAAL0nAAAcKQAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAQAAAB0cKQAAHSkAAMopAABIKgAASSoAAFsrAABcKwAADywAABAsAABELAAARSwA AFgtAABZLQAA4i8AAOMvAAAXMAAAGDAAADgwAAA5MAAA9zEAAPgxAABxMgAAcjIAAKIyAACjMgAA SzMAAG8zAACHMwAAmzMAAL8zAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAA AAAAAAEQAAABAAAAHeMvAAAXMAAAGDAAADgwAAA5MAAA9zEAAPgxAABxMgAAcjIAAKIyAACjMgAA SzMAAG8zAACHMwAAmzMAAL8zAABNNAAATjQAAAE1AAAaNQAAMDUAAEY1AABHNQAAfjUAAJA1AAC6 NQAAzzUAAPw1AAD9NQAA2DcAAAM4AAAiOAAARjgAAEc4AADTOAAAwjkAAKE6AACiOgAA1zoAANg6 AABjOwAAejsAAIs7AACeOwAAuzsAANM7AADvOwAAFjwAACw8AACxPQAA5T0AAC4+AABcPgAApT4A ANE+AAAMPwAAVT8AAH8/AACrPwAA9D8AABxAAABUQAAAnUAAAMFAAAD5QAAAQkEAAGdBAACgQQAA 6UEAAOpBAAAZQgAAGkIAALlCAAD2QgAAXkMAAF9DAACyQwAA7UMAADZEAABdRAAAokQAAOtEAADs RAAAZ0UAAGhFAACTRQAAlEUAAFRGAABVRgAAiUYAANJGAAD5RgAAQkcAAK5HAAD3RwAA+EcAAAD9 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAwIQAABfvzMAAE00AABONAAAATUAABo1AAAwNQAARjUAAEc1AAB+NQAAkDUAALo1AADP NQAA/DUAAP01AADYNwAAAzgAACI4AABGOAAARzgAANM4AADCOQAAoToAAKI6AADXOgAA2DoAAGM7 AAB6OwAAizsAAJ47AAC7OwAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAQAAAB27OwAA0zsAAO87AAAWPAAALDwAALE9AADlPQAALj4AAFw+AAClPgAA0T4AAAw/ AABVPwAAfz8AAKs/AAD0PwAAHEAAAFRAAACdQAAAwUAAAPlAAABCQQAAZ0EAAKBBAADpQQAA6kEA ABlCAAAaQgAAuUIAAPZCAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAA AAAAAAABAAAAHfZCAABeQwAAX0MAALJDAADtQwAANkQAAF1EAACiRAAA60QAAOxEAABnRQAAaEUA AJNFAACURQAAVEYAAFVGAACJRgAA0kYAAPlGAABCRwAArkcAAPdHAAD4RwAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAEAAAAWIAAcUAEAH7DQLyCw4D0hsAgHIrAIByOQoAUkkKAFJbAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAASABIACgABAFsADwACAAAAAAAAACQAAEDx/wIAJAAAAAYATgBvAHIAbQBhAGwAAAAC AAAABABtSAkEAAAAAAAAAAAAAAAAAAAAAAAAPABBQPL/oQA8AAAAFgBEAGUAZgBhAHUAbAB0ACAA UABhAHIAYQBnAHIAYQBwAGgAIABGAG8AbgB0AAAAAAAAAAAAAAAAADYAJ0CiAPEANgAAABEAQwBv AG0AbQBlAG4AdAAgAFIAZQBmAGUAcgBlAG4AYwBlAAAABABDShAALAAeQAEAAgEsAAAADABDAG8A bQBtAGUAbgB0ACAAVABlAHgAdAAAAAIAEAAAAC4AQkABABIBLgAAAAkAQgBvAGQAeQAgAFQAZQB4 AHQAAAACABEABwBCKgZtSAkMAAAAAAD4QwAABgAAXgAABAD/////AAQAAPhHAAAlAAAAAAQAAFIR AAD9GwAAHCkAAL8zAAC7OwAA9kIAAPhHAAAmAAAAKAAAACkAAAAqAAAALAAAAC0AAAAuAAAAAAQA AOMvAAD4RwAAJwAAACsAAAAAAAAA6wAAAPYAAADlAgAA8AIAAKMDAACuAwAADgQAABkEAAAYBQAA IgUAAKgLAACzCwAApgwAALEMAADEDAAAzwwAAFQNAABYDQAA4w0AAOcNAAAsDgAAMA4AAIIOAACG DgAA1w4AANsOAAD2DgAAAw8AAJ0QAAChEAAA9RAAAP0QAAAyEgAANhIAACoUAAA2FAAAbRwAAHEc AACjHAAAqxwAAPwcAAAAHQAAfx0AAIMdAACoHQAArB0AAIQeAACIHgAAtx4AAL8eAAAxHwAAPB8A AKAgAACnIAAAoSIAAKUiAAC8JAAAwCQAAMwkAADUJAAA9yQAAP8kAACvJgAAtyYAAAsnAAAXJwAA /SgAAAEpAACbKQAApikAAOIpAADtKQAAQSsAAEUrAACkKwAArysAANwrAADgKwAAHSwAACwsAABZ LQAAYi0AAOAtAADkLQAAkC4AAJsuAACxLgAAvC4AAL8uAADKLgAA+S8AAAQwAABgMAAAaDAAAG4w AAB5MAAAAzEAAA8xAAAyMQAAOzEAAGMyAABuMgAAszIAAL0yAADvMwAA+jMAAC00AAA4NAAAgDQA AIs0AADcNAAA6zQAAFE1AABgNQAA7DYAAPY2AACSNwAAnTcAAKU3AACvNwAAGDgAABo4AABIOgAA SjoAAFM6AABVOgAAwjoAAMQ6AABsOwAAbjsAAHw7AAB+OwAABzwAAAk8AAAYPAAAGzwAAFE8AABT PAAAvTwAAMA8AAD1PAAA+DwAAFM9AABVPQAAYz0AAGY9AACdPQAAnz0AAIE+AACMPgAADD8AABA/ AAAyPwAAPT8AAG4/AAB5PwAAWUAAAFxAAACYQAAAm0AAAE9BAABaQQAA40IAAOVCAAD1QgAA+EIA AFpDAABcQwAA+kMAAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABsA BwAbAAcAGwAHABsABwAcAAcAGwAHABsABwAcAAcAHAAHABwABwAcAAcAGwAHABsABwAcAAcAHAAH ABsABwAcAAcAAAAAADgAAAA6AAAASQAAAJEAAACfAAAADAUAABUFAAAxBQAANAUAAKgGAACvBgAA sgYAALkGAABwBwAAdwcAAGkIAABwCAAAlwoAAKQKAABIDQAAUQ0AAH8PAACIDwAABRQAABEUAAC+ FQAAyRUAAMIWAADlFgAAvxcAAMgXAADJFwAA0hcAANoXAADjFwAA6xcAAPQXAACiGQAAphkAANEZ AADYGQAA0xsAAN4bAAB3HAAAgRwAAE8dAABdHQAAch0AAHYdAAD4HgAACh8AAFggAABjIAAAbyAA AHYgAADmIAAACCEAAHMhAAB9IQAAXCIAAIciAAAQKAAAGigAADgpAABHKQAAECsAAEUrAAAYLAAA LCwAAIcsAACMLAAAgS0AAI4tAAB2LgAAoS4AAEUvAABKLwAATS8AAFgvAABxLwAAey8AAJ0vAACr LwAAeTEAAH0xAADTMwAA1zMAAMw0AADSNAAAojYAALI2AABZNwAAYjcAAGY3AABrNwAAfDcAAIA3 AACNNwAAkTcAAKA3AACkNwAAvTcAAMI3AADVNwAA2TcAAPE3AAD2NwAAGDgAABo4AAA6OQAASzkA AM85AADYOQAANDoAAEM6AACsOgAAuzoAAFk7AABuOwAA+jsAAAk8AABFPAAAUzwAAKU8AACvPAAA 6zwAAPg8AABLPQAAVT0AAJE9AACfPQAA6j0AAPg9AAC7PgAAvz4AAPg+AAAAPwAAoD8AALE/AADQ PwAA4D8AAD1AAABMQAAAjUAAAJtAAABoQQAAdUEAAFBCAABTQgAAc0IAAHxCAADWQgAA5UIAAEJD AABcQwAA+kMAAAQABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAH ABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcA GgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAa AAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoA BwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAH ABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHAP//EAAAAAQAbABlAGcAZwAqAFwA XABwAHIAbwB0AG8AbgBcAGgAbwBtAGUAcwBcAHQAZQBsAHMAdAByAGEAXABwAHIAagBcAG0AbQBc AEwARABVAFAAUABSAH4AMQAuAEQATwBDAAQAbABlAGcAZwApAEMAOgBcAFQARQBNAFAAXABBAHUA dABvAFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABMAEQAVQBQAFAAUgB+ADEALgBh AHMAZAAEAGwAZQBnAGcAKQBDADoAXABUAEUATQBQAFwAQQB1AHQAbwBSAGUAYwBvAHYAZQByAHkA IABzAGEAdgBlACAAbwBmACAATABEAFUAUABQAFIAfgAxAC4AYQBzAGQABABsAGUAZwBnACkAQwA6 AFwAVABFAE0AUABcAEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAEwA RABVAFAAUABSAH4AMQAuAGEAcwBkAAQAbABlAGcAZwApAEMAOgBcAFQARQBNAFAAXABBAHUAdABv AFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABMAEQAVQBQAFAAUgB+ADEALgBhAHMA ZAAMAEEAbABpAHMAbwBuACAAUABhAHkAbgBlACoAQwA6AFwAVABFAE0AUABcAEEAdQB0AG8AUgBl AGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAGwAZAB1AHAAcAByAG8AZgAyAC4AYQBzAGQA DABBAGwAaQBzAG8AbgAgAFAAYQB5AG4AZQAxAEQAOgBcAGEAcABhAHkAbgBlAFwAUAByAG8AagBl AGMAdABzAFwATABEAEEAUAAgAFIAZQBwAGwAaQBjAGEAdABpAG8AbgBcAGwAZAB1AHAAcAByAG8A ZgAyAC4AZABvAGMADABBAGwAaQBzAG8AbgAgAFAAYQB5AG4AZQAxAEQAOgBcAGEAcABhAHkAbgBl AFwAUAByAG8AagBlAGMAdABzAFwATABEAEEAUAAgAFIAZQBwAGwAaQBjAGEAdABpAG8AbgBcAGwA ZAB1AHAAcAByAG8AZgAyAC4AZABvAGMA/0BcXFZUUkxfNzcwQk0xX0YyXFY3NzBDLU01MTEzLVBR SFA1U0ktMQBOZTAyOgB3aW5zcG9vbABIUCBMYXNlckpldCA1U2kvNVNpIE1YIFBTAFxcVlRSTF83 NzBCTTFfRjJcVjc3MEMtTTUxMTMtUFEAAQQABJwAtAATVwEAAQAJAJoLNAhkAAEADwBYAgEAAgAA AAMAAABBNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFBSSVbgEAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAYAAAAAAAQJxAnECcAABAnAAAAAAAAAAAHMAoA//8AAf8AAf8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFxcVlRSTF83NzBCTTFf RjJcVjc3MEMtTTUxMTMtUFEAAQQABJwAtAATVwEAAQAJAJoLNAhkAAEADwBYAgEAAgAAAAMAAABB NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFBSSVbgEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAYAAAAAAAQJxAnECcAABAnAAAAAAAAAAAHMAoA//8AAf8AAf8AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAQABAAAAAQAAAGDp6AAJAAkA AQAAAAAAAAABAAAAAAAAAAIQAAAAAAAAAPhDAABgAAAIAEAAAAMAAABHFpABAAACAgYDBQQFAgME h3oAAAAAAIAIAAAAAAAAAP8AAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAA1 FpABAgAFBQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAzJpAB AAACCwYEAgICAgIEh3oAAAAAAIAIAAAAAAAAAP8AAAAAAAAAQQByAGkAYQBsAAAAIgAEAEEAiBgA ANACAAAAAAAAAAAKZERmtWxEhgAAAAAIAEcAAADVCQAACzgAAAEAHAAAAAAAAAB3AAAAAAAAAAAA AAABAAEAAAABAAAAAAAAAJEjAAAAhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKUGwAe0ALQA gAAyMAAAAAAAAAAAAAAAAAAA00QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//xIAAAAAAAAADQBMAEQAVQBQACAA UAByAG8AZgBpAGwAZQBzAAAAAAAAAAYAZgBvAG8AYgBhAHIADABBAGwAaQBzAG8AbgAgAFAAYQB5 AG4AZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/ AAAEAAIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAHgBAAARAAAAAQAA AJAAAAACAAAAmAAAAAMAAACwAAAABAAAALwAAAAFAAAAzAAAAAYAAADYAAAABwAAAOQAAAAIAAAA 9AAAAAkAAAAMAQAAEgAAABgBAAAKAAAANAEAAAwAAABAAQAADQAAAEwBAAAOAAAAWAEAAA8AAABg AQAAEAAAAGgBAAATAAAAcAEAAAIAAADkBAAAHgAAAA4AAABMRFVQIFByb2ZpbGVzAG8AHgAAAAEA AAAARFVQHgAAAAcAAABmb29iYXIAbx4AAAABAAAAAG9vYh4AAAABAAAAAG9vYh4AAAAHAAAATm9y bWFsAG8eAAAADQAAAEFsaXNvbiBQYXluZQAAbwAeAAAAAgAAADgAaXMeAAAAEwAAAE1pY3Jvc29m dCBXb3JkIDguMAAAQAAAAABqKOsJAAAAQAAAAADsyrtFpL8BQAAAAAA+iqslpb8BAwAAAAEAAAAD AAAA1QkAAAMAAAALOAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAACAAAA AAAAAAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOXCAArLPmuVAEA ABABAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAACYAAAABgAAAKAAAAARAAAAqAAAABcAAACwAAAA CwAAALgAAAAQAAAAwAAAABMAAADIAAAAFgAAANAAAAANAAAA2AAAAAwAAADyAAAAAgAAAOQEAAAe AAAAHgAAAFRlbHN0cmEgUmVzZWFyY2ggTGFib3JhdG9yaWVzAGxlAwAAAHcAAAADAAAAHAAAAAMA AADTRAAAAwAAADEVCAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAABAAAADgAA AExEVVAgUHJvZmlsZXMADBAAAAIAAAAeAAAABgAAAFRpdGxlAAMAAAABAAAAmAAAAAMAAAAAAAAA IAAAAAEAAAA2AAAAAgAAAD4AAAABAAAAAgAAAAoAAABfUElEX0dVSUQAAgAAAOQEAABBAAAATgAA AHsAMQA0AEIAMgA0AEIAOAAwAC0AMQAwADEAQgAtADEAMQBEADQALQBBADAANQAwAC0AMAAwADgA MABDADgANABFADYAOQBGADUAfQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUA AAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAA ABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAA IgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwAAAAtAAAALgAAAC8AAAD+ ////MQAAADIAAAAzAAAANAAAADUAAAA2AAAANwAAADgAAAA5AAAA/v///zsAAAA8AAAAPQAAAD4A AAA/AAAAQAAAAEEAAAD+////QwAAAEQAAABFAAAARgAAAEcAAABIAAAASQAAAP7////9////TAAA AP7////+/////v////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////9SAG8AbwB0ACAARQBuAHQAcgB5 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf////////// AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAQBA66yOlvwFwyGHAJaW/AU4AAACAAAAAAAAAADEAVABh AGIAbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAOAAIA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAA AMUSAAAAAAAAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAABoAAgEFAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAIl4AAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkA bwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQIAAAAEAAAA/////wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADoAAAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMA dQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB//////////// ////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQgAAAAAQAAAAAAAAAQBDAG8A bQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ABIAAgEBAAAABgAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA agAAAAAAAABPAGIAagBlAGMAdABQAG8AbwBsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAFgABAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAcMhhwCWl vwFwyGHAJaW/AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAP7///////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////8BAP7/AwoAAP////8GCQIAAAAAAMAA AAAAAABGGAAAAE1pY3Jvc29mdCBXb3JkIERvY3VtZW50AAoAAABNU1dvcmREb2MAEAAAAFdvcmQu RG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== ------_=_NextPart_000_01BFA527.9D83B3E8-- From owner-ietf-ldup@mail.imc.org Thu Apr 13 06:56:23 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26384 for ; Thu, 13 Apr 2000 06:56:23 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA12331 for ietf-ldup-bks; Thu, 13 Apr 2000 03:24:20 -0700 (PDT) Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA12327 for ; Thu, 13 Apr 2000 03:24:18 -0700 (PDT) Received: from langfjella.Alvestrand.no (langfjella.maxware.no [10.128.1.46]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id MAA06644; Thu, 13 Apr 2000 12:27:44 +0200 Message-Id: <4.3.1.2.20000413112953.0241e9a8@dokka.kvatro.no> X-Sender: hta@dokka.maxware.no X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 13 Apr 2000 11:32:09 +0200 To: "Ed Reed" , , From: Harald Tveit Alvestrand Subject: Re: Draft Minutes for the LDUP WG meeting - UUID Cc: , , , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 16:03 12.04.2000 -0600, Ed Reed wrote: >Harald - > >I've tracked down the ISO/IEC 11578:1996 spec, available from ANSI in >the USA over the web for a mere $280. I'm not amused. You indicated >I need to suck it up and buy the spec so we can verify the reference we'll >be making to it. > >Honestly, I'd rather refer to the OpenGroup document, published online >without charge to the reader, instead. Puullleeezzzz? can anyone help him - library? existing copy? I'm not willing to have normative references to the Open Group quite yet... Harald -- Harald Tveit Alvestrand, EDB Maxware, Norway Harald.Alvestrand@edb.maxware.no From owner-ietf-ldup@mail.imc.org Thu Apr 13 09:45:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01544 for ; Thu, 13 Apr 2000 09:45:12 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA19791 for ietf-ldup-bks; Thu, 13 Apr 2000 05:43:20 -0700 (PDT) Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA19786 for ; Thu, 13 Apr 2000 05:43:18 -0700 (PDT) Received: from langfjella.Alvestrand.no (langfjella.maxware.no [10.128.1.46]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id OAA11432; Thu, 13 Apr 2000 14:46:54 +0200 Message-Id: <4.3.1.2.20000413143534.025c5008@dokka.kvatro.no> X-Sender: hta@dokka.maxware.no X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 13 Apr 2000 14:46:07 +0200 To: "John Strassner" , From: Harald Tveit Alvestrand Subject: Re: Fw: I-D ACTION:draft-langer-ldup-mdcr-00.txt Cc: , , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <028501bfa3ec$b7c00f90$41b444ab@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:32 11.04.2000 -0700, John Strassner wrote: >The questions on the floor that this draft addresses are: > > 1) is the requirements document as currently written > too vague? That is, should we delay sending it to > IETF last call? Please read sections 1 and 3 of > this draft to answer this question. The only thing that addresses consistency of the type Albert is bothered about (from what I read in his draft) in the current requirements document is: 6.12 Multiple LDAP changes to a single server: If transactional consistency is propagated during replication, then multiple LDAP changes submitted to a single server SHOULD BE treated as a single 'atomic unit of work'. I agree with Albert that the consistency requirements are glossed over quite quickly in the current requirements doc; however, Albert's draft gives a solution only for a particular type of inconsistency: Multiple changes to unconnected attribute sets of an LDAP entry. > 2) should we add this draft as another possible > conflict resolution method, or should we replace > URP with this draft, or should URP stay as the > only method of conflict resolution. My current view is that URP gives you a directory with a certain consistency model. The requirements doc talks about a range of consistency models; somewhere on that scale is URP; somewhere else is Albert's draft. Unfortunately, I think both examples fall within "Model 2" of the requirements document, which is not fine-grained enough to show criteria whereby the two can be differentiated. Neither draft addresses inter-entry consistency, such as the case where two persons swap telephone numbers, with multiple persons trying to update the directory with this info - both procedures can lead to a situation where both persons have the same telephone listed. The important thing is IMHO documenting IN DETAIL what consistency the procedures guarantee; the requirement that the procedure proposals do should be in the requirements document. Apart from that, I think requirements are ready to go. Harald -- Harald Tveit Alvestrand, EDB Maxware, Norway Harald.Alvestrand@edb.maxware.no From owner-ietf-ldup@mail.imc.org Thu Apr 13 11:02:32 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04044 for ; Thu, 13 Apr 2000 11:02:31 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA21451 for ietf-ldup-bks; Thu, 13 Apr 2000 07:05:35 -0700 (PDT) Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA21447 for ; Thu, 13 Apr 2000 07:05:33 -0700 (PDT) Received: from [192.168.110.9] (workstation1.swip.net [130.244.254.1]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id QAA09779; Thu, 13 Apr 2000 16:08:25 +0200 (MET DST) Mime-Version: 1.0 X-Sender: paf@nix.swip.net (Unverified) Message-Id: In-Reply-To: <4.3.1.2.20000413112953.0241e9a8@dokka.kvatro.no> References: <4.3.1.2.20000413112953.0241e9a8@dokka.kvatro.no> Date: Thu, 13 Apr 2000 15:22:50 +0200 To: Harald Tveit Alvestrand , "Ed Reed" , , From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: Draft Minutes for the LDUP WG meeting - UUID Cc: , , Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:32 AM +0200 4/13/00, Harald Tveit Alvestrand wrote: >can anyone help him - library? existing copy? >I'm not willing to have normative references to the Open Group quite yet... I have no idea. I can not personally. paf From owner-ietf-ldup@mail.imc.org Thu Apr 13 16:51:03 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13726 for ; Thu, 13 Apr 2000 16:51:02 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA29448 for ietf-ldup-bks; Thu, 13 Apr 2000 13:14:27 -0700 (PDT) Received: from etrn.xmission.com (root@etrn.xmission.com [198.60.22.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA29444 for ; Thu, 13 Apr 2000 13:14:25 -0700 (PDT) Received: from [166.70.104.61] (helo=mail.oncalldba.com) by etrn.xmission.com with smtp (Exim 2.12 #1) id 12fq41-00047P-00 for ietf-ldup@imc.org; Thu, 13 Apr 2000 14:18:09 -0600 Received: from RMINC_DOM-Message_Server by mail.oncalldba.com with Novell_GroupWise; Thu, 13 Apr 2000 14:16:47 -0600 Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Thu, 13 Apr 2000 14:16:39 -0600 From: "Ed Reed" To: , , , , Cc: , , Subject: All call - ISO/IEC 11578:1996 - Remote Procedure Calls Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id NAA29445 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Anyone out there have access to a copy of this ISO document? Could you contact me if you do - so we can verify the document is the correct normative reference for the UUID we need for LDUP? Thanks, Ed ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.OnCallDBA.COM >>> Patrik Fältström 04/13/00 07:22AM >>> At 11:32 AM +0200 4/13/00, Harald Tveit Alvestrand wrote: >can anyone help him - library? existing copy? >I'm not willing to have normative references to the Open Group quite yet... I have no idea. I can not personally. paf From owner-ietf-ldup@mail.imc.org Fri Apr 14 21:59:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17739 for ; Fri, 14 Apr 2000 21:59:02 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA11385 for ietf-ldup-bks; Fri, 14 Apr 2000 18:08:52 -0700 (PDT) Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA11373 for ; Fri, 14 Apr 2000 18:08:50 -0700 (PDT) Received: from software.com ([207.19.203.220]) by mta1biz.bizmailsrvcs.net with ESMTP id <20000415011200.UOXS851310.mta1biz.bizmailsrvcs.net@software.com> for ; Fri, 14 Apr 2000 20:12:00 -0500 Message-ID: <38F7C1DD.C57DCB71@software.com> Date: Fri, 14 Apr 2000 18:11:57 -0700 From: sanjay jain Organization: Software.Com X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ldup@imc.org Subject: globally unique identifiers .. ?? 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 LDAP Replication Architecture draft has: " 4.4 Unique Identifiers [snip] 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. " Is the algorithm to generate unique identifiers *yet* defined in any of the LDUP docs ? If not, in which document will it be defined in future ? thanks sanjay From owner-ietf-ldup@mail.imc.org Fri Apr 14 22:27:15 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17882 for ; Fri, 14 Apr 2000 22:27:14 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA18372 for ietf-ldup-bks; Fri, 14 Apr 2000 18:47:27 -0700 (PDT) Received: from ps2.walltech.com (ps2.walltech.com [207.5.77.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA18365 for ; Fri, 14 Apr 2000 18:47:26 -0700 (PDT) Received: from dtasi1 (null@demeter.veritas.com [204.177.156.26]) by ps2.walltech.com (8.10.0/8.10.0/walltech-2.10) with SMTP id e3F1pFb14642; Fri, 14 Apr 2000 18:51:15 -0700 (PDT) Message-Id: <3.0.5.32.20000414185107.0092e140@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Fri, 14 Apr 2000 18:51:07 -0700 To: sanjay jain , ietf-ldup@imc.org From: Bruce Greenblatt Subject: Re: globally unique identifiers .. ?? In-Reply-To: <38F7C1DD.C57DCB71@software.com> 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 believe that Ed Reed is collecting donations so that he can include a reference to the ANSI document that has the algorithm to be used. I remember years ago I had to pay something like $100 for a five page document that described language codes (but as a bonus, it came in French and English)... Bruce At 06:11 PM 4/14/2000 -0700, sanjay jain wrote: >LDAP Replication Architecture draft has: > >" >4.4 Unique Identifiers > >[snip] >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. >" > >Is the algorithm to generate unique identifiers *yet* defined in any >of the LDUP docs ? If not, in which document will it be defined >in future ? > >thanks >sanjay > > ============================================== Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com From owner-ietf-ldup@mail.imc.org Mon Apr 17 01:55:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20109 for ; Mon, 17 Apr 2000 01:55:25 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA20496 for ietf-ldup-bks; Sun, 16 Apr 2000 22:09:36 -0700 (PDT) Received: from etrn.xmission.com (root@etrn.xmission.com [198.60.22.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA20491 for ; Sun, 16 Apr 2000 22:09:31 -0700 (PDT) Received: from [166.70.104.61] (helo=mail.oncalldba.com) by etrn.xmission.com with smtp (Exim 2.12 #1) id 12h3qj-00022B-00 for ietf-ldup@imc.org; Sun, 16 Apr 2000 23:13:29 -0600 Received: from RMINC_DOM-Message_Server by mail.oncalldba.com with Novell_GroupWise; Sun, 16 Apr 2000 23:11:56 -0600 Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Sun, 16 Apr 2000 23:11:27 -0600 From: "Ed Reed" To: , , Subject: Re: globally unique identifiers .. ?? 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 ns.secondary.com id WAA20493 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Actually, this one is $280 or so... Sanjay - the UUID we're attempting to reference is the one used by DCE, by IDL, by Microsoft, and codified in the ISO version of the RPC mechanism memorialized in ISO 11578:1996 (which is the document that costs $280 to obtain). We'd like to make the normative reference to the ISO document, rather than to an Open Group web URL that documents the same thing in an earlier motif (no pun intended). Ed ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.OnCallDBA.COM >>> Bruce Greenblatt 04/14/00 07:51PM >>> I believe that Ed Reed is collecting donations so that he can include a reference to the ANSI document that has the algorithm to be used. I remember years ago I had to pay something like $100 for a five page document that described language codes (but as a bonus, it came in French and English)... Bruce At 06:11 PM 4/14/2000 -0700, sanjay jain wrote: >LDAP Replication Architecture draft has: > >" >4.4 Unique Identifiers > >[snip] >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. >" > >Is the algorithm to generate unique identifiers *yet* defined in any >of the LDUP docs ? If not, in which document will it be defined >in future ? > >thanks >sanjay > > ============================================== Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com From owner-ietf-ldup@mail.imc.org Tue Apr 25 03:53:14 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06935 for ; Tue, 25 Apr 2000 03:53:13 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA19738 for ietf-ldup-bks; Tue, 25 Apr 2000 00:18:15 -0700 (PDT) Received: from infidel.boolean.net (root@router.boolean.net [198.144.206.49]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA19731 for ; Tue, 25 Apr 2000 00:18:14 -0700 (PDT) Received: from gypsy (root@infidel.boolean.net [198.144.202.241]) by infidel.boolean.net (8.9.3/8.9.3) with SMTP id HAA14289; Tue, 25 Apr 2000 07:22:39 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <3.0.5.32.20000425092133.009463f0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 25 Apr 2000 09:21:33 +0200 To: "Ed Reed" From: "Kurt D. Zeilenga" Subject: Re: LDAP Subentry and naming 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 12:46 AM 3/30/00 -0700, Ed Reed wrote: >During the LDUP discussion of the LDAP Subentry draft >the matter of naming attributes came up again, and we need to settle what the draft needs to say. > >Mark Wahl notes that some vendors have objected that CN is a poor choice for naming ldapSubEntry entries in the directory. Since they'll not be visible to users and administrators, unless specifically requested, they'll be in a position to cause mysterious naming clashes with other entries named by CN. The example being that if an ldapSubEntry exists with the name CN=fred, and an administrator attempts to create a person with CN=fred, the administrator will likely get a "duplicate entry name" like error (there's already an entry with the name CN=fred), but the administrator won't see the subentry. > >Since many ldapSubEntry entries will be created automatically by software in the operation of the directory, it's reasonable to name them something that won't cause such mysterious seeming errors as the one described above. > >There might be several possible solutions: > >1) define a new attribute, say ldapSE, of type DirectoryString, with which ldapSubEntry entries may be named. I rather not introduce a new attribute solely to name subentries. >2) leave supplying of the naming attribute to developers who use an ldapSubEntry class to hold their information - this seems troublesome, as the ldapSubEntry class is a STRUCTURAL class, meaning that SOME naming rule is likely to be required, which could get in the way of subsequent users; An alternative would be to define ldapSubEntry as ABSTRACT and leaving naming to definers of structural subclasses. ( X NAME 'ldapSubEntry' ABSTRACT DESC 'subentry abstract class' ) Of course, this leaves the name conflict issues with the structural subclasses... >3) punt, and leave it the way X.500 defines it, and leave experiments surrounding solving this problem to future innovators. >Option 1 takes ldapSubEntry further and further away from the X.500 definition. That's not a problem to the author, if that's desireable because we've learned a change to the X.500 model is warranted. > >Option 2 seems, to me, to take us toward makeing ldapSubEntry an AUXILIARY class itself, instead of a STRUCTURAL class, but I confess I don't understand the nuances being navigated by the X.500 vendors in the room. At any event, this would be an even more serious diversion from the original X.500 model Subentry class definition, wouldn't it? - is that a problem? I think AUXILIARY is a bad choice as a subentry is a subentry and an entry is an entry and this must be establish when the entry is instantiated. Use of AUXILIARY would allow for an entry to be changed into a subentry and vice versa. My suggestion: Define LDAPsubentry as STRUCTURAL with MUST 'cn' but state that naming with attributes other than CN is allowed.