From owner-ietf-ldup@mail.imc.org Sun Mar 2 13:57:50 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16147 for ; Sun, 2 Mar 2003 13:57:48 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h22IpgN13520 for ietf-ldup-bks; Sun, 2 Mar 2003 10:51:42 -0800 (PST) Received: from almso2.proxy.att.com (almso2.att.com [192.128.166.71]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h22IpfY13516 for ; Sun, 2 Mar 2003 10:51:41 -0800 (PST) Received: from qsun.mt.att.com ([135.16.12.1]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with SMTP id h22IpSWx029610; Sun, 2 Mar 2003 13:51:28 -0500 (EST) Received: by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id NAA15032; Sun, 2 Mar 2003 13:51:27 -0500 Date: Sun, 2 Mar 2003 13:51:27 -0500 Message-Id: <200303021851.NAA15032@qsun.mt.att.com> From: rvh@qsun.mt.att.com (Richard V Huber) To: internet-drafts@ietf.org Subject: New vesion of draft-ietf-ldup-infomod Cc: ietf-ldup@imc.org Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Drafts Editor - Please publish the attached as draft-ietf-ldup-infomod-06.txt. LDUP - This is a re-issue of the most recent version of infomod. The authors have been changed to reflect ongoing work and the previous authors have been added to the Acknowledgements. Rick Huber --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- Internet Draft Richard Huber Document: draft-ietf-ldup-infomod-06.txt AT&T Laboratories Expires: September 2003 John McMeeking IBM Ryan Moats Lemur Networks March 2003 LDUP Replication Information Model draft-ietf-ldup-infomod-06.txt . Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft expires March, 2002. . Abstract [LDUP Model] describes the architectural approach to replication of LDAP directory contents. This document describes the information model and schema elements which support LDAP Replication Services which conform to [LDUP Model]. Directory schema is extended to provide object classes, subentries, and attributes to describe areas of the namespace which are under common administrative authority, units of replication (i.e., subtrees, or partitions of the namespace, which are replicated), servers which hold replicas of various types for the various partitions of the namespace, which namespaces are held on given servers, and the progress of various namespace management and replication operations. Among other things, this knowledge of where Huber, et al Expires September 2003 [Page 1] LDUP Information Model directory content is located will provide the basis for dynamic generation of LDAP referrals for clients who can follow them. The controlling framework by which the relationships, types, and health of replicas of the directory content will be defined so that, as much as possible, directory content is itself used to monitor and control the environment. Security information, including access control policy identifiers and information will be treated as directory content by the replication protocols when specified by the LDAPEXT group. The information model will describe required and optional house- keeping duties for compliant systems to implement, such as garbage collection of deleted objects, reconciliation of moved and renamed objects, update sequencing and transaction bracketing of changes, etc. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. The sections below reiterate these definitions and include some additional ones. Huber, et al Expires September 2003 [Page 2] LDUP Information Model . Table of Contents 1. Status of this Memo............................................1 2. Abstract.......................................................1 3. Table of Contents..............................................3 4. Recent document changes........................................5 5. Introduction...................................................7 5.1. Scope.......................................................7 5.2. Terms and Definitions.......................................7 6. Data design....................................................7 7. Directory Knowledge............................................7 8. Schema.........................................................8 8.1. Data Structure Definitions..................................8 8.1.1. LdapChangeSequenceNumber..................................9 8.2. Attribute Definitions......................................10 8.2.1. supportedReplicationProtocols............................10 8.2.2. replicaContextRoots......................................10 8.2.3. replicaSubentries........................................11 8.2.4. attributeExclusionFilter.................................11 8.2.5. attributeInclusionFilter.................................12 8.2.6. replicaURI...............................................12 8.2.7. replicationStatus........................................12 8.2.8. replicaType..............................................13 8.2.9. updateVector.............................................14 8.2.10. replicaSecondaryURI......................................14 8.2.11. lostAndFoundEntryDN......................................15 8.2.12. replicaOnline............................................15 8.2.13. replicaDN................................................15 8.2.14. replicationMechanismOID..................................15 8.2.15. replicationCredentialsDN.................................16 8.2.16. replicationScheduleDN....................................16 8.2.17. updateVectorTrigger......................................16 8.2.18. secondsToWaitDefault.....................................17 8.2.19. secondsToWait1...........................................18 8.2.20. attrReplicationGroup1....................................18 8.2.21. secondsToWait2...........................................18 8.2.22. attrReplicationGroup2....................................19 8.2.23. scheduleTimePeriod.......................................19 8.2.24. scheduleMonthOfYearMask..................................19 8.2.25. scheduleDayOfMonthMask...................................19 8.2.26. scheduleDayOfWeekMask....................................20 8.2.27. scheduleTimeOfDayMask....................................20 8.2.28. scheduleLocalOrUtcTime...................................20 8.3. Class Definitions..........................................20 8.3.1. ReplicationContext.......................................20 8.3.2. replicaSubentry..........................................21 Huber, et al Expires September 2003 [Page 3] LDUP Information Model 8.3.3. replicaAgreementSubentry.................................22 8.3.4. replicaEventSchedule.....................................24 8.3.5. replicaTimeSchedule......................................25 9. Semantics of the information model............................25 10. Object Identifier Assignments...............................29 11. Security Considerations.....................................30 12. Copyright Notice............................................31 13. Acknowledgements............................................32 14. Authors' Addresses..........................................32 Huber, et al Expires September 2003 [Page 4] LDUP Information Model . Recent document changes Changes in this version - Fixed OID values to have correct prefix: 2.16.840.1.113719.1.142 - Fixed formatting to avoid strange single quote characters in text formatted file - Changed name of attrs1 and attrs2 to attrReplicationGroup1 and attrReplicationGroup2 - Made obsolete timeScheduledSubentry and eventScheduledSubentry - Re-based replicaSubEntry and other object classes on subentry schema from draft-zeilenga-ldap-subentry-00.txt - Clarified that root DSE attribute replicaSubentries should be automatically updated on both add and delete of these entries Changes made to previous revisions - Made obsolete replicaSubEntry and replicaAgreementSubentry object classes - Defined replacement object classes replicaSubEntry2 and replicaAgreementSubentry2 - Defined replicaEventSchedule and replicaTimeSchedule object classes and associated attributes - Defined attributes that must appear in the server's root DSE entry as part of the LDUP information model - Many editorial fixes - Clarified the notion that the updateVector is a replicated attribute and thus, itself, has CSN information for its attribute values - Introduced the notion that replicaAgreementSubentry entries represent constraints to what is, by default, "immediate" replication session initiation - LDAP Schedule Subentry definition is defined. - LDAP Access Point removed in favor of just using the DN of the server holding the replica (so a new syntax isn't required). - LDAP Change Sequence Number syntax eliminated in favor of just calling it a CaseIgnoreString, so new comparison rules aren't required. - Deleted ldapSearchFilter definition from here. Sparse replicas is deferred. Might sparse be supported for single-master configurations (read-only, of course). - Fractional are okay in multi-master configurations, but again, only on read-only replicas. - Changed the naming convention upper-lower case usage to look less weird. - Note: - Consistency discussion - Schema document must clearly indicate that clients can and should inspect the replica subentries to understand the single- master/multi-master nature of the naming context to which they're talking. Huber, et al Expires September 2003 [Page 5] LDUP Information Model - The paradigm change, to distributed data, needs to be exhaustively discussed in the profile documents. How old applications which assume single-master behave or misbehave in a multi-master environment is critical to make clear. Draw examples from SMP pre-emptive programming practices, from DNS vs. host file models, etc. Decisions from wash ietf… - define two simple schema classes - - event driven historesis buckets, and cron-like thing. Then, the replica has a single value pointer to a schedule. More schedule things can be defined in the future. - Create attribute ReplicaURI to provide service access point for that replica. No DSA entry requirement. - Replica id table discussion should move to protocol spec. - Decisions from Adelaide - Follow up with Chris Harding about GUID - Forget trying to define a schedule class, and just define a dn reference to the policy, and leave the policy element itself to implementations and future documentation To do: - verify LDUP OID number(s) with Novell - verify all OIDs assigned - verify all OIDs documented at the end of the document Huber, et al Expires September 2003 [Page 6] LDUP Information Model . Introduction .1. Scope This document describes schema of subentries representing replicas, replication agreements and their dependencies. Management and status schema elements may be defined if there is sufficient consensus. Semantic interpretation of schema elements, including any special handling expectations are to be provided here. .2. Terms and Definitions Definitions are provided in [LDUP Requirements], and may be reproduced here for the convenience of the reader. . Data design As described in [LDUP Model], knowledge of replicated portions of the directory information tree (DIT) is stored in the directory itself. An auxiliary class is defined to designate containers, or nodes, in the DIT which are the root-most, or base, of replication contexts. Directory subentries [LDAP Subentry] are used to hold information about replicas and replica agreements. In defining the replication agreement data model, describing the constraints under which replication between two replicas will occur, this document describes only the least set of information necessary to ensure interoperability between implementations. The specification of complex replication agreements and constraints is better served by usage of the emerging "policy model" [Policy schema]. Interoperable policies for replication agreements is left as a follow-on work effort. . Directory Knowledge Information about what replicas exist, what they contain, their types, where they are stored, and how they may be contacted inevitably provides the basis for distributed directory knowledge. As namespaces from stand-alone servers are inter-connected with one another, this replica information can and will be used by name resolution operations to locate servers holding copies of specific objects, and to optimize distributed searches which span multiple Naming Contexts. However, the focus of this document is NOT to fully enable such distributed directory uses. Instead, we are focused on how portions of the namespace (Directory Information Tree - DIT) may be replicated, and how those replicas are configured and related to one another via Replication Agreements. Huber, et al Expires September 2003 [Page 7] LDUP Information Model As such, the following high level description (from [LDUP Model]) of the information model envisioned is provided as reference for the reader before presenting the detailed specifications. Generally, the DSE Naming Context attribute of an LDAPv3 server names the Naming Contexts for which there are replicas on that server. The Replication Context Auxiliary Class (replicationContext) is added to container objects which may have separately defined replication policy. Immediately subordinate to a Replication Context object are the Replica Subentry containers which identify where the identified replica resides (i.e., its LDAP Access Point), its type (Primary, Updateable, ReadOnly), if it is sparse, the LDAP search filter which defines what object classes it holds, and if it is fractional, the attributes it does or does not hold. Immediately subordinate in the namespace to a Replica Subentry are Replication Agreement leaf entries which each identify another Replica, the scheduling policy for replication operations (including times when replication is to be performed, when it is not to be performed, or the policies governing event-driven replication initiation). These Replication Agreement subentries are used to specify constraints on when the replica will supply what changes to the "pointed to" other replica, as either the replication initiator or responder. Replication Agreement subentries are not defined to cover the following advanced policy characteristics: - when a replica would allow consumers to request a replication session - when a replica would allow suppliers to start a replication session - when a replica would request a replication session from a supplier. These advanced policy specifications imply the specification of complex replication agreements and constraints. This is better served by usage of the emerging "policy model" [Policy schema]. Interoperable policies for replication agreements is left as a follow-on work effort. . Schema .1. Data Structure Definitions For the purposes of defining the encoding rules for attribute structures, the BNF definitions in section 4.1 of [RFC2252] will be used. They are based on the BNF styles of [RFC822]. Huber, et al Expires September 2003 [Page 8] LDUP Information Model To avoid requiring new syntax support to be added unnecessarily to existing LDAPv3 directory service implementations (and the accompanying matching rules, etc. they would entail), a string encoding is defined for ldapChangeSequenceNumber which can use CaseIgnoreString matching rules for ordering and equality. .1.1. LdapChangeSequenceNumber ( 1.3.6.1.4.1.1466.115.121.1.TBD DESC 'LDAP Change Sequence Number' ) Values in this syntax are encoded according to the following BNF. Note there MUST NOT be any white space separators, unless they are in replicaID, which must be encoded according to the instructions below. This encoding is specified so that the CaseIgnoreString equality and ordering rules will work correctly when replicaNumber is used. When replicaID is used, CaseIgnoreString comparison rules will not work unless each replicaID is exactly the same length with no padded white spaces (because CaseIgnoreString suppresses duplicate adjacent white space when it compares two strings). LDAPChangeSequenceNumber = GeneralizedZTime "#" \ S1 "#" replicaID "#" S2 GeneralizedZTime = yyyy | mm | dd | hh | mi | ss | "Z" yyyy = dddd mm = dd dd = dd hh = dd mi = dd ss = dd replicaID = dstring S1, S2 = numericstring The GeneralizedTime is used as described (cf. [X680] section 39.3 case b) without separators or white space, and representing a coordinated universal time (i.e., Greenwich Mean Time, or GMT). All times referenced by this syntax MUST be normalized to GMT - no local times, nor time zone offsets are permitted. To simplify comparisons of two CSNs, the "Z" MUST be the UTF-8 capital-Z character. The ReplicaID represents the specific Replica of this Naming Context where the event associated with this LDAPChangeSequenceNumber Huber, et al Expires September 2003 [Page 9] LDUP Information Model occurred. Note that in actual transfer, the replicaID MAY be represented by a number which is associated with the entryUUID of the replicaSubEntry associated with the replica. (see the specification of the replicaIDTable in [LDUP Update Protocol]). When associated with an item of information within a replica, the replicaID should be traceable to the entryUUID of the replicaSubEntry associated with the replica on which the modification was made. This allows for compressed internal storage of change sequence numbers while still ensuring that change sequence numbers will be universally unique regardless of the replication context from which they were first produced. S1 and S2 are sequence numbers which are used to order two events with the same Generalized Time and replicaID. In order to use string matching rules for equality and ordering with values with this encoding, the length of each field must be consistent. Thus, all instances of S1 MUST be represented with the same number of digits, using leading zeros as necessary. The same with S2 and replicaID. .2. Attribute Definitions .2.1. supportedReplicationProtocols ( 2.16.840.1.113719.1.142.4.x NAME 'supportedReplicationProtocols' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 EQUALITY caseIgnoreMatch DESC 'set of OIDs which represent the (set of) protocols supported by this server' ) This attribute is added to the root DSE entry of servers which support replication as defined by [LDUP Model]. .2.2. replicaContextRoots ( 2.16.840.1.113719.1.142.4.x NAME 'replicaContextRoots' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch DESC 'names of the roots of all replicated areas (replication contexts that are held on this server.' ) This attribute is added to the root DSE of the servers which support replication as defined by [LDUP Model]. For every replication context defined on this server, a value is found for this attribute in the root DSE. The replicaContextRoots attribute is multi-valued of syntax distinguished name (DN) which indicates to readers that a server holds a copy (replica) of the Replication Context named. Servers implementing this specification MUST include this attribute in their root DSE, and populate the attribute with the distinguished names of the base entries of each Replication Context held on that server. When replicas are added to a server, servers MUST add the Huber, et al Expires September 2003 [Page 10] LDUP Information Model name of the new Replication Context base entry to this root DSE attribute. Clients wishing to know what replicas a server holds may read this root DSE attribute for a complete list of local replicas. When replicas are removed from the server, servers MUST remove the name of the unavailable replica from this root DSE attribute. .2.3. replicaSubentries ( 2.16.840.1.113719.1.142.4.x NAME 'replicaSubentries' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch DESC 'names of all replicaSubEntry entries that correspond to the replicas on this server. This is contrasted with the replicaContextRoots which notes the replication contexts, but not the replicaSubEntry sub-entries for this server within the replication context' ) This attribute in the root DSE entry names the replicaSubEntry entries that correspond to the replicas that are held on "this" server. This is slightly different than the replicaContextRoots root DSE entry attribute which lists the replication contexts held on this server. The replicaSubentries attribute indicates "this" server's replicaSubentry entry within each replication context. When replicas are defined on the server, servers MUST add the name of the replicaSubEntry representing "this" server to this root DSE attribute. When replicas are removed from the server, servers MUST remove the name from this root DSE attribute if a value exists in this root DSE attribute. .2.4. attributeExclusionFilter ( 2.16.840.1.113719.1.142.4.1 NAME 'attributeExclusionFilter' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) The attributeExclusionFilter is intended to contain a list of attributes in the form of an AttributeDescriptionList as described in section 4.5.1. Search Request of [RFC2251] with the following interpretation: an empty attributeExclusionFilter means that no attributes are excluded; the special values "*" and "1.1" mean that ALL attributes are excluded. A non-empty attributeExclusionFilter attribute on a replica subentry describes the attributes NOT PRESENT on entries held by that replica. Replicas MUST NOT accept changes for attributes they're not permitted to hold, per the attributeInclusionFilter and attributeExclusionFilter attributes on their replica subentry. Huber, et al Expires September 2003 [Page 11] LDUP Information Model A non-empty attributeExclusionFilter attribute on a replication agreement subentry describes which additional attributes are to be excluded from the updates to be sent from the supplier replica to the consumer replica. .2.5. attributeInclusionFilter ( 2.16.840.1.113719.1.142.4.2 NAME 'attributeInclusionFilter' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) The attributeInclusionFilter is intended to contain a list of attributes in the form of an AttributeDescriptionList as described in section 4.5.1. Search Request of [RFC2251] with the following interpretation: an empty attributeInclusionFilter means that all attributes are included; the special value "*" means that ALL attributes are included; the special value "1.1" is meaningless and is ignored in this usage. A non-empty attributeInclusionFilter attribute on a replica subentry describes the attributes that may be PRESENT on entries held by that replica. Replicas MUST NOT accept changes for attributes they're not permitted to hold, per the attributeInclusionFilter and attributeExclusionFilter attributes on their replica subentry. .2.6. replicaURI ( 2.16.840.1.113719.1.142.4.x NAME 'replicaURI' DESC 'LDAP URLs which indicate how to connect to this replica' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 EQUALITY caseExactMatch USAGE dSAOperation ) The replicaURI attribute is a multi-valued attribute used to list the set of LDAP URLs that should be used to contact the replica for replication sessions. If all URLs in the replicaURL attribute are not contactable, the replicaSecondaryURL attribute values should be used to establish a replication session with the replica. .2.7. replicationStatus (2.16.840.1.113719.1.142.4.3 NAME 'replicationStatus' DESC 'human readable status of last replication attempt' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) The replicationStatus attribute MAY be used to hold a human readable message describing the most recent replication session attempt for a replication agreement. Huber, et al Expires September 2003 [Page 12] LDUP Information Model For example, such a messages might include 1) 9980805162203Z # Success # 2) 19980805162322Z # Failure # Server too busy, try again 3) 19980805170215Z # Failure # Unable to connect to DSA 4) 19980806002301Z # Failure # Authentication failed 5) 19980806003201Z # Failure # lost connection, reset by peer It is suggested, but not required, that the time of a replication attempt (completion, if successful or failure, if not), the result of the attempt, and any additional information about a failure be included in the string message. It is suggested, but not required, that the messages be stored with language tags (English, French, German, Japanese, Chinese, per [LANG TAG]) particularly if multiple translations of the error messages are available to the DSA implementers. Note that this is a single-valued attribute. Sequences of status entries SHOULD be written to log files or other persistent storage, or in multi-valued replication history attributes, but are not specified here. .2.8. replicaType (2.16.840.1.113719.1.142.4.4 NAME 'replicaType' DESC 'Enum: 0-reserved, 1-Primary, 2-Updateable, 3-ReadOnly, all others reserved' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 EQUALITY integerMatch SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) ReplicaType is a simple enumeration, used to identify what kind of replica is being described in a Replica object entry. A ReadOnly replica only accepts LDAP Search operations (to Read entries, list containers, and search for entries). Because no updates ever originate from ReadOnly replicas, they never have changes to send to another replica. However, a ReadOnly replica may be designated a supplier DSA in a replica agreement, if it is simply passing along information it receives from other Updateable replicas about entries and their changes. ReadOnly replicas may be incomplete replicas. An Updateable replica may accept both LDAP Search operations (to read, list, or search entries), as well as modification operations (to add, modify, or delete entries). Huber, et al Expires September 2003 [Page 13] LDUP Information Model The consequences of having incomplete updateable replicas are not fully understood. LDAP DSAs MAY require updateable replicas to be complete replicas. A Primary replica is an Updateable replica, but it is "more special" than other Updateable replicas. When LDAP application want to direct their operations to a single replica, so that the application can be sure that all application LDAP modification (add, delete, modify) operations will be immediately visible to application readers, the Primary replica is a good choice. Such a use would be consistent with High Confidence DAP option [X518]. One such application might be a management application which creates new naming contexts or joins two naming contexts into a single naming context. Another application might be one which creates new replicas, or replication agreements. There SHOULD be only one Primary replica defined for a naming context at any time. If applications, expecting there to be a Primary replica discover, by search or inspection of ReplicaType attributes of the defined Replicas of a naming context, find more than one - - they should realize that something is wrong. There MAY be NO primary replica defined for a naming context. Primary replicas MAY NOT be incomplete replicas. The way in which replicas change their type, as from ReadOnly to Updateable, or Updateable to Primary is outside the scope of this document. Section 5.1 "Replica Type" of [LDUP MODEL] details the permissible combinations of replica types and sparse/fractional replicas. .2.9. updateVector ( 2.16.840.1.113719.1.142.4.6 NAME 'updateVector' SYNTAX 1.3.6.1.4.1.1466.115.121.1.TBD EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch NO-USER-MODIFICATION USAGE dSAOperation ) The attribute updateVector is a multi-valued attribute which contains information for a replica describing the latest changes received by the replica from other replicas. There may be only one ldapChangeSequenceNumber entry from each replica in the updateVector. That is to say, there is a unique value constraint on the ReplicaID component of entries in the list. .2.10. replicaSecondaryURI ( 2.16.840.1.113719.1.142.4.x NAME 'replicaSecondaryURI' DESC 'LDAP URLs which indicate how to connect to this replica' Huber, et al Expires September 2003 [Page 14] LDUP Information Model SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 EQUALITY caseExactMatch USAGE dSAOperation ) The replicaSecondaryURI attribute is a multi-valued attribute used to list the set of LDAP URLs that should be used to contact the replica for replication sessions if all LDAP URLs in the replicaURL attribute are not contactable. .2.11. lostAndFoundEntryDN ( 2.16.840.1.113719.1.142.4.x NAME 'lostAndFoundEntryDN' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch SINGLE-VALUE DESC 'name of the entry under which orphaned entries will be moved during replication update processing by this replica.' ) This attribute indicates the location under which the replica will move orphaned entries that are encountered while performing replication updates. The attribute is single-valued and is specific to each replica. .2.12. replicaOnline ( 2.16.840.1.113719.1.142.4.x NAME 'replicaOnline' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 EQUALITY booleanMatch SINGLE-VALUE DESC 'indicates whether or not the replica will will initiate and/or respond to replication session start requests.' ) This attribute indicates whether the replica is ready and willing to participate in replication sessions with other replicas that are defined as holding the replication context. .2.13. replicaDN ( 2.16.840.1.113719.1.142.4.x NAME 'replicaDN' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch SINGLE-VALUE DESC 'name of the consumer replicaSubentry entry that the replicaAgreementSubentry links to.' ) This attribute is used to link a replicaAgreementSubentry entry (associated with a supplier of replication update information) to the consumer replica that will be contacted by replication sessions constrained by the replicaAgreementSubentry. .2.14. replicationMechanismOID Huber, et al Expires September 2003 [Page 15] LDUP Information Model ( 2.16.840.1.113719.1.142.4.x NAME 'replicationMechanismOID' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 EQUALITY caseIgnoreMatch SINGLE-VALUE DESC 'the OID which represents the specific replication protocol used for replication sessions between the identified supplier and consumer replicas.' ) This attribute identifies the specific replication protocol used for replication sessions between the supplier and consumer replicas associated by the replicaAgreementSubentry entry. This attribute must be a value that is within the set of attribute values for the supportedReplicationProtocols attribute in the root DSE entry. .2.15. replicationCredentialsDN ( 2.16.840.1.113719.1.142.4.x NAME 'replicationCredentialsDN' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch SINGLE-VALUE DESC 'name of a separate entry in the directory tree which contains the credentials information used in identifying the supplier replica to the consumer replica when initiating a replication session.' ) This attribute is used to establish a separate entry in the directory tree that will hold the credentials information that is used to establish the supplier's identity at the consumer when starting a replication session. By placing credentials information in a separate entry, "pointed to" with this attribute, credentials information can be placed in a portion of the directory tree that is not replicated across multiple replicas. .2.16. replicationScheduleDN ( 2.16.840.1.113719.1.142.4.x NAME 'replicationScheduleDN' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch SINGLE-VALUE DESC 'name of an entry which contains the specific information used to establish when replication sessions will be initiated by this replica supplier.' ) This attribute is used to "point to" either a replicaEventSchedule or replicaTimeSchedule entry which describes when replication sessions should be initiated by a replica supplier. If not specified, a default schedule is assumed. See the section describing the replicaAgreementSubentry for more details. .2.17. updateVectorTrigger ( 2.16.840.1.113719.1.142.4.x NAME 'updateVectorTrigger' Huber, et al Expires September 2003 [Page 16] LDUP Information Model SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 EQUALITY booleanMatch SINGLE-VALUE DESC 'indicates whether or not updates made to the replicas updateVector should be treated as updates that cause the secondsToWaitDefault attribute value to be used in determining when to initiate a replication session.' ) This attribute is used to indicate whether or not changes to the replica's updateVector should be included as updates that cause the secondsToWaitDefault attribute value to be used when determining when to initiate replication sessions. If updateVectorTrigger is set to FALSE, then secondsToWaitDefault will not be used when the replica's updateVector is updated. This implies that some other update will need to be performed to the replica before the updated updateVector will be sent via a replication session. If upateVectorTrigger is set to TRUE, then updates to the updateVector will be used in determining when replication sessions should be initiated. Note that setting secondsToWaitDefault to 0 coupled with updateVectorTrigger to TRUE would cause replication sessions to continually "chase themselves", potentially clogging networks with an infinite loop of replication sessions. This combination SHOULD be prevented in implementations. If not specified, the value for updateVectorTrigger is assumed to be FALSE. .2.18. secondsToWaitDefault (2.16.840.1.113719.1.142.4.x NAME 'secondsToWaitDefault' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 EQUALITY integerMatch SINGLE-VALUE DESC 'The number of seconds to wait after an update is made to the replica before initiating a replication session.' NO-USER-MODIFICATION USAGE dSAOperation ) This attribute indicates the number of seconds that a replica should wait after an update is made to the replica before initiating a replication session. If not specified, the value is assumed to be 0. This attribute value is used for updates to all attributes that are NOT specified by either the attrs1 or attrs2 attributes. This attribute is always used for updates made to the replica's updateVector if the updateVectorTrigger attribute is set to TRUE. Huber, et al Expires September 2003 [Page 17] LDUP Information Model .2.19. secondsToWait1 (2.16.840.1.113719.1.142.4.x NAME 'secondsToWait1' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 EQUALITY integerMatch SINGLE-VALUE DESC 'The number of seconds to wait after an update is made to any attributes named in the attrs1 attribute before initiating a replication session.' NO-USER-MODIFICATION USAGE dSAOperation ) This attribute is similar to the secondsToWaitDefault attribute in how it is used. This attribute, however, is used to apply only to the attributes listed in the attrs1 attribute. This allows updates to different attributes to cause replication sessions to be initiated either sooner or later than updates made to other attributes. .2.20. attrReplicationGroup1 ( 2.16.840.1.113719.1.142.4.x NAME 'attrReplicationGroup1' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 EQUALITY caseIgnoreMatch DESC 'the set of attributes that are associated with the secondsToWait1 attribute. When updates are made to any of these attributes on the replica, a replication session will be delayed until after secondsToWait1 seconds have passed.' ) This attribute identifies a set of attributes that are associated with the secondsToWait1 attribute. When secondsToWait1 seconds have passed since an update to any attribute identified in the attrs1 attribute, a replication session will be initiated. .2.21. secondsToWait2 (2.16.840.1.113719.1.142.4.x NAME 'secondsToWait2' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 EQUALITY integerMatch SINGLE-VALUE DESC 'The number of seconds to wait after an update is made to any attributes named in the attrs2 attribute before initiating a replication session.' NO-USER-MODIFICATION USAGE dSAOperation ) This attribute is similar to the secondsToWaitDefault attribute in how it is used. This attribute, however, is used to apply only to the attributes listed in the attrs2 attribute. This allows updates to different attributes to cause replication sessions to be initiated either sooner or later than updates made to other attributes. Huber, et al Expires September 2003 [Page 18] LDUP Information Model .2.22. attrReplicationGroup2 ( 2.16.840.1.113719.1.142.4.x NAME 'attrReplicationGroup2' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 EQUALITY caseIgnoreMatch DESC 'the set of attributes that are associated with the secondsToWait2 attribute. When updates are made to any of these attributes on the replica, a replication session will be delayed until after secondsToWait2 seconds have passed.' ) This attribute identifies a set of attributes that are associated with the secondsToWait2 attribute. When secondsToWait2 seconds have passed since an update to any attribute identified in the attrs2 attribute, a replication session will be initiated. .2.23. scheduleTimePeriod ( 2.16.840.1.113719.1.142.4.x NAME 'scheduleTimePeriod' SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 EQUALITY caseIgnoreMatch SINGLE-VALUE DESC 'the absolute time range over which this time specification is valid.' ) This attribute is patterned after the TimePeriod property identified in RFC 3060 [RFC3060] and [Policy Schema]. Refer to these references for details on the format and interpretation of this attribute. .2.24. scheduleMonthOfYearMask ( 2.16.840.1.113719.1.142.4.x NAME 'scheduleMonthOfYearMask' SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 SINGLE-VALUE DESC 'mask identifying the months of the year during which replication sessions should be performed.' ) This attribute is patterned after the MonthOfYearMask property identified in RFC 3060 [RFC3060] and [Policy Schema]. Refer to these references for details on the format and interpretation of this attribute. .2.25. scheduleDayOfMonthMask ( 2.16.840.1.113719.1.142.4.x NAME 'scheduleDayOfMonthMask' SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 SINGLE-VALUE DESC 'mask identifying the days of the month during which replication sessions should be performed.' ) This attribute is patterned after the DayOfMonthMask property identified in RFC 3060 [RFC3060] and [Policy Schema]. Refer to Huber, et al Expires September 2003 [Page 19] LDUP Information Model these references for details on the format and interpretation of this attribute. .2.26. scheduleDayOfWeekMask ( 2.16.840.1.113719.1.142.4.x NAME 'scheduleDayOfWeekMask' SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 SINGLE-VALUE DESC 'mask identifying the days of the week during which replication sessions should be performed.' ) This attribute is patterned after the DayOfWeekMask property identified in RFC 3060 [RFC3060] and [Policy Schema]. Refer to these references for details on the format and interpretation of this attribute. .2.27. scheduleTimeOfDayMask ( 2.16.840.1.113719.1.142.4.x NAME 'scheduleTimeOfDayMask' SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 EQUALITY caseIgnoreMatch DESC 'mask identifying the times during the day when replication sessions should be initiated.' ) This attribute is patterned after the TimeOfDayMask property identified in RFC 3060 [RFC3060] and [Policy Schema]. Refer to these references for details on the format and interpretation of this attribute. .2.28. scheduleLocalOrUtcTime ( 2.16.840.1.113719.1.142.4.x NAME 'scheduleLocalOrUtcTime' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 EQUALITY integerMatch SINGLE-VALUE DESC 'flag indicating whether or not times in the scheduleTimeOfDayMask are in UTC time or local time.' ) This attribute is patterned after the LocaOrUtcTime property identified in RFC 3060 [RFC3060] and [Policy Schema]. Refer to these references for details on the format and interpretation of this attribute. .3. Class Definitions .3.1. ReplicationContext ( 2.16.840.1.113719.1.142.6.2.2 NAME 'replicationContext' SUP top AUXILIARY ) The replicationContext auxiliary class, when present on an object, indicates the beginning, or root, of a naming context. The naming Huber, et al Expires September 2003 [Page 20] LDUP Information Model context is said to be rooted at the entry with the replicationContext auxiliary class in its list of object classes. The root-most entry of a naming context is the entry with the replicationContext auxiliary class in its list of object classes. Characteristics of the replication topology of a naming context are defined in the replicaSubentry sub-entries associated with the naming context. The attribute accessControlPolicyOID has been removed from here, and should be published as an subentry subordinate to the replicationContext, instead. The attribute nameContextCreationTimestamp used here in previous drafts has been eliminated as redundant. The ldapChangeSequenceNumber associated with the replicationContext value in the list of objectclass attribute values serves the same purpose. .3.2. replicaSubentry ( 2.16.840.1.113719.1.142.6.3.2 NAME 'replicaSubentry-2' SUP subentry STRUCTURAL MUST ( cn $ replicaURI $ replicaType $ lostAndFoundEntryDN $ replicaOnline ) MAY ( attributeExclusionFilter $ attributeInclusionFilter $ replicaSecondaryURI $ description $ updateVector ) ) Entries of type replicaSubentry MUST be named by their cn attribute as defined in [LDAP Subentry]. The attributes attributeExclusionFilter and attributeInclusionFilter, if present, govern which entries and attributes from the local naming context are to be sent (or not sent) to the replica named in replicaDN of replica agreements for this replica. The attributeExclusionFilter names attributes which SHOULD NOT be sent. The attributeInclusionFilter names attributes which SHOULD be sent. The attribute replicaURI contains information in ldapURI format that can be used to contact (i.e., open a connection to) this replica. The replicaSecondaryURI contains the set of ldapURI format addresses that can be used as backup addresses if the replicaURI values cannot be used. Huber, et al Expires September 2003 [Page 21] LDUP Information Model The lostAndFoundEntryDN attribute is single-valued attribute that contains the distinguished name of the lost and found entry under which orphaned entries are placed. The replicaOnline attribute is a Boolean attribute which indicates whether or not this replica will supply and/or accept replication sessions. This attribute can be used to prevent replication sessions from being started before replicaAgreementSubentry entries have been defined. The attribute description contains a human-readable description of the sub-entry. The attribute updateVector contains a set of ldapChangeSequenceNumbers, one for each of the other replicas for this naming context, which records, from this replicas perspective, the last change event received from the other indicated replica. The subtreespecification attribute of the subentry superior object class is used to define the scope of the replication context. Use of the subtreespecification value SHOULD be limited to the base and components of ChopSpecification portions of this attribute. .3.3. replicaAgreementSubentry ( 2.16.840.1.113719.1.142.6.4.2 NAME 'replicaAgreementSubentry-2' SUP subentry STRUCTURAL MUST ( cn ) MAY ( attributeExclusionFilter $ description $ replicaDN $ replicationMechanismOID $ replicationStatus $ replicationCredentialsDN $ replicationScheduleDN ) ) Entries of type replicaAgreementSubentry MUST be named by their cn attribute as defined in [LDAP Subentry]. Entries of this type MUST be placed just below replicaSubentry entries in the directory tree. Name subordination is used to associate a replicaAgreementSubentry with the replicaSubentry representing the supplier of changes for all subordinate replication agreements. The attribute attributeExclusionFilter governs which attributes from the local naming context are to be sent (or not sent) to the replica named in replicaDN. The attributeExclusionFilter names attributes SHOULD NOT be sent. Note there is no attributeInclusionFilter, because the list of attributes that may be sent may not be extended beyond those documented in the attributeInclusionFilter on the replicaSubentry. Processing of allowable changes to be sent is as follows: Huber, et al Expires September 2003 [Page 22] LDUP Information Model 1) the attributeInclusionFilter from the replica subentry defines a set of attributes which SHOULD be sent, less exclusions; 2) the union of attributes excluded by the attributeExclusionFilter from the replicaSubentry and the attributeExclusionFilter from the replicaAgreementSubentry defines a set of attributes which SHOULD NOT be sent; 3) the subtraction of attributes which SHOULD NOT be sent by (2) from the attributes which SHOULD be sent by (1) constitute the set of attributes for which changes MAY be sent. The attribute description contains a human-readable description of the sub-entry. The attribute replicaDN of syntax distinguishedName names another sub-entry of type replicaSubentry to whom changes are to be sent. If there is no value for the replicaDN attribute on a replicaAgreementSubentry, the replicaAgreementSubentry is ignored. Absence of a value may occur briefly when replicas and replica agreements are first being created, or when the replica to which a replica agreement applies is being deleted. The attribute replicationMechanismOID is used to indicate the type of replication protocol that is used between the supplier and consumer. If not specified, the default replication protocol defined in [LDUP Update Replication Protocol] is assumed. The attribute replicationStatus MAY be used to record the most recent result of an attempt to send changes to the replica named in replicaDN, whether success, or if failure, the nature of the problem encountered. The attribute replicationCredentialsDN, if present, names an entry which contains information used to initialize authenticated the LDAP connection between the supplier and consumer. Separating the credentials information from the replicaAgreementSubentry itself allows for this information to be placed outside of the replication context. The attribute replicationScheduleDN, if present, names an entry which governs the schedule for replication attempts. If not present, replication MUST be attempted when there are changes to be sent (i.e. a default replica schedule of type replicaEventSchedule is assumed with secondsToWaitDefault=0 and updateVectorTrigger=FALSE). See Section on replicaEventSchedule for more information about these attributes and their meaning. The subtreespecification attribute of the subentry superior object class is ignored. Huber, et al Expires September 2003 [Page 23] LDUP Information Model .3.4. replicaEventSchedule ( 2.16.840.1.113719.1.142.6.x.1 NAME 'replicaEventSchedule' SUP subentry STRUCTURAL MUST ( cn ) MAY ( description $ updateVectorTrigger $ secondsToWaitDefault $ secondsToWait1 $ attrs1 $ secondsToWait2 $ attrs2 ) ) The replicaEventSchedule object class is used to specify when to initiate replication sessions in terms of the time to wait after an update is made to the supplier replica. The attribute cn is used as the naming attribute for the replicaEventSchedule object class. It is thought that replicaEventSchedule entries would be placed below replicaAgreementSubentry entries but this is not required. The attribute description contains a human-readable description of the sub-entry. The attribute updateVectorTrigger is a Boolean attribute which indicates whether or not the update of the supplier's updateVector attribute should, itself, be used to trigger replication sessions. Since the updateVector is, itself, an attribute, it has CSNs associated with each of its values. Note that these CSNs may be different from the CSNs that are in the attribute values themselves. Thus, it is possible that the update to the updateVector would, itself, need to be treated as an update to be replicated. Indeed, this is necessary in order for "transitive replication" to work. The secondsToWaitDefault attribute is a non-negative integer value. This value indicates the number of seconds to wait after an update is made before starting a replication session. This value is used for all attributes other than those noted in the attrs1 and attrs2 attributes. The secondsToWait1 attribute is similar to the secondsToWaitDefault attribute. This non-negative integer value is used whenever any attribute listed in the attrs1 attribute is updated. The secondsToWait2 attribute is similar to the secondsToWait1 attribute but is associated with the attrs2 attribute. Note that whenever any of these seconds-to-wait time periods has expired, a replication session should be initiated and the full set of information that needs to be replicated should be sent to the consumer replica. This implies that some information would be Huber, et al Expires September 2003 [Page 24] LDUP Information Model replicated before its associated seconds-to-wait time period had expired. The subtreespecification attribute of the subentry superior object class is ignored. .3.5. replicaTimeSchedule ( 2.16.840.1.113719.1.142.6.x.1 NAME 'replicaTimeSchedule' SUP subentry STRUCTURAL MUST ( cn ) MAY ( description $ scheduleTimePeriod $ scheduleMonthOfYearMask $ scheduleDayOfMonthMask $ scheduleDayOfWeekMask $ scheduleTimeOfDayMask $ scheduleLocalOrUtcTime ) ) The replicaTimeSchedule object class is used to specify when to initiate replication sessions based on a scheduled time basis rather than in relation to when updates are made to the supplier replica. The attribute cn is used as the naming attribute for the replicaTimechedule object class. It is thought that replicaTimeSchedule entries would be placed below replicaAgreementSubentry entries but this is not required. The attribute description contains a human-readable description of the sub-entry. The remaining attributes in this object class are patterned after the attributes defined for the policyTimePeriodCondition construct defined in the Policy Core Information Model [RFC3060]. Because the LDAP schema mapping for this portion of the CIM model is not complete at this time, these attributes are defined specifically for this LDUP-related object class. Refer to RFC 3060 for details of the formats for the scheduleTimePeriod, scheduleMonthOfYearMask, scheduleDayOfMonthMask, scheduleDayOfWeekMask, scheduleTimeOfDayMask, and scheduleLocalOrUtcTime attributes. The subtreespecification attribute of the subentry superior object class is ignored. . Semantics of the information model The intent of this information model is to allow for useful and expected operation while requiring a minimum amount of data to be specified. In this spirit, replicaAgreementSubentry entries are treated as "constraints" on when to initiate replication sessions, not "requirements" on being able to initiate replication sessions. To clarify this concept, two examples are provided in this section. Huber, et al Expires September 2003 [Page 25] LDUP Information Model The first example shows the minimal set of information required to get replication going between three replicas: dn: ou=accounting, o=your company objectclass: organizationalUnit objectclass: replicationContext ou: accounting dn: cn=replica1, ou=accounting, o=your company objectclass: subentry objectclass: replicaSubentry-2 cn: replica1 subtreespecification: {} description: replica in location 1 replicaURI: ldap://sys1.yourcompany.com replicaType: 2 lostAndFoundEntryDN: cn=lostAndFound1, o=your company replicaOnline: TRUE dn: cn=replica2, ou=accounting, o=your company objectclass: subentry objectclass: replicaSubentry-2 cn: replica2 subtreespecification: {} description: replica in location 2 replicaURI: ldap://sys2.yourcompany.com replicaType: 2 lostAndFoundEntryDN: cn=lostAndFound2, o=your company replicaOnline: TRUE dn: cn=replica3, ou=accounting, o=your company objectclass: subentry objectclass: replicaSubentry-2 cn: replica3 subtreespecification: {} description: replica in location 3 replicaURI: ldap://sys2.yourcompany.com replicaType: 2 lostAndFoundEntryDN: cn=lostAndFound3, o=your company replicaOnline: TRUE With replicaSubentry entries defined as shown in this first example, replication sessions will be initiated by all replicas whenever an update is made to any attribute within any entries in the replicationContext. The default event schedule will be used which indicates that a replication session is initiated immediately after an update is made to a replica. Further, replication sessions would be initiated to ALL OTHER replicas. As this shows, maximal replication is defined using a minimal amount of configuration. The second example shows how replication sessions can be constrained by replicaAgreementSubentry entries. This example builds on the Huber, et al Expires September 2003 [Page 26] LDUP Information Model data shown in the first example. Assume that the following entries are added to the entries defined in the first example: dn: cn=agreement1->2, cn=replica1, ou=accounting, o=your company objectclass: subentry objectclass: replicaAgreementSubentry-2 cn: agreement1->2 subtreespecification: {} description: Replica agreement constraining replication sessions from replica 1 to replica 2. replicationScheduleDN: cn=schedule1, cn=replica1, ou=accounting, o=your company dn: cn=agreement1->3, cn=replica1, ou=accounting, o=your company objectclass: subentry objectclass: replicaAgreementSubentry-2 cn: agreement1->3 subtreespecification: {} description: Replica agreement constraining replication sessions from replica 1 to replica 3. replicationScheduleDN: cn=schedule1, cn=replica1, ou=accounting, o=your company dn: cn=schedule1, cn=replica1, ou=accounting, o=your company objectclass: subentry objectclass: replicaEventSchedule cn: schedule1 subtreespecification: {} description: schedule that initiates replication one minute after any update (including to the updateVector) is made to the replica. secondsToWaitDefault: 60 updateVectorTrigger: TRUE dn: cn=agreement2->1, cn=replica2, ou=accounting, o=your company objectclass: subentry objectclass: replicaAgreementSubentry-2 cn: agreement2->1 subtreespecification: {} description: Replica agreement constraining replication sessions from replica 2 to replica 1. replicationScheduleDN: cn=schedule2, cn=replica2, ou=accounting, o=your company dn: cn=agreement2->3, cn=replica2, ou=accounting, o=your company objectclass: subentry objectclass: replicaAgreementSubentry-2 cn: agreement2->3 subtreespecification: {} description: Replica agreement constraining replication sessions from replica 2 to replica 3. replicationScheduleDN: cn=schedule2, cn=replica2, ou=accounting, o=your company Huber, et al Expires September 2003 [Page 27] LDUP Information Model dn: cn=schedule2, cn=replica2, ou=accounting, o=your company objectclass: subentry objectclass: replicaEventSchedule cn: schedule2 subtreespecification: {} description: schedule that initiates replication two minutes after any update (including to the updateVector) is made to the replica. secondsToWaitDefault: 120 updateVectorTrigger: TRUE dn: cn=agreement3->1, cn=replica3, ou=accounting, o=your company objectclass: subentry objectclass: replicaAgreementSubentry-2 cn: agreement3->1 subtreespecification: {} description: Replica agreement constraining replication sessions from replica 3 to replica 1. replicationScheduleDN: cn=schedule3, cn=replica3, ou=accounting, o=your company dn: cn=agreement3->2, cn=replica3, ou=accounting, o=your company objectclass: subentry objectclass: replicaAgreementSubentry-2 cn: agreement3->2 subtreespecification: {} description: Replica agreement constraining replication sessions from replica 3 to replica 2. replicationScheduleDN: cn=schedule3, cn=replica3, ou=accounting, o=your company dn: cn=schedule3, cn=replica3, ou=accounting, o=your company objectclass: subentry objectclass: replicaEventSchedule cn: schedule3 subtreespecification: {} description: schedule that initiates replication one minute after any update (including to the updateVector) is made to the replica. secondsToWaitDefault: 60 updateVectorTrigger: TRUE In this example, replication sessions are limited such that they will begin one or two minutes after an update is made to any one replica, depending on the replica on which the update was made. This "constrains" the replication session initiation from the default of "immediate replication" of updates. There are many ways in which the constraints around when to initiate and/or accept replication sessions between two replicas. The information model defined here provides a small set of options. More elaborate policies can be defined and this is left as a future exercise. It is hoped that the work from the Policy workgroup can Huber, et al Expires September 2003 [Page 28] LDUP Information Model offer schema that would support the creation of these complex policies. 0. Object Identifier Assignments The LDUP OID prefix is ID ::= OBJECT IDENTIFIER ldup ID ::= { joint-iso-ccitt(2) country(16) us(840) organization(1) novell(113719) novell-internal-OIDS(1) ldup(142) } The OID assignments defined in this document are: Attributes: attributeExclusionFilter ID ::= 2.16.840.1.113719.1.142.4.1 attributeInclusionFilter ID ::= 2.16.840.1.113719.1.142.4.2 replicationStatus ID ::= 2.16.840.1.113719.1.142.4.3 replicaType ID ::= 2.16.840.1.113719.1.142.4.4 secToWaitClass1 ID ::= 2.16.840.1.113719.1.142.4.5.1 - OBSOLETE secToWaitClass2 ID ::= 2.16.840.1.113719.1.142.4.5.2 - OBSOLETE secToWaitClass3 ID ::= 2.16.840.1.113719.1.142.4.5.3 - OBSOLETE secToWaitClass4 ID ::= 2.16.840.1.113719.1.142.4.5.4 - OBSOLETE secToWaitClass5 ID ::= 2.16.840.1.113719.1.142.4.5.5 - OBSOLETE updateVector ID ::= 2.16.840.1.113719.1.142.4.6 replicaURI ID ::= 2.16.840.1.113719.1.142.4.x replicaSecondaryURI ID ::= 2.16.840.1.113719.1.142.4.x lostAndFoundEntryDN ID ::= 2.16.840.1.113719.1.142.4.x replicaOnline ID ::= 2.16.840.1.113719.1.142.4.x replicaDN ID ::= 2.16.840.1.113719.1.142.4.x replicationMechanismOID ID ::= 2.16.840.1.113719.1.142.4.x replicationCredentialsDN ID ::= 2.16.840.1.113719.1.142.4.x replicationScheduleDN ID ::= 2.16.840.1.113719.1.142.4.x updateVectorTrigger ID ::= 2.16.840.1.113719.1.142.4.x secondsToWaitDefault ID ::= 2.16.840.1.113719.1.142.4.x secondsToWait1 ID ::= 2.16.840.1.113719.1.142.4.x attrReplicationGroup1 ID ::= 2.16.840.1.113719.1.142.4.x secondsToWait2 ID ::= 2.16.840.1.113719.1.142.4.x attrReplicationGroup2 ID ::= 2.16.840.1.113719.1.142.4.x scheduleTimePeriod ID ::= 2.16.840.1.113719.1.142.4.x scheduleMonthOfYearMask ID ::= 2.16.840.1.113719.1.142.4.x scheduleDayOfMonthMask ID ::= 2.16.840.1.113719.1.142.4.x scheduleDayOfWeekMask ID ::= 2.16.840.1.113719.1.142.4.x scheduleTimeOfDayMask ID ::= 2.16.840.1.113719.1.142.4.x scheduleLocalOrUtcTime ID ::= 2.16.840.1.113719.1.142.4.x supportedReplicationProtocols ID ::= 2.16.840.1.113719.1.142.4.x Huber, et al Expires September 2003 [Page 29] LDUP Information Model replicaContextRoots ID ::= 2.16.840.1.113719.1.142.4.x replicaSubentries ID ::= 2.16.840.1.113719.1.142.4.x Object Classes: eventScheduledSubentry ID ::= 2.16.840.1.113719.1.142.6.1 - OBSOLETE nameContext ID ::= 2.16.840.1.113719.1.142.6.2.1 - OBSOLETE replicaSubentry ID ::= 2.16.840.1.113719.1.142.6.3.1 - OBSOLETE replicaAgreementSubentry ID ::= 2.16.840.1.113719.1.142.6.4.1 - - OBSOLETE replicationContext ID ::= 2.16.840.1.113719.1.142.6.2.2 replicaSubEntry-2 ID ::= 2.16.840.1.113719.1.142.6.3.2 replicaAgreementSubEntry-2 ID ::= 2.16.840.1.113719.1.142.6.4.2 eventScheduledSubentry ID ::= 2.16.840.1.113719.1.142.6.1 - OBSOLETE replicaEventSchedule ID ::= 2.16.840.1.113719.1.142.6.x.1 replicaTimeSchedule ID ::= 2.16.840.1.113719.1.142.6.x.1 Note: Object Class OIDs have version numbers, Attribute OIDs don't. 1. Security Considerations Many of the attributes and object classes described in this document should be considered "security sensitive", and protected from unintended modification by LDAP servers. Generally, creating Naming Contexts, Replicas and Replica Agreement entries should only be allowed by directory administrators who are authorized to do so. The values of attributes defined here are intended to control the behavior of the directory service agents, themselves. Unintended modification of their values may result in incomplete replication of data (if ldapSearchFilter or attributeExclusionFilter are changed), inappropriate disclosure of information (if attributeInclusionFilter is changed), or updates may be lost (if updateVector is changed). To avoid depending to much on the ldapAccessPoint values for other replicas, connections between LDAP servers for the purpose of replication MUST ALWAYS be authenticated using an authentication mechanism appropriate for the nature of information to be exchanged. References [LDUP Model] - J. Merrells, E. Reed, U. Srinivisan, "An Abstract Model of LDAP Replication", Internet draft, draft-merrells-ldup- model-01.txt [LDUP Requirements] - R. Weiser, E. Stokes "LDAP Replication Requirements", Internet draft, draft-weiser-replica-req-02.txt, April 1998 Huber, et al Expires September 2003 [Page 30] LDUP Information Model [LDAP Subentry] - - K. Zeilenga, "Subentries in LDAP", Internet draft, draft-zeilenga-ldap-subentry-00.txt, October 2001. [LDUP Update Protocol] - - E. Stokes, G. Good, R. Harrison, "The LDUP Replication Update Protocol", Internet Draft, draft-ietf-ldup- protocol-03.txt [Policy Schema] - J. Strassner, A. Westerinen, E. Ellesson, B. Moore, R. Moats, "Policy Core LDAP Schema", Internet draft, draft- ietf-policy-core-schema-11.txt, May 2001. [RFC822] - - D. Crocker, "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES", August 1982, RFC 822 [RFC2251] - - M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3)", December 1997, RFC 2251 [RFC2252] - - M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", December 1997, RFC 2252 [RFC3060] - - B. Moore, E. Ellesson, J. Strassner, A. Westerinen, "Policy Core Information Model - - Version 1 Specification", February 2001, RFC 3060 [X518] - ITU-T Recommendation X.518 (1997) | ISO/IEC 9594-4:1998, Information Technology - - Open Systems Interconnection - - The Directory: Procedures for Distributed Operation [X680] - ITU-T Recommendation X.680 (1994) | ISO/IEC 8824-1:1995, Information technology - - Abstract Syntax Notation One (ASN.1): Specification of Basic Notation 2. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Huber, et al Expires September 2003 [Page 31] LDUP Information Model This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3. Acknowledgements The authors would like to thank Ed Reed and Tim Han, the authors of the original infomod draft, for all their work. The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 4. Authors' Addresses Richard Huber AT&T Laboratories Email: rvh@att.com John McMeeking IBM Email: jmcmeek@us.ibm.com Ryan Moats Lemur Networks, Inc. Email: rmoats@lemurnetworks.net LDUP Mailing List: ietf-ldup@idc.org Huber, et al Expires September 2003 [Page 32] From owner-ietf-ldup@mail.imc.org Sun Mar 2 13:59:44 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16164 for ; Sun, 2 Mar 2003 13:59:43 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h22Ik4213050 for ietf-ldup-bks; Sun, 2 Mar 2003 10:46:04 -0800 (PST) Received: from almso2.proxy.att.com (almso2.att.com [192.128.166.71]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h22Ik2Y13045 for ; Sun, 2 Mar 2003 10:46:02 -0800 (PST) Received: from qsun.mt.att.com ([135.16.12.1]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with SMTP id h22IjrWx028657; Sun, 2 Mar 2003 13:45:53 -0500 (EST) Received: by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id NAA14728; Sun, 2 Mar 2003 13:45:51 -0500 Date: Sun, 2 Mar 2003 13:45:51 -0500 Message-Id: <200303021845.NAA14728@qsun.mt.att.com> From: rvh@qsun.mt.att.com (Richard V Huber) To: internet-drafts@ietf.org Subject: New version of draft-ietf-ldup-usage-profile Cc: ietf-ldup@imc.org Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Drafts Editor - Please publish the attached as draft-ietf-ldup-usage-profile-04.txt. LDUP - This is part of the LDUP wrap-up work. There are no changes in this version of the draft; we will publish a revised version after the other LDUP drafts are revised. Rick Huber --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- Internet-Draft Richard V. Huber LDAP Duplication/Replication/Update Gerald F. Maziarski Protocols WG AT&T Laboratories Intended Category: Informational Ryan D. Moats Expires: September 2003 Lemur Networks March 2003 General Usage Profile for LDAPv3 Replication draft-ietf-ldup-usage-profile-04.txt Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt. The list of Internet-Drafts Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract Support for replication in LDAP directory systems is often one of the key factors in the decision to deploy them. But replication brings design constraints along with its benefits. We discuss some of the factors that should be taken into consideration when designing a replicated directory system. Both programming and architectural/operational concerns are addressed. Huber, et al Expires September 2003 [Page 1] INTERNET DRAFT Gen'l Usage Profile for LDAP Replication March 2003 Table of Contents 1 Introduction........................................................2 2 Meta-data Considerations............................................3 2.1 Schema Considerations............................................3 2.2 Replication Agreements...........................................4 2.3 Access Control...................................................5 2.4 Change Logs......................................................6 3 Naming Considerations...............................................6 4 Conflict Resolution Considerations..................................7 4.1 Consistent Access after Changes..................................7 4.2 Conflict Resolution in Single-Master Systems.....................8 4.3 Problem Cases....................................................9 4.3.1 Atomicity.....................................................9 4.3.1.1 Locking...................................................9 4.3.1.2 Partitioning..............................................9 4.4 General Principles..............................................10 5 Failover Considerations............................................10 5.1 Common Issues...................................................11 5.2 Single Master Issues............................................11 5.3 Multi-Master Issues.............................................12 6 Other Issues.......................................................13 6.1 Locking.........................................................13 6.2 Backup and Restore..............................................13 7 Impact of Non-LDAP Changes/Constraints.............................14 7.1 Changes Outside of LDAP.........................................14 7.2 Application Triggers............................................15 7.3 Policy Conflicts Across Servers.................................15 8 Security Considerations............................................16 9 Acknowledgements...................................................16 10 References........................................................16 Authors' Addresses...................................................17 Full Copyright Statement.............................................18 1 Introduction As LDAP directories become part of the critical infrastructure for applications maintaining high reliability and availability is significant. Distributed, replicated directories can reduce reliability and capacity problems. However, applications that work well with a single, standalone directory can develop problems in a distributed environment unless both the applications and the environment are carefully designed. Huber, et al Expires September 2003 [Page 2] INTERNET DRAFT Gen'l Usage Profile for LDAP Replication March 2003 While particular areas of concern depend partly on whether the distributed directory is a single-master or multi-master system most concerns that are common to both. This document flags some issues as being specific to either single-master or multi-master directories. Unflagged issues pertain to both. The current replication framework provides no easily separable subset of functions for single-master and multi-master replication, therefor this addresses general issues regarding the deployment of single-master and multi-master directory systems. There may be additional drafts in the future that address specific applications. 2 Meta-data Considerations Any LDAP directory contains meta-data as well as the user data in the directory. Examples of this meta-data include descriptions of the data in the directory (e.g. schema), policies for use of the data (e.g. access controls), and configuration/status information (e.g. replication agreements); this is not an exhaustive list. This meta-data is stored in the directory itself, frequently accessible as regular data or as operational attributes. Issues arise when meta- data stored in the directory is replicated. However, not replicating meta-data also causes issues to arise. 2.1 Schema Considerations If the schema of one or more of the copies of a replica differs from the schema of the other replicas, then there is a possibility of schema mismatch when data is exchanged between them. The schema extensibility feature of LDAP nearly guarantees that replica groups comprised of a heterogeneous mix of systems will not contain homogeneous schema because of directory vendors' built-in extensions. A given directory may not utilize all of the elements of its schema, so schema differences do not always lead to schema mismatches during replication. Schema mismatch issues are further complicated by the possibility of replicating the "subschemaSubentry" itself. Some directories distribute schema changes through that mechanism. Currently there is no standard for LDAP schema representation within the subschemaSubentry. In the absence of such a standard, full schema interoperability is not possible in the IETF sense. Directory designers should establish common schema on all servers holding a replica. Huber, et al Expires September 2003 [Page 3] INTERNET DRAFT Gen'l Usage Profile for LDAP Replication March 2003 The following is a partial list of possible schema mismatches: 1. Object class not defined 2. Structure Rule of an object class 3. Structural vs. Auxiliary in an object class 4. Optional vs. Mandatory attribute in an object class 5. Object identifiers differ on an attribute type or on an object class 6. Type and number of attributes defined in a class 7. Attribute type not defined 8. Base syntax of an attribute type 9. Multi-valued vs. single-valued attribute types 10. Matching rule of an attribute type 11. Naming collisions of attribute type names 12. Attribute name aliasing ("street" vs. "streetAddress" vs. "Strasse") 13. ACL format (and consequently, ACL calculus) (Note: this is being addressed in the ACL model [ACLModel]) Schema mismatches that cause data corruption in one or more of the replicas must result in meta-data (e.g. log entries) in order to comply with Requirement P7 of [ReplicaReq]. However, not all schema differences produce corruption in all circumstances. Some schema differences may have little or no impact on the proper storage of replicated data. However, any time data is added to the directory, replication may result in data corruption due to a schema mismatch. Here are some options for dealing with such potential mismatches: - Use fractional replication to replicate only those attributes that do not have differences - Removal of all schema mismatches. - Use the same schema on all systems The tool described by requirement AM8 of [ReplicaReq] would help designers detect schema conflicts as early as possible. 2.2 Replication Agreements Replication Agreements are central to replication, as they allow configuration of most of the aspects of the replication process, including the triggers for replica cycles (from Requirement M1 in [ReplicaReq]), critical OID information (from Requirement M6 in [ReplicaReq]), and replication process parameters (Requirement M7 in [ReplicaReq]). Through the use of a standard replication agreement Huber, et al Expires September 2003 [Page 4] INTERNET DRAFT Gen'l Usage Profile for LDAP Replication March 2003 schema (Requirement SC2 of [ReplicaReq], [InfoMod]) it is possible to replicate the replication agreement. If a replication agreement includes replication credentials, the agreement should be read protected in the directory and transport of the replication agreement should be encrypted. When replication agreements are themselves distributed via replication, they are subject to same "loose consistency" problems (due to replication delay and deferred conflict resolution) as other data. Even a temporary inconsistency among replication agreements may cause unbalanced replication and further inconsistency. As "multi-mastering" complicates "loose consistency" issues, avoidance of these issues by making all replication agreement changes through the same master (see Sections 4 and 5) is strongly advised. 2.3 Access Control The following considerations complicate replication of Access Control Information: - Access Control Information (ACI) is treated as though it were stored as attributes in the directory [ACModel] - LDAP [RFC2251] declares that changes resulting from a single LDAP MODIFY are atomic (but see caveats for multi-master replication in Sections 3 and 4) - The ACI affecting a given entry may not be part of that entry (it could be part of a group entry or part of an ancestor of the entry in question) - The ACI cannot always be changed atomically with associated data changes - The interaction of replication and partitioning is still unclear (i.e. what happens when access control policy is inherited from an area of replication that is not held locally). - Thus, if you aren't careful, you can leave windows where data is unprotected To reduce risk: - In all environments, access control changes should be made before adds and after deletes - In multi-master environments, access control changes and the associated data changes should be made on same system. Even when ACI is faithfully replicated (with the same transfer format) among heterogeneous members of a replica group, there is no guarantee Huber, et al Expires September 2003 [Page 5] INTERNET DRAFT Gen'l Usage Profile for LDAP Replication March 2003 that an ACI change is expressed similarly everywhere in the group. This caveat is partly due to the open issues with respect to partitioning mentioned above, and partly due to vendor differences with regard to the expression of security policy. 2.4 Change Logs Requirement G4 of [ReplicaReq] states that meta-data must not grow without bound. Since it is unrealistic to assume that meta-data won't be needed during replication, designers must consider how and when meta-data can be purged. Replicas that use connections with intermittent quality should use explicit replica cycle scheduling. Since the systems know when replication should have occurred, delayed replication can be detected and manual intervention initiated before the meta-data grows without bound. In extreme cases, it may be necessary to remove a replica from the replication group and restore it once better connectivity is available. In a multi-master system, it is possible for a consumer to receive changes that cannot be applied. For example, a modify request for an entry may arrive before the add request that creates that entry. The replication system will typically queue this change and wait for additional changes (see Section 3.3). 3 Naming Considerations A number of naming models have been proposed for directories ([RFC1255], [RFC2377], [CIMNames]), and many others have been implemented on an ad hoc basis. Each of these models specifies the naming attributes to be used and provides rules for using them which may also include containment rules. The naming plan applies to the directory as a whole, not the individual servers holding replicas. Therefore, in a heterogeneous replicated environment, all of the replicating servers must be capable of supporting all of the rules for the naming plan in use for that directory. Some directory implementations have naming constraints (e.g. containment rules, restrictions on attributes that can be used for naming). If such an implementation is part of a replicated directory, those constraints will have to be observed by all participating directories. If the environment contains implementations with Huber, et al Expires September 2003 [Page 6] INTERNET DRAFT Gen'l Usage Profile for LDAP Replication March 2003 incompatible constraints there is a major problem. This should be checked as early in the design phase as possible. Applications often have their own requirements on naming; in this case the directory will have to support multiple naming schemes. Thus, if two independent applications start sharing previously separate directory information, care should be taken that the naming is consistent across the applications. A difference in name form may be accepted through LDUP without constraint violation, but nevertheless result in unexpected behavior from a cross-application perspective. Consistent naming is not only important to the directory, but to the applications that consume directory information as well. 4 Conflict Resolution Considerations 4.1 Consistent Access after Changes Many operations on a directory are done as a set of steps. For example, a new object may be created by one operation, and its values may be filled in as part of a separate LDAP operation. An administrator may add a user to a directory, and that user may then try to log in using the new entry. Replicated LDAP directories provide loose consistency [ReplicaReq]. A new entry or a change to an existing entry will not reach all replicas immediately; there will be some delay before changes are available on all replicas. Changes made (e.g. adding a new user) on one physical system may appear to be "lost" if checked on another physical system before replication is complete. In general, LDAP applications should be prepared to operate correctly in the face of replication delays. In some cases, this means designing to allow for delay. In the case of the newly created user, it should be standard practice to ask the user to wait a while before trying to use the entry. In the case where the new object must be filled in, the application should make appropriate use of LDAP sessions to make sure that the same server is reached for both operations. As a general rule, an LDAP application should bind once and not unbind until a complete set of related operations have been performed. To achieve load balancing of write operations in a multi-master environment, balancing the write-enabled connections is recommended over balancing LDAP write operations. In the single-master case, all write requests go to one server. If a set of related reads and writes are done, they should all be done on Huber, et al Expires September 2003 [Page 7] INTERNET DRAFT Gen'l Usage Profile for LDAP Replication March 2003 the master if possible. Ideally, only sets of related operations that cannot include a write should go to one of the slave servers. But load balancing concerns may make this impractical. In some cases, related requests will deal with data in different partitions that are not all available on a single server. In this case, it is safer to keep sessions open to all servers rather than closing the session with one server and opening one with another server. It may not always be obvious to clients that they are using different servers. If a load distribution system is used between the client and the server, the client may find that a change request and a subsequent lookup are directed to different physical servers even though the original requests were sent to the same server name and/or address. Since LDAP is session oriented, any load distribution system used should take sessions into account. Thus, keeping all related read and write requests within a single bind/unbind session should be the goal in this situation as well. 4.2 Conflict Resolution in Single-Master Systems It is possible that resolution conflicts could occur in a single master replication system. Because requirement SM2 of [ReplicaReq] is a "SHOULD" and not a "MUST", it is possible for implementers to reorder changes. If changes are reordered, it is quite possible for a conflict to occur. Consider a case where schema changes are declared critical and must be moved to the front of the replication queue. Then the consumer servers might have to delete an attribute that still has values, and later process requests to delete the values of that attribute. However, directory administrators may have scenarios where re-ordering of replication information is desirable. On a case-by-case basis, the directory administrator should make such decisions. Many vendors may not implement conflict resolution for single-master replication. If such a system receives out-of-order changes from a system that does support them, replication errors will almost certainly occur. Designers should be aware that mismatches in the capabilities of replicating single-master directories could cause problems. Designs should not permit the master to re-order changes unless all slave copies are known to handle the situation correctly. Huber, et al Expires September 2003 [Page 8] INTERNET DRAFT Gen'l Usage Profile for LDAP Replication March 2003 4.3 Problem Cases 4.3.1 Atomicity The fact that replication does not guarantee the time order arrival of changes at a consumer allows situations where changes that were applied successfully at the supplier may fail in part when an attempt is made to apply the same change at the consumer. Examples appear below. 4.3.1.1 Locking There is an entry with distinguished name "DN" that contains attributes X, Y, and Z. The value of X is 1. On replica A, a ModifyRequest is processed which includes modifications to change that value of X from 1 to 0 and to set the value of Y to "USER1". At the same time, replica B processes a ModifyRequest which includes modifications to change the value of X from 1 to 0 and to set the value of Y to "USER2" and the value of Z to 42. The application in this case is using X as a lock and is depending on the atomic nature of ModifyRequests to provide mutual exclusion for lock access. In the single-server case, the two operations would have occurred sequentially. Since a ModifyRequest is atomic, the entire first operation would succeed. The second ModifyRequest would fail, since the value of X would be 0 when it was attempted, and the modification changing X from 1 to 0 would thus fail. The atomicity rule would cause all other modifications in the ModifyRequest to fail as well. In the multi-master case, it is inevitable that at least some of the changes will be reversed despite the use of the lock. Assuming the changes from A have priority per the conflict resolution algorithm, the value of X should be 0 and the value of Y should be "USER1" But what is the value of Z at the end of the replication cycle? If it is 42, then the atomicity constraint on the change from B has been violated. But for it to revert to its previous value, grouping information must be retained. Therefore, it is not clear when such information may be safely discarded. Thus, requirement G6 in [ReplicaReq] may be violated. The utility of locking mechanisms cannot be guaranteed with multi- master replication, and therefore results are likely to be misleading. As discussed further in section 6.1 below, its use in multi-master environments should be deprecated. 4.3.1.2 Partitioning Huber, et al Expires September 2003 [Page 9] INTERNET DRAFT Gen'l Usage Profile for LDAP Replication March 2003 Partitioning (design of replica groups) also adds complexity. For example, suppose two servers, A and B, are members of a replica-group for area of replication X while servers B and C are members of replica- group for area Y. It is possible to issue a ModifyRDN operation on server B that moves an entry from area X to area Y. Replication in area X would delete the entry on server A while replication in area Y would add the entry to server C. However, if another change on server C prevented the add operation from working (e.g. an entry with the same RDN but a different GUID exists there already), then the change on server A is inconsistent and will need to be reversed. Other examples of cases of this class include group membership modification and access control scoping. 4.4 General Principles The examples above discuss some of the most difficult problems that can arise in multi-master replication. Dealing with them is difficult and can lead to situations that are quite confusing to the application and to users. The common characteristics of the examples are: - Several directory users/applications are changing the same data - They are changing the data at the same time - They are using different directory servers to make these changes - They are changing data that are parts of a distinguished name or they are using ModifyRequest to both read and write a given attribute value in a single atomic request If any one of these conditions is reversed, the types of problems described above will not occur. There are many useful applications of multi-master directories where at least one of the above conditions does not occur. For cases where all four do occur, application designers should be aware of the possible consequences. 5 Failover Considerations One of the major reasons to use directory replication is to improve reliability of the directory system as a whole. Replication permits hot- and warm-standby configurations to be built easily. But there are some issues that must be considered during design. In this situation, single-master systems actually raise more concerns than multi-master. Both are addressed below. Huber, et al Expires September 2003 [Page 10] INTERNET DRAFT Gen'l Usage Profile for LDAP Replication March 2003 5.1 Common Issues In both the single- and multi-master cases, clients must be able to find an alternate quickly when a server fails. Some possible ways to do this are detailed in [FindingLDAP] and [LDAPinDNS]. If all else fails, a list of possible servers can be built into client applications. Designers should consider how clients are notified that the server is again available. When the failed server comes back up, it is brought back into synchronization with the other servers and is ready to take requests. It is always possible that the failed server, if it was acting as a supplier, was unable to completely distribute its pending changes before removal from service, leaving its consumers in an inconsistent state. During the period between its removal from service and its eventual return, the inconsistency may have been compounded by further application activity. As there is no current automatic mechanism to rectify the problem, the administrator should use whatever mechanism is available to compare the replicas for consistency as soon after the event as is reasonable. Note that the process used to bring a failed server back into replication can also be used to add a server to a set of replicating servers. In this case, the new server might be initialized from a backed-up copy of the directory or it may acquire the entire DIB via replication. The former method is usually preferable when the directory is large. 5.2 Single Master Issues In a single-master system, the master is a single point of failure, as all modification has to originate at the master server. When high availability is a requirement, a quick, automated failover process for converting a slave replica to a new master is desirable, as the failover time becomes a major factor in determining system availability. The considerations in section 5.1 apply here; clients must know how to find the new master or a new slave in case of failure. To aid in promotion of a slave replica, the master could replicate control information and meta-data (including replication credentials) so that this information is available during failover promotion. This data may either be replicated on a single "failover designate" slave (which would become the master in during failover) or it could be replicated to all slaves. The first possibility has the advantage of minimizing the amount of extra replication while the second more robustly handles multiple failovers (i.e. failover of the newly Huber, et al Expires September 2003 [Page 11] INTERNET DRAFT Gen'l Usage Profile for LDAP Replication March 2003 promoted master to another slave before the original master has been restored). If this method is followed, data privacy mechanisms should be used to protect the replication session. If data privacy mechanisms (e.g. encryption) are used to protect the replication session, the new master must have the necessary key information. Further this key information should be independent of the master that is using it (i.e. not tied to the IP address of the master server). If it is not independent, slave replicas could be pre- configured with the keys for all possible masters to reduce failover time. Restoration of the failed or broken master can be handled in one of two ways: - It could join the replica group and function as a slave. - It could join the replica group and negotiate with the new master to synchronize and then take over as master. In either case, clients need a way to know that a new server is available. If the broken master is returned to service as a slave, then the administrator must, external to LDUP, distribute and resolve whatever pending changes remained undistributed and unresolved from the time immediately before it was removed from service. If the broken master is returned as a new master, then care must be taken with its replacement master to ensure that all of its pending changes are distributed and resolved before it is returned to duty as a slave. The slave replicas may also use the replication agreement to filter which master is allowed to submit changes. Such a model allows the slave servers to function correctly when the master server is "broken" and sending out incorrect updates. However, then it is necessary to update the replication agreement during the fail over process so that the slaves will accept updates from the new master. This is the case for both the original failure and the restoration of the restored master if that is how the restored master rejoins the replica group. 5.3 Multi-Master Issues Huber, et al Expires September 2003 [Page 12] INTERNET DRAFT Gen'l Usage Profile for LDAP Replication March 2003 Typically, a multi-master configuration is used when high availability is required for writes as well as reads in the directory. Because there are multiple active servers prepared to take write requests, there is no "switchover" time in this case. But clients still need to be able to find an alternate server, so the considerations of Section 5.1 apply here. 6 Other Issues 6.1 Locking Section 4.3.1.1 discussed the problems that can arise when the "modify" command in LDAP is used for locking in a multi-master environment. There are more general principles at work there. LDAP is a distributed and replicated directory service that is typically described as "loosely consistent". In loose consistency, the data should eventually converge among the replicas, but at any given instant, replicas may be in disagreement. This stipulation is the general result of: 1. The delay due to replication or extended replication intervals 2. The out of natural time order arrival of data at a replica 3. The temporary isolation of distributed systems from one another 4. Failure to accept a change due to conflict resolution failure on a replica Because of loose consistency, data preconditions to an LDAP operation may differ among replicas. Multi-mastering may exacerbate this situation, but single-mastering will not totally eliminate it if out- of-order replication is allowed (see Section 4.2). One must carefully assess the effect of loose consistency when evaluating operations that place specific preconditions on data to work correctly. Applications which depend on such operations may be better suited for transactional models and/or non-distributed data. Distributed locking is one operation that depends on strict data preconditions. When data preconditions cannot be guaranteed, the lock is moot. The same principles hold for "atomic operations", defined here as any mix of allowable operations contained within the same LDAP PDU. RFC2251 requires that they either all fail or are applied as a unit. If strict data preconditions cannot be guaranteed, then the atomic operation may itself result in a further inconsistency requiring human intervention at one of the consumers. 6.2 Backup and Restore Backup of a directory server should have the following goals: Huber, et al Expires September 2003 [Page 13] INTERNET DRAFT Gen'l Usage Profile for LDAP Replication March 2003 1. It can be unambiguously and faithfully restored. 2. It is an internally consistent snapshot of an entire replica during the time interval it took to make it. This can only be achieved if the server is quiescent. 3. Replication can resume on a machine restored from that backup without information loss. Backup and restore of a single, operating directory server (rather than the entire directory system) presents its own challenges. "Loose consistency" works against the probability of achieving a loss-free copy of all the data in the directory, except under ideal conditions. Backup and restore of distributed directories is a decidedly easier task when the constraint of continuous availability is removed. In most cases, the removal of entire directory systems from write service is impossible, even for small periods of time. It is more practical to remove a single directory server from service to achieve a condition of quiescence. Once all write load is removed, including write load due to replication, an internally consistent copy of the data may be obtained. Replicas that have suffered catastrophic data loss may be restored from backups of working servers temporarily removed from service specifically to make a copy. This scenario illustrates the benefit of having three or more replicas in the system: no single point of write failure in the event that one of the replicas must be restored from a copy of another. The M11 requirement from [ReplicaReq] allows an empty replica to be brought up to date through replication. This feature duplicates, but does not make entirely unnecessary, backup procedures on directory servers. Backups are still needed to recover data that has been lost to all replicas, either through normal LDAP updates or through some catastrophic event. 7 Impact of Non-LDAP Changes/Constraints 7.1 Changes Outside of LDAP LDAP directories are typically built on top of some database or file system. Thus there are ways to change the data that do not go through the normal LDAP change mechanisms (e.g. ModifyRequest). If the data is modified outside of LDAP, the changes will not be checked for schema conformance nor will access controls be checked as the changes are Huber, et al Expires September 2003 [Page 14] INTERNET DRAFT Gen'l Usage Profile for LDAP Replication March 2003 made. Since both integrity and security checks are omitted, security can be adversely affected. Also, many systems use the normal LDAP modification mechanisms to trigger replication. Changes made using non-LDAP mechanisms may not be replicated at all, leading to inconsistencies between replica copies. 7.2 Application Triggers Directory servers commonly integrate one or more specific applications. To achieve this integration the directory server may intercept updates and run application-specific "trigger" code. Such triggers enforce directory invariants that cannot be expressed by the LDAP schema. A simple trigger example is password policy enforcement. A directory server might interpret a request to replace the current value of the userPassword attribute with some new value as a request to first check that the new value conforms to the server's password policy (e.g. the value is sufficiently long and complex) before storing the new value. Using this trigger the directory server voids the security risk associated with passwords that are easy to attack. A more complex trigger example is password hashing. A directory server might interpret a request to replace the current value of the userPassword attribute with some new value as a request to compute one or more secure hashes of the new value and store these hashes in one or more attributes, storing no value in the userPassword attribute. Using this trigger the directory server avoids the security exposure of storing the plaintext password. Replication between directory servers with different application triggers will compromise directory integrity. 7.3 Policy Conflicts Across Servers In addition to the discussions of ACI in Section 2.3 and triggering in section 7.2, LDUP replication can not (by its definition) handle replication of information that makes use of policy not expressible in the LDAP protocol. A prime example of this is security encoding of attributes (e.g. userPassword). This encoding is typically implementation specific and is not easily expressible via the LDAP protocol. Therefore replication of userPassword attributes between directory servers that use different encoding schemes will impede replication in a way that is not describable as schema or syntax mismatch. This is because of the bind-time policy semantics that are the true point of conflict. Huber, et al Expires September 2003 [Page 15] INTERNET DRAFT Gen'l Usage Profile for LDAP Replication March 2003 Another case arises from the use of authentication levels in the Access Control Model [ACModel]. The authentication levels represent the strength of various forms of authentication rather than specific authentication mechanisms; the association between levels and mechanisms is left for administrators though some guidance may be provided [AuthMap]. In a replicated environment, administrators must be sure that the mappings of all replicating systems are compatible. If they are not compatible, access controls may have different effects on different replicas of a partition. In general, any attribute with semantics that are outside the scope of what is expressible by the LDAP protocol could result in strange replication errors. Therefore, distributed directory implementers should (in the absence of a way to express such semantics) either strive for a homogeneous set of servers or ensure during acceptance testing that a new server can support the existing semantics of their directory. 8 Security Considerations The document discusses issues that arise in replication. Some of these issues are security related (e.g. replication of access control information) and the security implications are discussed in the relevant sections. 9 Acknowledgements This document owes a lot to discussions on the LDUP mailing list. In particular, the authors would like to thank Ed Reed, whose email to the mailing list drove much of section 6.1, and Mark Brown for identifying and generating text on the issues discussed in section 7. 10 References [ACModel] E. Stokes, R. Blakeley, R. Byrne, R. Huber, D. Rinkevich, "Access Control Model for LDAPv3", Internet Draft, draft-ietf-ldapext- acl-model-08.txt, June 2001. [AuthMap] K. Zeilenga, "Authentication Mechanisms Levels", Internet Draft, draft-zeilenga-auth-lvl-01.txt, April 2001. [CIMNames] Desktop Management Task Force, "Guidelines for CIM-to-LDAP Directory Mappings", DMTF Specification DSP0100, May 2000 (available online at http://www.dmtf.org/spec/DEN/DSP0100.htm). Huber, et al Expires September 2003 [Page 16] INTERNET DRAFT Gen'l Usage Profile for LDAP Replication March 2003 [FindingLDAP] R. Moats, R. Hedberg, "A Taxonomy of Methods for LDAP Clients Finding Servers", Internet Draft, draft-ietf-ldapext-ldap- taxonomy-05.txt, July 2001. [InfoMod] E. Reed, T. Hahn, "LDUP Replication Information Model", Internet Draft, draft-ietf-ldup-infomod-03.txt, July 2001. [LDAPinDNS] M. Armijo, L. Esibov, P. Leach, R. L. Morgan, "Discovering LDAP Services with DNS", Internet Draft, draft-ietf-ldapext-locate- 05.txt, March 2001. [ReplicaReq] E. Stokes, R. Weiser, R. Moats, R. Huber, "LDAPv3 Replication Requirements", Internet Draft, draft-ietf-ldup-replica-req- 08.txt, March 2001. [RFC1255] The North American Directory Forum, "A Naming Scheme for c=US", RFC 1255, September 1991. [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol", RFC 2251, December 1997. [RFC2377] A. Grimstad, R. Huber, S. Sataluri, M. Wahl, "Naming Plan for Internet Directory-Enabled Applications", RFC 2377, September 1998. Authors' Addresses Richard V. Huber Room C3-3B30 AT&T Laboratories 200 Laurel Avenue South Middletown, NJ 07748 USA E-Mail: rvh@att.com Telephone: +1 732 420 2632 Fax: +1 732 368 1690 Gerald F. Maziarski Room C3-3Z01 AT&T Laboratories 200 Laurel Avenue South Middletown, NJ 07748 USA E-Mail: gfm@att.com Telephone: +1 732 420 2162 Fax: +1 732 368 1690 Huber, et al Expires September 2003 [Page 17] INTERNET DRAFT Gen'l Usage Profile for LDAP Replication March 2003 Ryan D. Moats Lemur Networks 15621 Drexel Circle Omaha, NE 68135 USA E-Mail: rmoats@lemurnetworks.net Telephone: +1 402 894 9456 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Huber, et al Expires September 2003 [Page 18] From owner-ietf-ldup@mail.imc.org Sun Mar 2 19:13:07 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21601 for ; Sun, 2 Mar 2003 19:13:06 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h23079k25315 for ietf-ldup-bks; Sun, 2 Mar 2003 16:07:09 -0800 (PST) Received: from tconl91223.tconl.com (tconl91223.tconl.com [204.26.91.223]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h23077Y25311 for ; Sun, 2 Mar 2003 16:07:07 -0800 (PST) Received: (from jayhawk@localhost) by tconl91223.tconl.com (8.11.6/8.11.0) id h2306Wd01515; Sun, 2 Mar 2003 18:06:32 -0600 Date: Sun, 2 Mar 2003 18:06:32 -0600 From: Ryan Moats To: internet-drafts@ietf.org Cc: ietf-ldup@imc.org Subject: New version of draft-ietf-ldup-mrm Message-ID: <20030302180632.A1509@privateer.local.windrose.omaha.ne.us> Reply-To: rmoats@lemurnetworks.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Drafts Editor- Please published the attached as draft-ietf-ldup-mrm-03.txt LDUP- This is a re-issue of the most recent version of MRM. Ryan Moats --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- INTERNET DRAFT Mandatory LDAP Replica Management March 2003 Internet-Draft Ryan Moats LDAP Duplication/Replication/Update Lemur Networks, Inc. Protocols WG Rick Huber Expires September 2003 AT&T Laboratories John McMeeking IBM March 2003 Mandatory LDAP Replica Management Filename: draft-ietf-ldup-mrm-03.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt. The list of Internet-Drafts Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract The goal of standards for LDAP replication is to allow interoperable replication among products from many different vendors. Defining the mechanism to move data among replicas is a necessary part of this work, but management of the replicated environment must also be standardized for replication to be truly interoperable. This document presents the replication management functions that must be performed. Whenever possible, these functions are defined in terms of existing LDAP functionality using existing LDAP operations and existing data definitions. In some cases, changes or additions to the existing model are required, and specifications for these changes are included in this document. Moats, et al Expires September 2003 [Page 1] INTERNET DRAFT Mandatory LDAP Replica Management March 2003 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Table of Contents Status of this Memo...................................................1 Abstract..............................................................1 Table of Contents.....................................................2 1 Introduction .......................................................3 2 Administrative Precursors ..........................................4 3 Operational "Atoms" ................................................4 3.1 Add area of replication to a server ............................5 3.2 Delete area of replication from a server .......................5 3.3 Copy base of area of replication between servers ...............6 3.4 Create server entry for an area of replication .................6 3.5 Delete server entry from an area of replication ................6 3.6 Modify replica .................................................7 3.6.1 Change Replica Type .........................................7 3.6.2 Change Between Full/Partial Replica .........................7 3.6.3 Change Replica URI for one server for one area of replication 8 3.7 Add Replication Agreement ......................................8 3.8 Delete Replication Agreement ...................................9 3.9 Modify Replication Agreement ...................................9 3.10 Suspend Replication ..........................................9 3.11 Resume Replication ..........................................10 3.12 Trigger an Immediate Replica Cycle ..........................10 3.13 Immediately Terminate a Replica Cycle .......................11 3.14 Search with Meta-Data .......................................11 3.15 Changing Replication Meta-Data ..............................12 3.15.1 Add with Meta-Data .......................................12 3.15.2 Delete with Meta-Data ....................................13 3.15.3 Modify with Meta-Data ....................................13 3.16 Write-Unwriteable Control ...................................13 4 Common Tasks ......................................................14 4.1 Add a new replica to an existing replica group ................14 4.1.1 Large area of replication support ..........................15 4.2 Verify replication information is present between two servers .16 4.2.1 Verify that replication objects exist ......................17 4.2.2 Verify that it is valid for replication to occur between these servers .....................................................18 4.3 Start replication between two servers .........................18 4.4 Suspend Replication activity on one area of a server ..........19 4.5 Suspend Replication activity on all areas of a server .........19 4.6 Restart Replication activity on one area of a server ..........19 4.7 Restart Replication activity on all areas of a server .........19 4.8 Halt replication ..............................................19 4.9 List status of a particular area of replication on a given server .............................................................20 4.9.1 Local Replica On-Line ......................................20 4.9.2 Remote Replicas On-Line ....................................20 Moats, et al Expires September 2003 [Page 2] INTERNET DRAFT Mandatory LDAP Replica Management March 2003 4.9.3 Check Status of Outward Replication ........................20 4.9.4 Check Status of Incoming Replication .......................20 4.10 List all areas of replication defined on a given server and their status .......................................................21 4.11 Restore a server and replication agreements after a server crash 21 4.11.1 Recent Backup is Available ...............................21 4.11.2 Backup is Not Available ..................................22 4.12 Split an Area of Replication ................................22 4.13 Move an existing area of replication to a new server ........23 4.14 Join two Areas of Replication ...............................23 4.14.1 Preconditions ............................................23 4.14.2 Procedure ................................................24 4.14.3 Server requirements ......................................24 4.15 Stop Replicating an Area of Replication. ....................24 4.16 Convert a read-only replica to an updateable replica ........25 4.17 Convert an updateable replica to a read-only replica ........25 4.18 Postpone a Replica Cycle to a Later Time ....................26 4.19 Examine Replication Audit History on a Server ...............26 4.20 Compare Two Replicas on Two Servers for Differences .........26 4.21 Fix an Entry Without Triggering Replication .................27 4.22 Check Reported Schema Mismatches Discovered During Replication 27 4.23 Adding a new directory server to a replica group and initializing the contents ..........................................28 4.24 Restore from the master failure in a single-master system ...28 5 Formal Specifications .............................................29 5.1 New/Modified Object Classes ...................................29 5.2 New/Modified Attributes .......................................29 5.3 New/Modified Extended Operations ..............................29 5.4 New/Modified Replication Primitives ...........................29 5.5 New/Modified Controls .........................................29 6 Security Considerations ...........................................30 7 Acknowledgements ..................................................30 8 References ........................................................31 Authors' Addresses:..................................................31 Full Copyright Statement.............................................32 1 Introduction In the LDAP replication architecture [Arch], the LDAP servers and replication agreements between them are represented by entries in the directory tree, as part of the replicated naming context. The LDAP replication information model [InfoMod] describes the contents of these entries. Replication management entries, such as replicaSubentries or replication agreements, can be altered on any updateable replica using standard LDAP operations [RFC2251]. These entries are explicitly included in the directory entries governed by any agreement associated with this area of replication. As a result, all servers with a replica Moats, et al Expires September 2003 [Page 3] INTERNET DRAFT Mandatory LDAP Replica Management March 2003 of an area of replication will have access to information about all other replicas of that area of replication and associated agreements. The deployment and maintenance of a replicated directory network involves the creation and management of the replicas themselves and associated replication control information (e.g. replicationSubentries and replication agreements). This document outlines the administrative actions necessary to create and maintain replication agreements. Typically, administrative tools will guide the administrator and facilitate these actions. 2 Administrative Precursors In this document the term "administrative user" refers to an identity that will be performing replication configuration by binding to and invoking operations on directory servers. Most LDAP server implementations have the concept of a superuser or power user, however this need not be the same as the administrative user, so long as the administrative user has been granted appropriate privileges. The administrative user MAY be running as an autonomous process, and MUST be capable of securely maintaining its own credentials. Deployments SHOULD create an administrative user identity that is granted access to all servers holding a copy of a replicated area to perform the procedures described below, in particular to read the root DSE, the replicationContext prefix entry and all subordinate subentries. The administrative user who will be viewing or modifying the replication status MUST have already been provided with and established in the directory server or servers appropriate authentication credentials and authorization rights to retrieve attributes and invoke DIT modification operations that are beyond the ability of the 'average' directory user. 3 Operational "Atoms" The following operational atoms are used to build up more complex tasks in section 4. Most of these operational "atoms" make the following assumptions: Through prior LDAP or out-of-band means the administrative user MUST have been granted the following access control permissions to the directory in order to establish replication: - Create the naming context prefix entry - Create subentries immediately below the naming context prefix entry In several sections below, we refer to "source" and "target" servers. The "source" server is a server that already holds a copy of the area of replication. It may already be replicating that area with other servers. The "target" server does not currently hold a copy of the area of replication. The "target" is being added to the replica-group. Moats, et al Expires September 2003 [Page 4] INTERNET DRAFT Mandatory LDAP Replica Management March 2003 The LDUP Architecture [Arch] allows for read-only replicas. Setting up and maintaining a read-only replica will sometimes require that the administrator create or modify data on the read-only replica. In this case, the Write-Unwriteable control (Section 3.16) should be used. In the remainder of the document, any numbered list of steps is intended to be performed in the order given. Un-numbered (dash) lists will be used where order is unimportant. 3.1 Add area of replication to a server The client SHOULD invoke a ModifyRequest in which the object field is the context prefix of the replication context, and the modification list consists of a single item to add the value replicationContext to the attribute objectClass. If the server responds with the resultCode attributeOrValueExists, then the value is already there. If the server responds with a resultCode other than attributeOrValueExists or success, then this is an error. Should an error occur at this point, the server is in an inconsistent state and needs to be fixed. After this step is completed, the server will begin storing change information for this area of replication. 3.2 Delete area of replication from a server On the target server, the client SHOULD invoke a SearchRequest to find all replicaSubentry objects which refer to the area of replication: 1. Retrieve all the values of the replicaContextRoots attribute in the root DSE of the server. Each value is the distinguished name of the base entry of a Replication Context held on the server. 2. Perform a one-level LDAP search in each replicaContextRoot for objects of class replicaSubentry whose replicaURI attribute points to the given server (e.g. use a filter of "(&(objectclass=replicaSubentry-2)(replicaURI=ldap://thisserver))") where "thisserver" is the fully-qualified DNS name of the given server with the associated port if it is not port 389. The client then examines the subtreeSpecifications to determine which one it wants and then deletes all replicaSubentries with that subtreeSpecification. If any of the DelRequests fail, the area of replication has not been completely removed. After this step is completed, the target server will no longer replicate this area of replication nor will it record changes for later replication. However, the other servers in the replica group for this area will still have a replicaSubentry for the given server, and this should be cleaned up on all servers that hold the replica. WG Issue: This is a reason for the subtreeSpecification issue. If it were a DN, this would be much easier. Otherwise, we're going to need a matching rule for subtreeSpecification. Moats, et al Expires September 2003 [Page 5] INTERNET DRAFT Mandatory LDAP Replica Management March 2003 3.3 Copy base of area of replication between servers In this section, the "target server" is the server on which the client has just modified the root DSE. The client MUST separately contact another server, one that already holds a copy of this replication context, and issue a SearchRequest on that server in which the baseObject is the DN of the base of the area of replication, the scope baseObject, the filter "(objectClass=*)" and the attributes list {"*", entryUuid}. If the client cannot obtain the single entry at this point, the procedure will fail. Now that it has the entry, the client SHOULD invoke an AddWithMetaData (see 3.15.1) on the target server with entry set to the DN of the base of the area of replication and attributes the same list as obtained in the previous search. If the server returns a resultCode other than success, it is an error, and the server will be in an inconsistent state. 3.4 Create server entry for an area of replication Each server needs to have in its copy of the area of replication a replicaSubentry for each of the servers involved in replicating that area before replication can be started. These entries MUST have the following attributes: - objectclass, with values top, Subentry and replicaSubentry - cn - replicaURI - replicaType and MAY contain other attributes, as described in the Information Model [InfoMod]. WG Issue: This means that InfoMod needs to explicitly define replicaOnline as DSA specific with a default value of FALSE. 3.5 Delete server entry from an area of replication On the target server, the client SHOULD invoke a SearchRequest to find all replicaSubentry objects which refer to the area of replication: 1. Retrieve all the values of the replicaContextRoots attribute in the root DSE of the server. Each value is the distinguished name of the base entry of the base entry of a Replication Context held on the server. 2. Perform a one-level LDAP search in each replicaContextRoot for objects of class replicaSubentry whose replicaURI attribute points to the given server (e.g. use a filter of "(&(objectclass=replicaSubentry-2) (replicaURI=ldap://thisserver))") where "thisserver" is the fully-qualified DNS name of the given server. The subentry control MUST be included on this operation. Moats, et al Expires September 2003 [Page 6] INTERNET DRAFT Mandatory LDAP Replica Management March 2003 The client then examines the subtreeSpecifications and the replicaURI to determine which one(s) it wants and then deletes all replicaSubentries with that proper subtreeSpecification and replicaURI. If any of the DelRequests fail, the area of replication has not been completely removed. WG Issue: This is another reason for the subtreeSpecification issue. If it were a DN, this would be much easier. Otherwise, we're going to need a matching rule for subtreeSpecification. 3.6 Modify replica 3.6.1 Change Replica Type Note: This section covers only the simple protocol operation to change the replica type. Section 4.16 covers the full set of operations for converting from a ReadOnly to an Updateable replica. The client SHOULD invoke a ModifyRequest with the Write-Unwriteable control (Section 3.16) in which the object field is the replicationSubentry, and the modification list consists of a single item to change the value of the attribute replicaType. If the server responds with the resultCode attributeOrValueExists, then the value is already there. If the server responds with a resultCode other than attributeOrValueExists or success, then this is an error. 3.6.2 Change Between Full/Partial Replica Note: This section currently discusses how to change between fractional and full replication. Once the information model supports sparse replication, it will need to be added here. This section only discusses the simple LDAP protocol operations to change between full and partial replicas. Additional actions are discussed in Section 4.15. To switch from fractional to full replication, a client SHOULD invoke a ModifyRequest with the Write-Unwriteable control (Section 3.16) in which the object field is the replicaSubentry, and the modification list consists of two items: one to remove the attribute attributeExclusionFilter and the other to remove the attribute attributeInclusionFilter. If the server responds with a resultCode other than noSuchAttribute or success then an error has occurred. To switch from full to fractional replication, a client SHOULD invoke a ModifyRequest with the Write-Unwriteable control in which the object field is the replicaSubentry, and the modification list consists of one or two items: one to add the attribute attributeExclusionFilter and/or the other to add the attribute attributeInclusionFilter. If the server responds with a resultCode other than attributeOrValueExists or success, then an error has occurred. Moats, et al Expires September 2003 [Page 7] INTERNET DRAFT Mandatory LDAP Replica Management March 2003 3.6.3 Change Replica URI for one server for one area of replication Note: This section covers only the simple protocol operation to change the replica URI. Replication will carry this change to other servers. The client SHOULD invoke a ModifyRequest in which the object field is the replicationSubentry, and the modification list consists of a single item to delete the old value of the attribute replicaURI and add the new value. If the server responds with the resultCode attributeOrValueExists, then the value is already there. If the server responds with a resultCode other than attributeOrValueExists or success, then this is an error. 3.7 Add Replication Agreement Each server that acts as a supplier in replication sessions needs to have in its copy of the area of replication a replicaAgreementSubentry for each server that it replicates to. ReplicaAgreementSubentry objects are created as subordinates of the replicaSubentry representing the supplier server. These entries MUST have the following attributes: - objectclass, with values top, Subentry and replicaAgreementSubentry- 2, and - cn and MAY contain other attributes, as described in the Information Model [InfoMod]. The cn attribute value has no significance to replication. The cn attribute SHOULD have a value that is meaningful to the replication administrator. These objects MUST have the following attributes (defined as optional in the Information Model) for replication to occur: - replicaDN If replicaDN is absent, no replication occurs under this agreement. A client AddRequest creates the replicaAgreementSubentry. The entry field of the AddRequest is the DN of the agreement (formed by using the cn attribute as the RDN naming attribute in combination with the DN of the parent replicaSubentry). The attributes field of the AddRequest contains the required attributes for the agreement and any optional attributes that are to be defined at this time. Note: while replicationAgreementSubentries could be replicated, since the replicationCredentialsDN are contained in the replicationAgreementSubentry, there is a bootstrapping issue with replicating via anonymous replication. To avoid this, clients MAY create the replicationAgreementSubentries on all servers. If they do this, they should use the AddWithMetaData operation (Section 3.15.1) to ensure that all replicationAgreementSubentries have the same entryUUID. Moats, et al Expires September 2003 [Page 8] INTERNET DRAFT Mandatory LDAP Replica Management March 2003 3.8 Delete Replication Agreement To delete a replication agreement a LDAP client SHOULD invoke a DeleteRequest naming the replicaAgreementSubentry to be deleted. The termination of replication agreements should be done with caution as it can easily result in a partition of the directory servers if performed incorrectly. Once all replication agreements have been terminated between a server and others for a naming context, then that copy of the context on the server will be divergent, and any updates made there will not be propagated to any other server. 3.9 Modify Replication Agreement To modify a replication agreement, the client SHOULD invoke a ModifyRequest naming the replicaAgreementSubentry. The modification list MAY include any of the following attributes: - attributeExclusionFilter - description - replicaDN - replicationMechanismOID - replicationCredentialsDN - replicationScheduleDN No further administrative action is required for these changes to take affect. Changing the replicaDN attribute has the effect of ending the existing agreement with the replica named by the old replicaDN value (if a value was present). Similary, changing the replicationMechanismOID attribute to specify ietf-ldup-full-update has the effect of ending incremental replication relationship. In this respect, these changes are equivalent to deleting a replication agreement and have the same considerations (see section 3.8) The replicationStatus attribute cannot be modified. 3.10 Suspend Replication The client SHOULD invoke a ModifyRequest in which the object field is the DN of the target replicationSubentry, and the modification list consists of a single item to change the value of replicaOnline attribute to false. If the server responds with the resultCode attributeOrValueExists, then the value is already there. If the server responds with a resultCode other than attributeOrValueExists or success, then this is an error. If replicaOnline is FALSE for a replicaSubentry that represents the server containing the instance of the replicaSubentry, the server MUST NOT initiate or accept any new incremental replication sessions. If replicaOnline is FALSE for a replicaSubentry that represents a replica Moats, et al Expires September 2003 [Page 9] INTERNET DRAFT Mandatory LDAP Replica Management March 2003 other than the server containing the instance of the replicaSubentry, the server MUST NOT initiate or accept any new incremental replication sessions with that replica. 3.11 Resume Replication The client SHOULD invoke a ModifyRequest in which the object field is the DN of the target replicationSubentry, and the modification list consists of a single item to change the value of replicaOnline attribute to true. If the server responds with the resultCode attributeOrValueExists, then the value is already there. If the server responds with a resultCode other than attributeOrValueExists or success, then this is an error. If replicaOnline is TRUE for a replicaSubentry that represents the server containing the instance of the replicaSubentry, the server MAY initiate or accept new incremental replication sessions. If replicaOnline is TRUE for a replicaSubentry that represents a replica other than the server containing the instance of the replicaSubentry, the server MAY initiate or accept new incremental replication sessions with that replica. 3.12 Trigger an Immediate Replica Cycle An immediate replication cycle can be triggered using an LDAP extended operation - "Trigger Replication". This operation takes 4 or 5 arguments: . The distinguished name of the replicaSubentry for the target replica. If there is no instance of this entry on the server where the extended operation is executed, the operation is not performed and an error is returned. . The LDAP URL of the target server. (Note: Per [Req] M8, a single Replication Agreement may accommodate more than one pair of servers. Thus this argument is necessary.) . Type of replication session to be performed (full update or incremental update). . Flags indicating whether the replication session is online or offline, and if offline whether the server should create the offline file or read the offline file. See Section 4.1.1 for more details of offline replication. . If the replication session is offline, the name of the file to be used. All other required information (connection information, authentication information, etc.) is obtained from the Replication Agreement. The server on which the operation is executed immediately initiates a replica cycle with the target server. Updates are transferred in both directions if allowed by the replication agreement. If either the target server or the server executing the extended operation has a currently-active replica cycle for the replication Moats, et al Expires September 2003 [Page 10] INTERNET DRAFT Mandatory LDAP Replica Management March 2003 context specified by the extended operation, the extended operation will fail ([Arch] Section 10). Since replication is normally an asynchronous operation, the Trigger Replication extended operation completes and returns status when replication is started. It does not wait for completion of the replica cycle and the returned status indicates whether the cycle was started successfully, not whether it completed successfully. Further progress of the replica cycle can be checked using other mechanisms (e.g. Section 4.9). The detailed syntax of the operation and associated response are presented in Section 5.3. 3.13 Immediately Terminate a Replica Cycle Note: this section discusses just the operation for terminating a replica cycle. See section 4.18 for a discussion of suspending replication or changing the replication schedule. An in-progress replication cycle can be terminated immediately using an LDAP extended operation - "Terminate Replication". This operation takes 2 arguments: 1. The distinguished name of the replicaSubentry for the target replica. If there is no instance of this entry on the server where the extended operation is executed, the operation is not performed and an error is returned. 2. The LDAP URL of the target server. (Note: Per [Req] M8, a single Replication Agreement may accommodate more than one pair of servers. Thus this argument is necessary.) All other required information is obtained from the Replication Agreement. The server on which the operation is executed immediately terminates its current replica cycle with the target server. Termination will not interrupt transmission of a Replication Update [Arch], it will occur only between Replication Updates. The detailed syntax of the operation and associated response are presented in Section 5.3. Note: If data is queued awaiting replication between a pair of servers and if replication is set to trigger on updates, the replication system may automatically start a new replica cycle shortly after a cycle is terminated. To avoid this, the replication schedule should be adjusted to suspend replication before the Terminate Replication extended operation is issued. 3.14 Search with Meta-Data Many pieces of replication meta-data are used by LDUP. In some cases (entryUUID, createdEntryCSN) they are stored as operational attributes Moats, et al Expires September 2003 [Page 11] INTERNET DRAFT Mandatory LDAP Replica Management March 2003 and can be read using the LDAP search operation. Other meta-data (deleted entries, CSNs related to changes of attribute values) are not visible via normal LDAP operations but must be obtainable by administrative users attempting to deal with replication problems (e.g. dealing with Lost+Found entries). "Search with Meta-Data" is an extended operation that is modeled on the LDAP search operation [RFC2251]. There is an additional parameter that indicates what additional data should be returned be the search. The following values are permitted: - deletedEntries - Any deleted entries in the scope of the search are returned. Deleted entries can be distinguished from non- deleted entries because the deleted entries will have a value in their deletedEntryCSN attribute. If the deletedEntries controlValue is given, the deletedEntryCSN attribute is automatically added to the AttributeDescriptionList of the search. - attributeChangeState - Each attribute value returned as part of the search will be returned as a triple consisting of the attribute value, the deleted flag associated with the value, and the modificationCSN associated with the value. The formal specification of the Search with Meta-Data extended operation is given in Section 5.3. Note: Search with Meta-Data is designed as an extended operation rather than a control because the format of the returned data (sets of triples) is different from a normal LDAP search operation. Other than this, Search with Meta-Data operates the same as search. 3.15 Changing Replication Meta-Data When fixing a replication problem, administrators need a way to modify meta-data values that are normally treated as operational attributes (createdEntryCSN, entryUUID) or as completely hidden data (deletedEntryCSN, deleted flag, modificationCSN). This set of extended operations mirrors the normal LDAP operations that allow modification, but they allow modification of the associated meta- data as well. 3.15.1 Add with Meta-Data The Add with Meta-Data extended operation is modeled on the LDAP Add operation [RFC2251]. The differences from the standard LDAP Add operation are: - Each value is specified as a triple consisting of the value, the deleted flag to be associated with that value, and the modificationCSN to be associated with that value. - A value may be supplied for the createdEntryCSN attribute. - A value may be supplied for the entryUUID attribute. Moats, et al Expires September 2003 [Page 12] INTERNET DRAFT Mandatory LDAP Replica Management March 2003 - If the Add with Meta-Data extended operation is executed on a readonly replica it will be executed locally rather than returning a referral to an updateable replica. The formal specification of Add with Meta-Data is in Section 5.3. 3.15.2 Delete with Meta-Data The Delete with Meta-Data extended operation is modeled on the LDAP Delete operation [RFC2251]. The differences from the standard LDAP Delete operation are: - A deletedEntryCSN may be supplied with the Delete with Meta-Data extended operation. In this case the delete operation is performed as in [RFC2251], except that the value of the deletedEntryCSN is taken from the controlValue. - It may be flagged as a noRecordDelete. In this case the targeted entry is deleted with no meta-data left behind (no deletedEntry or "tombstone"). - If the Delete with Meta-Data extended operation is executed on a readonly replica it will be executed locally rather than returning a referral to an updateable replica. The formal specification of the Delete with Meta-Data extended operation is given in Section 5.3. 3.15.3 Modify with Meta-Data The Modify with Meta-Data extended operation is modeled on the LDAP Modify operation [RFC2251]. The differences from the standard LDAP Modify operation are: - Each value is specified as a triple consisting of the value, the deleted flag to be associated with that value, and the modificationCSN to be associated with that value. - The createdEntryCSN attribute may be modified. - The entryUUID attribute may be modified. - If the Modify with Meta-Data extended operation is executed on a readonly replica it will be executed locally rather than returning a referral to an updateable replica. The formal specification of Modify with Meta-Data is in Section 5.3. 3.16 Write-Unwriteable Control There are a number of attributes defined in [InfoMod] which are marked "NO-USER-MODIFICATION". When fixing replication problems, there may be times when these values need to be changed. In addition, when administering readonly replicas it may be necessary for administrators to modify values on readonly replicas. The Write-Unwriteable control handles these cases. Moats, et al Expires September 2003 [Page 13] INTERNET DRAFT Mandatory LDAP Replica Management March 2003 The control can be attached to an LDAP modify operation. If the control is present, it allows the modify operation to change values that are marked "NO-USER-MODIFICATION" (the only exception is attributes which are locally calculated by the implementation). Also, if the control is present, modify operations can be executed on readonly replicas. In this case the readonly replica will not return a referral to an updateable replica and the operation will be performed on the readonly replica. The formal specification of the control is given in Section 5.5. The current list of NO-USER-MODIFICATION attributes in [InfoMod] is: attributeExclusionFilter (Section 8.2.4) attributeInclusionFilter (Section 8.2.5) replicationStatus (Section 8.2.7) replicaType (Section 8.2.8) updateVector (Section 8.2.9) secondsToWaitDefault (Section 8.2.18) secondsToWait1 (Section 8.2.19) secondsToWait2 (Section 8.2.21) 4 Common Tasks There are many tasks that administrators need to perform in a replicated environment. This section describes many typical tasks and describes how they are performed in terms of the atoms defined above. 4.1 Add a new replica to an existing replica group Assume there is an existing replica group for a given area of replication. To add one new server (which does not already hold a copy of the area) to the replica group, perform the following steps: 1. Copy the base entry of the area of replication from one of the current servers to the new server (Section3.3). 2. On one of the existing servers in the replica group, create the replicaSubentry for the new server with the replicaOnline attribute set to "false" (Section 3.4). Replication will copy this to all the existing replicas (trigger immediate replication per Section 3.12 if necessary). Since replicaOnline does not replicate, it needs to be set "false" on all existing servers. 3. On the new server, create a replicaSubentry for one of the other servers in the replica group with the replicaOnline attribute set to "false". The UUID of this replicaSubentry MUST be identical to the UUID it has on the existing replicas, so Add with Meta- Data (Section 3.15.1) should be used to create the entry. 4. If the authentication mechanism used for replication requires credentials, make appropriate entries on all existing servers for the new server and make appropriate entries for all the existing servers on the new server. If any of the credential data is in the current area of replication, use Add with Meta-Data on the Moats, et al Expires September 2003 [Page 14] INTERNET DRAFT Mandatory LDAP Replica Management March 2003 new server and make the UUIDs the same as those on the existing servers. 5. Create the replication agreement(s) on one of the existing servers and let it replicate to the other existing servers (Section 3.7). 6. Set the replicaOnline attribute to true for the new server on both the source and target servers (Section 3.11). 7. On the source server, trigger an immediate "full update" replica cycle (Section 3.12). The data replicated will include the replicaSubentries and replication agreements for all other servers in the replica group since they are in the area of replication. 8. On the new server, set the replicaOnline attributes in the replicaSubentries for all the other servers to "true". 9. On the servers in the replica group other than the source server, set the replicaOnline attribute in the replicaSubentry for the target server to "true". 4.1.1 Large area of replication support In some cases, an area of replication is so large or available bandwidth so small that out-of-band mechanisms (e.g. mailing a tape) need to be used to transport the initial copy from the source to the target. The target then needs to be updated with changes made to the source since the copy was made. While LDIF is typically used to transport bulk LDAP data, it is not suitable here because it does not transport replication meta-data (CSNs, GUIDs, etc.). To ensure that all needed data is available; bulk replication data is stored as a stream of protocol elements from [Proto] in network byte order. There is an LDAP extended operation that will either cause a server to generate or read a stream of protocol elements (see Section 3.12). Use of the extended operation to generate or a read a file is OPTIONAL, but if the file is generated it MUST be a stream of protocol elements. The following restrictions are imposed on the data stream: - The BIND operation is unauthenticated. The extended operation that causes the destination server to read protocol elements from a local file should be restricted to privileged users only (See Section 6); this provides authentication for the operation. - The "supplier initiated" protocol flow is used. - A "full update" replication session is assumed. - Since input is coming from a file, there are no responses. The stream of protocol elements should assume that all response codes are "REPL_SUCCESS". - Since this is a "full update" session, [Proto] specifies that "the consumer's update vector should be assumed to be set to times 'earlier than' the oldest times known to the supplier server." Thus the protocol stream can be generated without receiving a createGroupingResponse extended operation from the consumer. Moats, et al Expires September 2003 [Page 15] INTERNET DRAFT Mandatory LDAP Replica Management March 2003 - The value of the groupCookie in the endGroupingRequest extended operation is ignored. Once the file has been loaded on the destination server, the destination server should initiate a replication session with the source server (Section 3.12). This will pick up changes that have occurred since the original file was created. In summary, to add a new server to an existing replica group for a large replica, follow these steps (steps 1-7 are the same as steps 1-7 of Section 4.1): 1. Copy the base entry of the area of replication from one of the current servers to the new server (Section3.3). 2. On one of the existing servers in the replica group, create the replicaSubentry for the new server with the replicaOnline attribute set to "false" (Section 3.4). Replication will copy this to all the existing replicas. Since replicaOnline does not replicate, it needs to be set "false" on all existing servers. (Trigger immediate replication per Section 3.12 if necessary.) 3. On the new server, create a replicaSubentry for one of the other servers in the replica group with the replicaOnline attribute set to "false". The UUID of this replicaSubentry MUST be identical to the UUID it has on the existing replicas, so Add with Meta- Data (Section 3.15.1) should be used to create the entry. 4. If the authentication mechanism used for replication requires credentials, make appropriate entries on all existing servers for the new server and make appropriate entries for all the existing servers on the new server. If any of the credential data is in the current area of replication, use Add with Meta-Data on the new server and make the UUIDs the same as those on the existing servers. 5. Create the replication agreement(s) on one of the existing servers and let it replicate to the other existing servers (Section 3.7). 6. Set the replicaOnline attribute to "true" for the new server on both the source and target servers (Section 3.11). 7. Generate an update file on the source server (Section 3.12) 8. Transport the file to the destination site by any appropriate means (FTP, express parcel, postal mail, etc.) 9. Load the file onto the destination server (create a disk file from tape if necessary) 10. Import the file into LDAP (Section 3.12) 11. Set the replicaOnline attribute to true for the new server 12. Trigger a replica session between the source and destination machine to pick up changes since the file was generated (Section 3.12) 4.2 Verify replication information is present between two servers This section describes steps that verify the proper replication information is present for replication to occur between two replicas. There are two parts to this process: Moats, et al Expires September 2003 [Page 16] INTERNET DRAFT Mandatory LDAP Replica Management March 2003 1. Verify that the necessary objects have been created on both replicas. These objects include replicaSubentry objects representing the replicas, replication agreements describing consumer-supplier relationships between the replicas, and the credential and schedule objects named in the agreements. 2. Verify that it is valid to replicate between the replicas. For example, a fractional replica cannot act as a supplier to a full replica. 4.2.1 Verify that replication objects exist This section describes how to verify that the necessary replication objects exist. Within this section the term replica refers to one of the two replicas for which information is being verified. It is assumed that an administrator has identified the replicas (both the IP address/host name and the replicaId), the area of replication, and which of the replicas are expected to act as suppliers. One or both of the replicas must be a supplier to the other replica. 1. The client SHOULD invoke an object scope search specifying the DN of the root entry of the area of replication. This entry MUST exist on both servers, and the objectclass attribute values MUST include the value replicationContext. 2. On the replicas which the administrator has indicated is a supplier, the client SHOULD invoke a baseObject scope search of the root DSE requesting the replicationSubentries attribute. The value for this attribute MUST name exactly one replicaSubentry object that is a child of the root entry of the area of replication. The distinguished name of the entry MUST be of the form: cn=, 3. On each supplier replica, the client SHOULD invoke a baseObject scope search specifying the DN of replicaSubentry that was identified in the replicaSubentries attribute of the root DSE in the previous step. This object MUST exist for replication to occur, and MUST include the value replicaSubentry in the list of objectclass values. The client SHOULD invoke an object scope search for the other server. The base DN for this search is of the form: cn=, where is the replicaId of the other replica. This object MUST exist, and MUST include the value replicaSubentry in the list objectclass values. 4. On each supplier replica, the client SHOULD invoke a oneLevel search, specifying the DN of replicaSubentry for that replica as the baseObject, and a search filter like: (&(objectclass=replicationAgreementSubentry-2) (replicaDN=)) where ; Mon, 3 Mar 2003 06:52:22 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h23BoPV15335 for ietf-ldup-bks; Mon, 3 Mar 2003 03:50:25 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h23BoOY15329 for ; Mon, 3 Mar 2003 03:50:24 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18681; Mon, 3 Mar 2003 06:48:23 -0500 (EST) Message-Id: <200303031148.GAA18681@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldup-urp-07.txt Date: Mon, 03 Mar 2003 06:48:23 -0500 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF. Title : LDUP Update Reconciliation Procedures Author(s) : S. Legg, A. Payne Filename : draft-ietf-ldup-urp-07.txt Pages : 32 Date : 2003-2-28 This document describes the procedures used by Lightweight Directory Access Protocol (LDAP) directory servers or X.500 directory servers to reconcile updates performed by autonomously operating directory servers in a distributed, replicated directory service, using the LDAP Duplication/Replication/Update protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldup-urp-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldup-urp-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-28125506.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-urp-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-urp-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-28125506.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Wed Mar 5 06:38:55 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27146 for ; Wed, 5 Mar 2003 06:38:55 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h25BXoh10226 for ietf-ldup-bks; Wed, 5 Mar 2003 03:33:50 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h25BXn310222 for ; Wed, 5 Mar 2003 03:33:49 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26445; Wed, 5 Mar 2003 06:31:45 -0500 (EST) Message-Id: <200303051131.GAA26445@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldup-protocol-04.txt Date: Wed, 05 Mar 2003 06:31:44 -0500 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF. Title : The LDUP Replication Update Protocol Author(s) : E. Stokes Filename : draft-ietf-ldup-protocol-04.txt Pages : 19 Date : 2003-3-4 The protocol described in this document is designed to allow one LDAP server to replicate its directory content to another LDAP server. The protocol is designed to be used in a replication configuration where multiple updateable servers are present. Provisions are made in the protocol to carry information that allows the server receiving updates to apply a total ordering to all updates in the replicated system. This total ordering allows all replicas to correctly resolve conflicts that arise when LDAP clients submit changes to different servers that later replicate to one another. All protocol elements described here are LDAPv3 extended operations and controls. LDAPv3 is described in RFC 2251 [LDAPv3]. Some LDAPv3 extended operations and controls described here are LDAPv3 extended operations used to group related operations. The protocol elements used for grouping are described in LDAPv3: Grouping of Related Operations [GROUPING]. Certain terms used in this document are defined in the document 'LDAP Replication Architecture' [ARCHITECTURE]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-protocol-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldup-protocol-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldup-protocol-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-4174352.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-protocol-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-protocol-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-4174352.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Thu Mar 6 06:32:43 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03797 for ; Thu, 6 Mar 2003 06:32:42 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h26BUYZ10228 for ietf-ldup-bks; Thu, 6 Mar 2003 03:30:34 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h26BUX310222 for ; Thu, 6 Mar 2003 03:30:33 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03282; Thu, 6 Mar 2003 06:28:28 -0500 (EST) Message-Id: <200303061128.GAA03282@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldup-model-08.txt Date: Thu, 06 Mar 2003 06:28:28 -0500 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF. Title : LDAP Replication Architecture Author(s) : J. Merrells, E. Reed, U. SRINIVASAN Filename : draft-ietf-ldup-model-08.txt Pages : 35 Date : 2003-3-5 This architectural document outlines a suite of schema and protocol extensions to LDAPv3 that enables the robust, reliable, server-to- server exchange of directory content and changes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldup-model-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldup-model-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-5141123.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-model-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-model-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-5141123.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Fri Mar 7 06:59:01 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22317 for ; Fri, 7 Mar 2003 06:59:00 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h27Btit14319 for ietf-ldup-bks; Fri, 7 Mar 2003 03:55:44 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h27Bth314312 for ; Fri, 7 Mar 2003 03:55:43 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21349; Fri, 7 Mar 2003 06:53:38 -0500 (EST) Message-Id: <200303071153.GAA21349@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldup-lcup-04.txt Date: Fri, 07 Mar 2003 06:53:38 -0500 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF. Title : LDAP Client Update Protocol Author(s) : R. Megginson, M. Smith, O. Natkovich, J. Parham Filename : draft-ietf-ldup-lcup-04.txt Pages : 27 Date : 2003-3-6 This document defines the Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP). The protocol is intended to allow an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldup-lcup-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldup-lcup-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-6125307.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-lcup-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-lcup-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-6125307.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Fri Mar 7 06:59:02 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22344 for ; Fri, 7 Mar 2003 06:59:02 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h27Btur14360 for ietf-ldup-bks; Fri, 7 Mar 2003 03:55:56 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h27Btt314355 for ; Fri, 7 Mar 2003 03:55:55 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21386; Fri, 7 Mar 2003 06:53:50 -0500 (EST) Message-Id: <200303071153.GAA21386@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldup-mrm-02.txt Date: Fri, 07 Mar 2003 06:53:50 -0500 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF. Title : Mandatory LDAP Replica Management Author(s) : R. Moats, R. Huber, J. McMeeking Filename : draft-ietf-ldup-mrm-02.txt Pages : 32 Date : 2003-3-6 The goal of standards for LDAP replication is to allow interoperable replication among products from many different vendors. Defining the mechanism to move data among replicas is a necessary part of this work, but management of the replicated environment must also be standardized for replication to be truly interoperable. This document presents the replication management functions that must be performed. Whenever possible, these functions are defined in terms of existing LDAP functionality using existing LDAP operations and existing data definitions. In some cases, changes or additions to the existing model are required, and specifications for these changes are included in this document A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-mrm-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldup-mrm-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldup-mrm-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-6125326.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-mrm-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-mrm-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-6125326.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Fri Mar 7 07:55:07 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22319 for ; Fri, 7 Mar 2003 06:59:00 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h27Btd514299 for ietf-ldup-bks; Fri, 7 Mar 2003 03:55:39 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h27Btc314292 for ; Fri, 7 Mar 2003 03:55:38 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21328; Fri, 7 Mar 2003 06:53:33 -0500 (EST) Message-Id: <200303071153.GAA21328@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldup-usage-profile-04.txt Date: Fri, 07 Mar 2003 06:53:33 -0500 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF. Title : General Usage Profile for LDAPv3 Replication Author(s) : R. Huber, G. Maziarski, R. Moats Filename : draft-ietf-ldup-usage-profile-04.txt Pages : 18 Date : 2003-3-6 Support for replication in LDAP directory systems is often one of the key factors in the decision to deploy them. But replication brings design constraints along with its benefits. We discuss some of the factors that should be taken into consideration when designing a replicated directory system. Both programming and architectural/operational concerns are addressed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-usage-profile-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldup-usage-profile-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldup-usage-profile-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-6125258.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-usage-profile-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-usage-profile-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-6125258.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Fri Mar 7 07:55:08 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22318 for ; Fri, 7 Mar 2003 06:59:00 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h27BtpZ14340 for ietf-ldup-bks; Fri, 7 Mar 2003 03:55:51 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h27Bto314336 for ; Fri, 7 Mar 2003 03:55:50 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21368; Fri, 7 Mar 2003 06:53:45 -0500 (EST) Message-Id: <200303071153.GAA21368@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldup-infomod-06.txt Date: Fri, 07 Mar 2003 06:53:45 -0500 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF. Title : LDUP Replication Information Model Author(s) : R. Huber, J. McMeeking, R. Moats Filename : draft-ietf-ldup-infomod-06.txt Pages : 32 Date : 2003-3-6 [LDUP Model] describes the architectural approach to replication of LDAP directory contents. This document describes the information model and schema elements which support LDAP Replication Services which conform to [LDUP Model]. Directory schema is extended to provide object classes, subentries, and attributes to describe areas of the namespace which are under common administrative authority, units of replication (ie, subtrees, or partitions of the namespace, which are replicated), servers which hold replicas of various types for the various partitions of the namespace, which namespaces are held on given servers, and the progress of various namespace management and replication operations. Among other things, this knowledge of where directory content is located will provide the basis for dynamic generation of LDAP referrals for clients who can follow them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-infomod-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldup-infomod-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldup-infomod-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-6125316.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-infomod-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-infomod-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-6125316.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Fri Mar 7 09:49:18 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06321 for ; Fri, 7 Mar 2003 09:49:15 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h27Eg0h26136 for ietf-ldup-bks; Fri, 7 Mar 2003 06:42:00 -0800 (PST) Received: from netscape.com (c3po.aoltw.net [64.236.137.25]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h27Efp326122 for ; Fri, 7 Mar 2003 06:41:51 -0800 (PST) Received: from dredd.mcom.com (dredd.nscp.aoltw.net [10.169.8.48]) by netscape.com (8.10.0/8.10.0) with ESMTP id h27Efil13640 for ; Fri, 7 Mar 2003 06:41:44 -0800 (PST) Received: from netscape.com ([10.169.192.54]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HBDVGV00.VBT for ; Fri, 7 Mar 2003 06:41:19 -0800 Message-ID: <3E68AF0B.3050406@netscape.com> Date: Fri, 07 Mar 2003 07:39:07 -0700 From: richm@netscape.com (Rich Megginson) Organization: Netscape - Enterprise Products User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ldup@imc.org Subject: Response to LCUP WG Last Call Issues References: <000201c269ea$bdf4dc80$775f050a@D7ST2111> Content-Type: multipart/alternative; boundary="------------060503000400070307000309" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------060503000400070307000309 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit >Issue Number: 1 > >Description: Complete LCUP Client Update is Problematic > >Summary: > >Concern was expressed over an LCUP Client that repeats an original >request may find that the copy "synchronized" by LCUP has changed >significantly. > >Concensus: > >The protocol basically needs not only to send a copy of >all entries which are within scope which have significantly >changed, but also send a list of UUIDs and CSNs of all the >entries which have not changed. This would not only allows >the client to determine the set of entries which have been >deleted from the fragment, but also determine if an entry >returned but not updated needs to be refreshed. In which >case, it can request a copy of those entries which it >believes need to be refreshed. This can be done out of >band with a persist operation. > >Relevant Posting(s): > >http://www.imc.org/ietf-ldup/mail-archive/msg01511.html > Response: The other authors and I don't think this is necessary. The main reason this is needed is that it is difficult for servers to keep track of which entries have left the result set due to meta data changes such as access control, configuration, etc. So, a server could simply send unchanged entries instead of sending entry left set notifications. We don't think this needs to be addressed in LCUP for the following reasons: 1) It is expected that changes which would cause the server to have a hard time calculating which entries have left the result set will be very infrequent. 2) The 04 version of the LCUP draft provides a mechanism to have the server tell the client that a reload is required at any time. We feel that, in most cases, returning all present entries will be nearly as expensive as a full reload. 3) There will be cases where the server may have a hard time figuring out which entries are even present, much less have left the result set, so a reload will be required in those cases as well. >Issue Number: 2 > >Description: Persist Doesn't Support Eventual Convergence > >Summary: > >This issue was raised in the context of Issue #1. It basically >states that the server should support eventual convergence of >the client's information with equivalent information on the server. > >Concensus: > >The server needs to be required to generate the set of >events necessary for eventual convergence of the client's >copy of the DIT fragment. > >The spec currently only appears to support "lossy convergence." > >Relevant Postings: > >http://www.imc.org/ietf-ldup/mail-archive/msg01511.html >http://www.imc.org/ietf-ldup/mail-archive/msg01594.html >http://www.imc.org/ietf-ldup/mail-archive/msg01595.html >http://www.imc.org/ietf-ldup/mail-archive/msg01596.html >http://www.imc.org/ietf-ldup/mail-archive/msg01597.html > Response: I think the majority of this was answered in the response to #1 above. If I missed something, please let me know. >Issue Number: 3 > >Description: Confusing Cookie/Scheme Text > >Summary: > >The document defines a cookie as representing client state, >but it then says it may be sent initially (without value) >to indicating the desired scheme. > >Concensus: > >The specification would be a lot clearer if the cookie/scheme >were defined as: > > LCUPScheme ::= LDAPOID > LCUPCookie ::= SEQUENCE { > scheme LCUPScheme, > value OCTET STRING > } > >and request control was defined as: > > ClientUpdateControlValue ::= SEQUENCE { > updateType ENUMERATED { > synchronizeOnly (0), > synchronizeAndPersist (1), > persistOnly (2) }, > sendCookieInterval INTEGER OPTIONAL, > scheme LCUPScheme OPTIONAL, > cookie LCUPCookie OPTIONAL > } > >where scheme may only be specified on initial request to indicate >desired scheme and cookie must be provided on subsequent >requests. > >Relevant Posting(s): > >http://www.imc.org/ietf-ldup/mail-archive/msg01606.html > Response: Changed, and the scheme is no longer a part of the cookie. Thanks for the suggestion. >Issue Number: 4 > >Description: Clarification of Cookie Specification > >Summary: > >Section 4.2 states: "The cookie value MUST be included except when a >client has no stored state; i.e., when the client is requesting a full >synchronization" > >Concensus: > >Clarification is needed as to which of the following this text refers >to (or an indication that it refers to all of the following): > > + ClientUpdateControlValue > > + EntryUpdateControlValue > > + ClientUpdateDoneControlValue > >Relevant Posting(s): > >http://www.imc.org/ietf-ldup/mail-archive/msg01506.html > Response: The LCUP 04 draft is much clearer about when and how a cookie should be returned. >Issue Number: 5 > >Description: New Cookie w/No Entry Mechanism > >Summary: > >LCUP needs to provide a mechanism which allows the server to send, >at any time, a new cookie to the client without requiring the server >to send an entry. > >Concensus: > >This is useful in cases where the cookie the server previously >sent is too old to be useful and a new cookie would allow more >efficient resync if the session where to be unexpectedly dropped. >In fact, the cookie may be so old to cause a full sync to occur >when no changes would be necessary if the cookie were updated. > >Relevant Posting(s): > >http://www.imc.org/ietf-ldup/mail-archive/msg01518.html >http://www.imc.org/ietf-ldup/mail-archive/msg01520.html >http://www.imc.org/ietf-ldup/mail-archive/msg01521.html >http://www.imc.org/ietf-ldup/mail-archive/msg01522.html >http://www.imc.org/ietf-ldup/mail-archive/msg01524.html >http://www.imc.org/ietf-ldup/mail-archive/msg01526.html >http://www.imc.org/ietf-ldup/mail-archive/msg01532.html >http://www.imc.org/ietf-ldup/mail-archive/msg01534.html > Response: The LCUP 04 allows for a "Sync Update Informational Response" which can be used to return the cookie (or other information) at any time, without using an intermediate response. >Issue Number: 6 > >Description: UUID Syntax and Matching Rule > >Summary: > >The syntax of UUID is directory string, and moreover, the matching rule >is case ignore match. It was suggested that this combination is overly >limiting and that the syntax be changed to octet string. This is made >even more apparent by the fact that this document leaves standardization >of the value generation to a future specification. > > >Concensus: > >First and foremost, UUID support needs to be mandatory. The >protocol won't work otherwise. > >Instead of returning the UUID as an attribute value (which >are subject to normal access controls), it should be returned >within the control (which *should* be subject to some kind of >access restrictions). This to avoid having to deal with no >UUID as being a valid response to a CRITICAL update request. >Instead, if the server is unwilling to provide the UUID, the >CRITICAL request will fail. > >A specification of how the server represents UUIDs (and CSNs) >in the directory should be standardized, but suggest this be >done in a separate document... as, if UUIDs are passed in the >control, LCUP doesn't depend on the particulars representation >in the DIT. > >For the specifications of entryUUID (and entryCSN), using >either octetString/octetStringMatch or UUID/UUIDMatch >(where UUID was a constrained OCTET STRING with a string >syntax). The later is preferable. > >There is no need to leave the string syntax up to future >standardization. ISO/IEC 11578:1996 can be referenced. > >Relevant Posting(s): > >http://www.imc.org/ietf-ldup/mail-archive/msg01505.html >http://www.imc.org/ietf-ldup/mail-archive/msg01508.html >http://www.imc.org/ietf-ldup/mail-archive/msg01544.html >http://www.imc.org/ietf-ldup/mail-archive/msg01510.html >http://www.imc.org/ietf-ldup/mail-archive/msg01546.html >http://www.imc.org/ietf-ldup/mail-archive/msg01552.html >http://www.imc.org/ietf-ldup/mail-archive/msg01553.html >http://www.imc.org/ietf-ldup/mail-archive/msg01555.html >http://www.imc.org/ietf-ldup/mail-archive/msg01557.html >http://www.imc.org/ietf-ldup/mail-archive/msg01558.html >http://www.imc.org/ietf-ldup/mail-archive/msg01563.html >http://www.imc.org/ietf-ldup/mail-archive/msg01567.html >http://www.imc.org/ietf-ldup/mail-archive/msg01568.html > Response: Done, and thanks for the suggestion. The new LCUP draft specifies a mechanism by which the server's UUIDAttribute (name or OID) can be returned to the client so that the client can do searches. This element is optional - only for servers that have a UUID attribute and support searches. >Issue Number: 7 > >Description: Trigger Mechanism or Not? > >Summary: > >The draft states that it "is intended to allow LDAP clients to >synchronize with the content stored by LDAP servers". but also states >that it wants to solve the problem of triggered actions (Section 3, >Bullet 3). > >Concensus: > >Most of the rest of the draft is consistent with the notion of >synchronization, but tends to downplay support for triggered responses. >Do we want this to be a useful event driver, or is the idea that we just >preserve the easy stuff of what prior drafts could do? > >Specifically, the left-out items in Sections 5.1, 5.2, and 5.3 deter >from the effectiveness of the "persist" mode. > >Curent users of Persistent Search rely on the notion of change types. >Section 5.2 assumes that change types are used for partial replication, >and thus discounts them as useful for LCUP. > >Triggered actions should be within LCUP's scope. The LCUP authors have >tried to balance the server implementation burden with the client >implementation burden. In particular, I would really like to >avoid creating an LCUP protocol that requires a server to store >client-specific state (that just won't scale when their are thousands >or hundreds of thousands of clients). > >A related comment: section 5 should be moved to an appendix that >is named "Features Left Out of LCUP." It is not core to LCUP, but is >useful to provide historical context and rationale for why some things >are not included in LCUP. > >Relevant Posting(s): > >http://www.imc.org/ietf-ldup/mail-archive/msg01519.html >http://www.imc.org/ietf-ldup/mail-archive/msg01554.html >http://www.imc.org/ietf-ldup/mail-archive/msg01556.html >http://www.imc.org/ietf-ldup/mail-archive/msg01562.html > Response: We made it clear in the new 04 LCUP draft that it is not the intention of LCUP to fully replace all existing persistent and triggered search applications. We also moved those sections mentioned to a "Features Left Out of LCUP" appendix as suggested. >Issue Number: 8 > >Description: Alias Dereferencing > >Summary: > >The server instructions for alias deferencing are found in the Client >Side Considerations section. > >Concensus: > >Specifically, it says that a server will respond with protocolError if >any other than neverDerefAliases or derefFindingBaseObj is specified. >This should be moved to, copied to, or referenced in a more server-centric >part of the draft. It should say "... the server MUST return protocolError..." > >Relevant Posting(s): > >http://www.imc.org/ietf-ldup/mail-archive/msg01516.html > Response: Done. Thanks for the suggestion. >Issue Number: 9 > >Description: Laundry List > >Summary: > >This posting contains a copy of feedback provided to the document >editors privately. > >Concensus: > >Some of the specific comments in the postings below have been discussed and >addressed as a part of other issues. Other comments are strictly editorial >in nature and should be incorporated. The document editors should raise >comments otherwise classified to the mailing list and obtain clarification >from the WG members. > >Relevant Posting(s): > >http://www.imc.org/ietf-ldup/mail-archive/msg01514.html >http://www.imc.org/ietf-ldup/mail-archive/msg01515.html >http://www.imc.org/ietf-ldup/mail-archive/msg01517.html > Response: There are a lot of issues here, most (if not all) of which have been addressed in the LCUP 04 draft. I would suggest that Kurt (and others) take a look at the new draft to see if the issues have been addressed appropriately and sufficiently. >Issue Number: 10 > >Description: Search Filter and Returned Entries > >Summary: > >The draft states in Section 5.2 that "For LCUP, the intention is full >synchronization, not partial.". > >Concensus: > >LCUP must support both partial (not necessarily all entries within >scope) and fractional (not necessarily all attributes of each entry) >synchronization. > >Relevant Posting(s): > >http://www.imc.org/ietf-ldup/mail-archive/msg01523.html >http://www.imc.org/ietf-ldup/mail-archive/msg01530.html >http://www.imc.org/ietf-ldup/mail-archive/msg01539.html > Response: That section mentioned above has been moved to the appendix and is no longer relevant to the LCUP protocol. LCUP does support partial and fractional synchronization. >Issue Number: 11 > >Description: Does entryDeleted break the protocol? > >Summary: > >The description for entryDeleted states at first that it indicates that >the entry being returned has been deleted--then goes on to say that it >also might indicate that the entry has left the result set. In the case >of it being due to the entry has left the result set, we need to answer >these: >1) If due to a rename, what DN is used (old or new) >2) If the entry is not in the result set, doesn't it break the LDAP >protocol to return it (it doesn't match the filter)? > >Concensus: > >No change required. Clarification was provided on the mailing list. > >Relevant Posting(s): > >http://www.imc.org/ietf-ldup/mail-archive/msg01525.html >http://www.imc.org/ietf-ldup/mail-archive/msg01545.html > Response: LCUP 04 makes it clear what it means for an entry to have left the result set. And yes, this does "break" the LDAP protocol (specifically as regards to search responses), but it is a necessary break to provide a lightweight sync mechanism. >Issue Number: 12 > >Description: Is the EntryUpdateControlValue optional? > >Summary: > >First, is the EntryUpdateControlValue supposed to be returned during an >initial synchronization session? > >Next, Section 4.8 states: "Each SearchResultEntry may have an >entryUpdate control attached. ". This indicates that the control is >optional. Is it? > >Concensus: > >No further discussion took place on the list on this topic. > >Relevant Posting(s): > >http://www.imc.org/ietf-ldup/mail-archive/msg01527.html > Response: LCUP 04 makes this much more clear. >Issue Number: 13 > >Description: What is "a while"? > >Summary: > >Section 4.8 states "it MUST wait for a while before attempting another >synchronization session with the server. " > > >Concensus: > >If we're going to use an imperative like MUST, we ought to not use >vague language like "a while". I suggest we drop the MUST anyway--is >there an interoperability issue here? > >The "MUST wait for a while" would be consistent with most other network >algorithms. If it doesn't wait, it may cause unintentional denial of >service attacks by swamping the server with connection requests. > >Since LCUP is proposing persistent open TCP connections and >the use of an error code for resources exhaustion, "acceptable" client >behavior ought to be specified to help determine a "malicious" client. > >Since list comments imply that different use cases of LCUP require >different back off periods, I'd think that having the server specify >the initial backoff period in seconds with the lcupResorcesExhausted error >would be worth consideration. > >Relevant Posting(s): > >http://www.imc.org/ietf-ldup/mail-archive/msg01528.html >http://www.imc.org/ietf-ldup/mail-archive/msg01547.html >http://www.imc.org/ietf-ldup/mail-archive/msg01559.html >http://www.imc.org/ietf-ldup/mail-archive/msg01569.html >http://www.imc.org/ietf-ldup/mail-archive/msg01571.html > Response: The LCUP 04 draft says that a "client SHOULD wait 5 seconds before attempting a retry". It also goes on to say that clients SHOULD use an exponential backoff strategy, but this is not required, as different clients may want to use different backoff strategies. >Issue Number: 14 > >Description: note about syncing to different servers > >Summary: > >What does the "(Note that the client can synchronize with different >servers during different synchronization sessions.) " mean in the >context of the paragraph it's in? > >Concensus: > >No further discussion took place on the list on this topic. > >Relevant Posting(s): > >http://www.imc.org/ietf-ldup/mail-archive/msg01529.html > Response: This has been removed. >Issue Number: 15 > >Description: Need for lcupReloadRequired > >Summary: > >Why is this error needed? It seems that if this scenario exists, the >server would simply send the full set of entries, and a new cookie. The >current specification indicates that the client would try to sync, >receive an error, then try to sync again with an empty cookie. Is there >a benefit to the extra step? > >Concensus: > >Yes, it tells the client to delete everything it has. Otherwise >it might be left with entries which should be have been deleted >but were not. > >Of course, given that LCUP doesn't ensure this doesn't happen >under success resync is of concern. > >Relevant Posting(s): > >http://www.imc.org/ietf-ldup/mail-archive/msg01531.html >http://www.imc.org/ietf-ldup/mail-archive/msg01535.html >http://www.imc.org/ietf-ldup/mail-archive/msg01533.html > Response: LCUP 04 provides a mechanism for servers to tell clients, at any time, that a reload is required. I believe the extra step is nice if the client is not currently prepared to do a resync. Why? Is it really that much trouble for the client to issue another LCUP search request for a full resync? >Issue Number: 16 > >Description: sync, then sync and persist > >Summary: > >Why is there a suggestion in Section 6 to "perform an initial >synchronization...(synchronizeOnly)" and then immediately perform a >synchronizeAndPersist session? Why not just perform a >synchronizeAndPersist session to begin with? > >Concensus: > >What's needed is a intermediate response PDU indicating >the end of the synchronize phase and provide a new cookie. >This not only works when there are no sync events, but also >works when there are persist event occurring during >synchronization. Calling it an "end of sync phase" marker >doesn't prevent an overlapping "persist" phase. > >There should be no problem with allowing an overlapping >"persist" phase (as the current I-D does) AS LONG AS it >is clear to the client when it has a complete copy of the >DIT fragment. > >Then, we can work on providing the client with a complete >and accurate copy... > >Relevant Posting(s): > >http://www.imc.org/ietf-ldup/mail-archive/msg01536.html >http://www.imc.org/ietf-ldup/mail-archive/msg01541.html >http://www.imc.org/ietf-ldup/mail-archive/msg01550.html >http://www.imc.org/ietf-ldup/mail-archive/msg01551.html > Response: No intermediate response PDU is required. The LCUP 04 draft provides a "Sync Update Informational Response" to handle this case. Also, the new draft clearly states that overlap of sync and persist phase is not permitted. >Issue Number: 17 > >Description: rename of baseObject (was something else) > >Summary: > >At 10:20 PM 2002-09-03, Jim Sermersheim wrote: > > >>The scenario I was thinking of is one where the base existed when a >>persistent LCUP session starts, but later is renamed or deleted. >> >> > >Concensus: > >Client Considerations implies noSuchObject is >returned in this case. This needs to be detailed >in Section 4 (along with many other protocol >details found in sections 6 and 7). > >Relevant Posting(s): > >http://www.imc.org/ietf-ldup/mail-archive/msg01538.html >http://www.imc.org/ietf-ldup/mail-archive/msg01543.html >http://www.imc.org/ietf-ldup/mail-archive/msg01548.html >http://www.imc.org/ietf-ldup/mail-archive/msg01549.html > Response: This is addressed in section "4.2 Renaming the Base Object" in the LCUP 04 draft. >Issue Number: 18 > >Description: subordinate references > >Summary: > >The document is quite unclear how references are to be >handled. What happens when a named subordinate referral >object [RFC 3296] within scope of the search is added, >deleted, or modified? > >Concensus: > >One approach would be to return a searchResultReference >with a control much like the EntryUpdateControl, but with >the UUID of the referral object. > >Or one could just redefine (and rename) the >EntryUpdateControl to include the UUID. > >Another approach would be require the presence of >the ManageDsaIT control in the request. This, basically, >requests that all referral objects be treated as >entry objects. However, the problem with this, is that >the ManageDsaIT control may be used to manage other kinds >of knowledge information. It selects a management plane >within the DsaIT. An LCUP with ManageDsaIT should be >treated as a LCUP request within the management plane >normally selected by the ManageDsaIt. > >Another option is to just to say the all referral objects >are treated as entry objects when the LCUP control is >present. > >There may be other options. > >A preference was expressed for something like the first approach >(for add, and mod). And a comment was made that a "delete would >just be a delete." > >Relevant Posting(s): > >http://www.imc.org/ietf-ldup/mail-archive/msg01560.html >http://www.imc.org/ietf-ldup/mail-archive/msg01564.html > Response: We decided to go with something like the first approach, which Kurt elaborated on in his sync I-D. >Issue Number: 19 > >Description: collective attributes, subentries, etc. > >Summary: > >Some statement should be made with how LCUP interacts >with collective attributes appearing both in the >filter and returned entries. The simple approach >would be to say: 1) filter should not contain >assertions upon collective attributes, 2) changes to >an collective subentry will not cause entries within >the collection to be "updated", 3) clients are interested >in maintaining sync with collective attributes should >include the collective subentry within an LCUP request. > >Which leads to another question: > how does a client ask for update of both entry > and subentry DSEs subordinate to the baseObject object? > >This is similar to the subordinate referral issue. One >could generalize the question to: > > How does a client ask for update of all DSEs of > a particular combination of DSE types subordinate > to the baseObject? > > >Concensus: > >No other discussion took place on the list on this topic. > >Relevant Posting(s): > >http://www.imc.org/ietf-ldup/mail-archive/msg01561.html > Response: If subentries are within the scope of the request, and the subentry control is present, the subentries are treated and returned just like normal entries. Virtual (collective, et. al.) attributes are handled just like regular attributes. This means that if you change a virtual attribute definition, you may cause many entries within the search scope to be returned as modified. Alternately, the server may decide that would be too expensive of an operation and simply force the client to resync. It would be nice if there were a search control which would allow the client to specify that no virtual attributes are to be returned. >Issue Number: 20 > >Description: operational attributes > >Summary: > >We need to state how updates to operational attributes (both stored >and not stored) affect LCUP. > >Concensus: > >There are different classes of this: > >1) A server internally increments a numSubordinates attribute on the >parent of an entry being added or deleted (server responding to client >action) >2) A server modifies replication-related information (server responding >to bilateral processes) >3) A server updates the state of a transitional attribute (response to >an internal, timed operation) >4) An entire set of operations like those above that affect the value >of an operational attribute, but the value is generated dynamically, >only when read by a client. >5) A client updates an operational attribute. > >We should also discuss any differences in behavior among the three >different types of operational attribute (directoryOperation, >distributedOperation, dSAOperation). > >Relevant Posting(s): > >http://www.imc.org/ietf-ldup/mail-archive/msg01565.html >http://www.imc.org/ietf-ldup/mail-archive/msg01572.html >http://www.imc.org/ietf-ldup/mail-archive/msg01573.html >http://www.imc.org/ietf-ldup/mail-archive/msg01574.html > Response: If a client requests an operational attribute, then the client should get it - no special handling. >Issue Number: 21 > >Description: Changes to attributes not in attributes list > >Summary: > >When we implemented psearch, there was contention over whether >or not the client should be updated when a modification is made >to an attribute that was not requested by the client. > >Concensus: > >No other discussion occured on the list on this topic, however, >in this case, silence seems to indicate the following intent. > >The case for NOT sending these entries is pretty strong. I'm not >sure what arguments can be made for sending them. In either case, >this needs to be spelled out in the draft. > >Relevant Posting(s): > >http://www.imc.org/ietf-ldup/mail-archive/msg01566.html > Response: The client will only be notified of changes to requested attributes. If a non requested attribute changes, the client will not be notified. For deleted entries, especially in servers that use tombstones that do not contain the full attributes and values of the entry, the server MAY send deleted entry notifications for entries that are not and have never been in the client's result set - the client MUST ignore these. >Issue Number: 22 > >Description: Interaction with other controls? > >Summary: > >How does this control interact with other controls? >How does this control interact with existing search controls? >Paging? Sorting? Matched Values? Duplicate Entries? VLV? etc. > >Concensus: > >There was no further discussion about this topic on the list. > >Relevant Posting(s): > >http://www.imc.org/ietf-ldup/mail-archive/msg01570.html > Response: "LCUP defines neither restrictions nor guarantees about the ability to use the controls defined in this document in conjunction with other LDAP controls, except for the following: A server MAY ignore non-critical controls supplied with the LCUP control. A server MAY ignore an LCUP defined control if it is non-critical and it is supplied with other critical controls. If a server receives a critical LCUP control with another critical control, and the server does not support both controls at the same time, the server SHOULD return unavailableCriticalExtension. It is up to the server implementation to determine if the server supports controls such as the Sort or VLV or similar controls that change the order of the entries sent to the client. But note that it may be difficult or impossible for a server to perform an incremental synchronization in the presence of such controls, since the cookie will typically be based off a change number, or CSN, or timestamp, or some criteria other than an alphabetical order." >Issue Number: 23 > >Description: cookie schemes, why? > >Summary: > >The document doesn't adequately describe why cookie schemes >are necessary... in particular, why would a client ever >want to request a particular scheme? How would a client >determine which schemes where supported by the server? And, >if the server is allowed to support differ schemes in different >subtrees, how would a client determine which schemes where >supported in which subtrees. > >The need to allow the client to request particular cookie >schemes is being questioned after prior concensus was >established on this topic. It was suggested that there >if there is a need for this, then we need to make sure >adequate discovery mechanisms are provided so that client >can which schemes are supported where (yuk). Which is >a topic that has been discussed during the WG meeting >prior to the issuance of this WG Last Call. > >It was also suggested that if there is no reason, that no >means be provided to allow a client to request a particular >scheme. If later some need arises, LCUP can be extended. >That extension would have to deal with scheme discovery >issues. > >Concensus: > >>From past discussions, the main purpose of the scheme was >to facilitate protocol operations in replicated environments. >That is, where the client resumes an LCUP session on a >different server then that which provided the cookie, the >scheme allows the server to determine the cookie format >used by the other server. If the doesn't recognize the >scheme, it can return an error (or a referral to the >servers which do understand the scheme?). > >Concensus in the WG Meeting Prior to the issuance of >this WG Last Call was that a cookie discovery mechanism >was not needed. This was posted to the mailing list in the >form of meeting minutes from that WG Meeting. > >Relevant Posting(s): > >http://www.imc.org/ietf-ldup/mail-archive/msg01607.html > Response: The cookie discovery mechanism has been removed. >Issue Number: 24 > >Description: various LCUP issues > >Summary: > >A posting was made shortly prior to the end of the WG Last call >period containing several comments/issues. > >Concensus: > >No further discussion took place on the list in response to this posting. > >Relevant Posting(s): > >http://www.imc.org/ietf-ldup/mail-archive/msg01608.html > Response: > (Below, I assumed RUV (as in section 7) as the cookie.) > In the case that RUV is returned to the client periodically > during a synchronize session, it may not have much > meaning unless the returned entries are sorted > (as in size limit case in section 7). I would consider that to be a server implementation detail - if the server returns a cookie, it should be able to accept it and use it whenever it is presented with an LCUP search request. I think it is outside the scope of the LCUP draft to impose this sort of implementation detail. > Otherwise, upon error during a synchronization session, > the next synchronization should restart from > the RUV before the failed synchronization not from the last > received RUV before error. > If this is the case, periodic delivery of cookies during > a synchronize section may be meaningless. It's up to the server implementation - if the server returns a cookie, it should be able to use it. > It seems that the above paragraph also holds when a time limit is imposed. > A possible issue with the time limit is that the time to sort the result set > may be larger than the time limit itself. > The sorting may also be required when we decided to cope with errors during > a synchronization session in such a way that avoids restart from the pre-session state. Again, that is a server implementation detail that won't be specified by LCUP. The server should ensure that it returns a cookie to the client if a size or time limit is exceeded. >Issue Number: 25 > >Description: LCUP Draft inline comments > >Summary: > >Many comments, some of which were editorial, are included in the posting >associated with this issue. > >Concensus: > >Some of these issues were discussed separately and would be duplicates of >those above if documented seperately here. Some of them are editorial and >should be incorporated. Comments classified otherwise should be posted to >the mailing list by the document editors for further discussion. > >Relevant Posting(s): > >http://www.imc.org/ietf-ldup/mail-archive/msg01598.html > Response: > > Several features of the protocol distinguish it from LDUP > replication. LCUP is designed such that the server does not need to > maintain state information on behalf of the client. > > TJH: I don't understand how servers won't have to maintain some level > of information related to the client if deleted entries are going > to have to be "remembered" Tombstones? No client state information needs to be saved. > and potentially "cookie" values will > have to be "remembered" as well. If the cookie value is an RUV, then server will have to store this, but it doesn't have to store them on a client by client basis. Each client will just refer to the RUV used by the server. Unless I misunderstand what you're getting at here? > LCUP operations are subject to administrative and access > control policies enforced by the server. > > TJH: Might be good to note that something like a change > to a server's access control settings may cause a client to be > UNABLE to synchronize (for all of the information that it might > be holding already). Right. The server may then, at any time, return to the client that a reload is required. > A part of the DIT > > TJH: clarify "part". > which is enabled for LCUP is referred to as an > LCUP Context. A server may support one or more LCUP Contexts. Done. For example, a naming context can be an LCUP context. > synchronizeOnly - the server sends all the data needed to > synchronize the client with the server, then closes the > connection > > TJH: When this is specified, is it possible that the same entry may > be sent to the client MULTIPLE times, if, for example, the entry > was modified by some other client while the LCUP session was still > processing/returning data? If so, this should be noted. Right. This is noted in detail in the new draft. > > entryDeleted - if set to TRUE, indicates that the entry to which > the control is attached was deleted. The server MAY also set > this to TRUE if the entry has left the client's search result > set. As far as the client is concerned, a deleted entry is no > different than an entry that has left the result set. > > TJH: How long must a server "remember" that a client "knew" > about an entry in order to know when to send/set this flag on > an entry returned to the client over the LCUP session? It is entirely up to the server implementation. The server implementer and administrator will need to keep in mind the presence of replication and LCUP clients in order to set the tombstone reap policy, for example. > S->C Stops sending changes to the client and closes the connection. > > TJH: Why does it close the connection? What if other concurrent > operations > are being performed over the connection? You're right. It doesn't need to close the connection - it just needs to finish the LCUP request. > . The client SHOULD maintain a cache of the LDAP URLs returned > in the continuation references and the cookies associated with > them. The client is responsible for performing another LCUP search to > follow the references, and SHOULD use the cookie corresponding to > the LDAP URL for that reference (if it has a cookie). > > TJH: I don't think I understand this one. Does this imply that one > server > can add cookies that would be interpretable by some other server that is > pointed to by the searchResultReference? No, it means a server can send references to itself, in order to maintain different cookies for different LCUP contexts. > The server SHOULD send a > SearchResultReference [RFC2251, SECTION 4.5.3] when the LCUP Context > for a returned entry changes. The server SHOULD return all entries > for a particular LCUP Context before returning a reference to other > LCUP Contexts or non-LCUP enabled parts of the DIT, in order to > minimize the processing burden on the clients. > > TJH: I disagree with this SHOULD. By sending references "early", > a multi-threaded client has the "opportunity" to do things in parallel. > But by sending the references "late", the client has no choice but to > serialize the operations - prohibiting parallel operation. That's a good idea. I'll change the wording so that the server MAY return all searchResultReferences first. --------------060503000400070307000309 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
Issue Number: 1

Description: Complete LCUP Client Update is Problematic

Summary:

Concern was expressed over an LCUP Client that repeats an original
request may find that the copy "synchronized" by LCUP has changed
significantly.

Concensus:

The protocol basically needs not only to send a copy of
all entries which are within scope which have significantly
changed, but also send a list of UUIDs and CSNs of all the
entries which have not changed.  This would not only allows
the client to determine the set of entries which have been
deleted from the fragment, but also determine if an entry
returned but not updated needs to be refreshed.  In which
case, it can request a copy of those entries which it
believes need to be refreshed.  This can be done out of
band with a persist operation.

Relevant Posting(s):

http://www.imc.org/ietf-ldup/mail-archive/msg01511.html
Response:

The other authors and I don't think this is necessary.  The main reason this is needed is that it is difficult for servers to keep track of which entries have left the result set due to meta data changes such as access control, configuration, etc.  So, a server could simply send unchanged entries instead of sending entry left set notifications.  We don't think this needs to be addressed in LCUP for the following reasons:
1) It is expected that changes which would cause the server to have a hard time calculating which entries have left the result set will be very infrequent.
2) The 04 version of the LCUP draft provides a mechanism to have the server tell the client that a reload is required at any time.  We feel that, in most cases, returning all present entries will be nearly as expensive as a full reload.
3) There will be cases where the server may have a hard time figuring out which entries are even present, much less have left the result set, so a reload will be required in those cases as well.
Issue Number: 2

Description: Persist Doesn't Support Eventual Convergence

Summary:

This issue was raised in the context of Issue #1. It basically
states that the server should support eventual convergence of
the client's information with equivalent information on the server.

Concensus:

The server needs to be required to generate the set of
events necessary for eventual convergence of the client's
copy of the DIT fragment.

The spec currently only appears to support "lossy convergence."

Relevant Postings:

http://www.imc.org/ietf-ldup/mail-archive/msg01511.html
http://www.imc.org/ietf-ldup/mail-archive/msg01594.html
http://www.imc.org/ietf-ldup/mail-archive/msg01595.html
http://www.imc.org/ietf-ldup/mail-archive/msg01596.html
http://www.imc.org/ietf-ldup/mail-archive/msg01597.html
Response:
I think the majority of this was answered in the response to #1 above.  If I missed something, please let me know.
Issue Number: 3

Description: Confusing Cookie/Scheme Text

Summary:

The document defines a cookie as representing client state,
but it then says it may be sent initially (without value)
to indicating the desired scheme.

Concensus:

The specification would be a lot clearer if the cookie/scheme
were defined as:

  LCUPScheme ::= LDAPOID
  LCUPCookie ::= SEQUENCE {
	scheme          LCUPScheme,
	value           OCTET STRING
  }

and request control was defined as:

  ClientUpdateControlValue ::= SEQUENCE {
      updateType         ENUMERATED {
                               synchronizeOnly         (0),
                               synchronizeAndPersist   (1),
                               persistOnly             (2) },
      sendCookieInterval INTEGER    OPTIONAL,
      scheme		  LCUPScheme OPTIONAL,
      cookie             LCUPCookie OPTIONAL
  }

where scheme may only be specified on initial request to indicate
desired scheme and cookie must be provided on subsequent
requests.

Relevant Posting(s):

http://www.imc.org/ietf-ldup/mail-archive/msg01606.html
Response:
Changed, and the scheme is no longer a part of the cookie.  Thanks for the suggestion.
Issue Number: 4

Description: Clarification of Cookie Specification

Summary:

Section 4.2 states: "The cookie value MUST be included except when a
client has no stored state; i.e., when the client is requesting a full
synchronization"

Concensus:

Clarification is needed as to which of the following this text refers
to (or an indication that it refers to all of the following):

   + ClientUpdateControlValue

   + EntryUpdateControlValue

   + ClientUpdateDoneControlValue

Relevant Posting(s):

http://www.imc.org/ietf-ldup/mail-archive/msg01506.html
Response:
The LCUP 04 draft is much clearer about when and how a cookie should be returned.
Issue Number: 5

Description: New Cookie w/No Entry Mechanism

Summary:

LCUP needs to provide a mechanism which allows the server to send,
at any time, a new cookie to the client without requiring the server
to send an entry.

Concensus:

This is useful in cases where the cookie the server previously
sent is too old to be useful and a new cookie would allow more
efficient resync if the session where to be unexpectedly dropped.
In fact, the cookie may be so old to cause a full sync to occur
when no changes would be necessary if the cookie were updated.

Relevant Posting(s):

http://www.imc.org/ietf-ldup/mail-archive/msg01518.html
http://www.imc.org/ietf-ldup/mail-archive/msg01520.html
http://www.imc.org/ietf-ldup/mail-archive/msg01521.html
http://www.imc.org/ietf-ldup/mail-archive/msg01522.html
http://www.imc.org/ietf-ldup/mail-archive/msg01524.html
http://www.imc.org/ietf-ldup/mail-archive/msg01526.html
http://www.imc.org/ietf-ldup/mail-archive/msg01532.html
http://www.imc.org/ietf-ldup/mail-archive/msg01534.html
Response:
The LCUP 04 allows for a "Sync Update Informational Response" which can be used to return the cookie (or other information) at any time, without using an intermediate response.
Issue Number: 6

Description: UUID Syntax and Matching Rule

Summary:

The syntax of UUID is directory string, and moreover, the matching rule
is case ignore match. It was suggested that this combination is overly
limiting and that the syntax be changed to octet string. This is made
even more apparent by the fact that this document leaves standardization
of the value generation to a future specification.


Concensus:

First and foremost, UUID support needs to be mandatory. The
protocol won't work otherwise.

Instead of returning the UUID as an attribute value (which
are subject to normal access controls), it should be returned
within the control (which *should* be subject to some kind of
access restrictions).  This to avoid having to deal with no
UUID as being a valid response to a CRITICAL update request.
Instead, if the server is unwilling to provide the UUID, the
CRITICAL request will fail.

A specification of how the server represents UUIDs (and CSNs)
in the directory should be standardized, but suggest this be
done in a separate document... as, if UUIDs are passed in the
control, LCUP doesn't depend on the particulars representation
in the DIT.

For the specifications of entryUUID (and entryCSN), using
either octetString/octetStringMatch or UUID/UUIDMatch
(where UUID was a constrained OCTET STRING with a string
syntax). The later is preferable.

There is no need to leave the string syntax up to future
standardization.  ISO/IEC 11578:1996 can be referenced.

Relevant Posting(s):

http://www.imc.org/ietf-ldup/mail-archive/msg01505.html
http://www.imc.org/ietf-ldup/mail-archive/msg01508.html
http://www.imc.org/ietf-ldup/mail-archive/msg01544.html
http://www.imc.org/ietf-ldup/mail-archive/msg01510.html
http://www.imc.org/ietf-ldup/mail-archive/msg01546.html
http://www.imc.org/ietf-ldup/mail-archive/msg01552.html
http://www.imc.org/ietf-ldup/mail-archive/msg01553.html
http://www.imc.org/ietf-ldup/mail-archive/msg01555.html
http://www.imc.org/ietf-ldup/mail-archive/msg01557.html
http://www.imc.org/ietf-ldup/mail-archive/msg01558.html
http://www.imc.org/ietf-ldup/mail-archive/msg01563.html
http://www.imc.org/ietf-ldup/mail-archive/msg01567.html
http://www.imc.org/ietf-ldup/mail-archive/msg01568.html
Response:
Done, and thanks for the suggestion.  The new LCUP draft specifies a mechanism by which the server's UUIDAttribute (name or OID) can be returned to the client so that the client can do searches.  This element is optional - only for servers that have a UUID attribute and support searches.
Issue Number: 7

Description: Trigger Mechanism or Not?

Summary:

The draft states that it "is intended to allow LDAP clients to
synchronize with the content stored by LDAP servers". but also states
that it wants to solve the problem of triggered actions (Section 3,
Bullet 3).

Concensus:

Most of the rest of the draft is consistent with the notion of
synchronization, but tends to downplay support for triggered responses.
Do we want this to be a useful event driver, or is the idea that we just
preserve the easy stuff of what prior drafts could do?

Specifically, the left-out items in Sections 5.1, 5.2, and 5.3 deter
from the effectiveness of the "persist" mode.

Curent users of Persistent Search rely on the notion of change types.
Section 5.2 assumes that change types are used for partial replication,
and thus discounts them as useful for LCUP.

Triggered actions should be within LCUP's scope. The LCUP authors have
tried to balance the server implementation burden with the client
implementation burden. In particular, I would really like to 
avoid creating an LCUP protocol that requires a server to store 
client-specific state (that just won't scale when their are thousands
or hundreds of thousands of clients).

A related comment: section 5 should be moved to an appendix that 
is named "Features Left Out of LCUP." It is not core to LCUP, but is 
useful to provide historical context and rationale for why some things 
are not included in LCUP.

Relevant Posting(s):

http://www.imc.org/ietf-ldup/mail-archive/msg01519.html
http://www.imc.org/ietf-ldup/mail-archive/msg01554.html
http://www.imc.org/ietf-ldup/mail-archive/msg01556.html
http://www.imc.org/ietf-ldup/mail-archive/msg01562.html
Response:
We made it clear in the new 04 LCUP draft that it is not the intention of LCUP to fully replace all existing persistent and triggered search applications.  We also moved those sections mentioned to a "Features Left Out of LCUP" appendix as suggested.
Issue Number: 8

Description: Alias Dereferencing

Summary:

The server instructions for alias deferencing are found in the Client
Side Considerations section.

Concensus:

Specifically, it says that a server will respond with protocolError if
any other than neverDerefAliases or derefFindingBaseObj is specified.
This should be moved to, copied to, or referenced in a more server-centric
part of the draft. It should say "... the server MUST return protocolError..."

Relevant Posting(s):

http://www.imc.org/ietf-ldup/mail-archive/msg01516.html
Response:
Done.  Thanks for the suggestion.
Issue Number: 9

Description: Laundry List

Summary:

This posting contains a copy of feedback provided to the document
editors privately.

Concensus:

Some of the specific comments in the postings below have been discussed and
addressed as a part of other issues. Other comments are strictly editorial
in nature and should be incorporated. The document editors should raise
comments otherwise classified to the mailing list and obtain clarification
from the WG members.

Relevant Posting(s):

http://www.imc.org/ietf-ldup/mail-archive/msg01514.html
http://www.imc.org/ietf-ldup/mail-archive/msg01515.html
http://www.imc.org/ietf-ldup/mail-archive/msg01517.html
Response:
There are a lot of issues here, most (if not all) of which have been addressed in the LCUP 04 draft.  I would suggest that Kurt (and others) take a look at the new draft to see if the issues have been addressed appropriately and sufficiently.
Issue Number: 10

Description: Search Filter and Returned Entries

Summary:

The draft states in Section 5.2 that "For LCUP, the intention is full
synchronization, not partial.".

Concensus:

LCUP must support both partial (not necessarily all entries within
scope) and fractional (not necessarily all attributes of each entry)
synchronization.

Relevant Posting(s):

http://www.imc.org/ietf-ldup/mail-archive/msg01523.html
http://www.imc.org/ietf-ldup/mail-archive/msg01530.html
http://www.imc.org/ietf-ldup/mail-archive/msg01539.html
Response:
That section mentioned above has been moved to the appendix and is no longer relevant to the LCUP protocol.
LCUP does support partial and fractional synchronization.
Issue Number: 11

Description: Does entryDeleted break the protocol?

Summary:

The description for entryDeleted states at first that it indicates that
the entry being returned has been deleted--then goes on to say that it
also might indicate that the entry has left the result set. In the case
of it being due to the entry has left the result set, we need to answer
these:
1) If due to a rename, what DN is used (old or new)
2) If the entry is not in the result set, doesn't it break the LDAP
protocol to return it (it doesn't match the filter)?

Concensus:

No change required. Clarification was provided on the mailing list.

Relevant Posting(s):

http://www.imc.org/ietf-ldup/mail-archive/msg01525.html
http://www.imc.org/ietf-ldup/mail-archive/msg01545.html
Response:
LCUP 04 makes it clear what it means for an entry to have left the result set.  And yes, this does "break" the LDAP protocol (specifically as regards to search responses), but it is a necessary break to provide a lightweight sync mechanism.
Issue Number: 12

Description: Is the EntryUpdateControlValue optional?

Summary:

First, is the EntryUpdateControlValue supposed to be returned during an
initial synchronization session?

Next, Section 4.8 states: "Each SearchResultEntry may have an
entryUpdate control attached. ". This indicates that the control is
optional. Is it?

Concensus:

No further discussion took place on the list on this topic.

Relevant Posting(s):

http://www.imc.org/ietf-ldup/mail-archive/msg01527.html
Response:
LCUP 04 makes this much more clear.
Issue Number: 13

Description: What is "a while"?

Summary:

Section 4.8 states "it MUST wait for a while before attempting another
synchronization session with the server. "


Concensus:

If we're going to use an imperative like MUST, we ought to not use
vague language like "a while". I suggest we drop the MUST anyway--is
there an interoperability issue here?

The "MUST wait for a while" would be consistent with most other network
algorithms. If it doesn't wait, it may cause unintentional denial of
service attacks by swamping the server with connection requests. 

Since LCUP is proposing persistent open TCP connections and
the use of an error code for resources exhaustion, "acceptable" client
behavior ought to be specified to help determine a "malicious" client.

Since list comments imply that different use cases of LCUP require
different back off periods, I'd think that having the server specify
the initial backoff period in seconds with the lcupResorcesExhausted error
would be worth consideration.

Relevant Posting(s):

http://www.imc.org/ietf-ldup/mail-archive/msg01528.html
http://www.imc.org/ietf-ldup/mail-archive/msg01547.html
http://www.imc.org/ietf-ldup/mail-archive/msg01559.html
http://www.imc.org/ietf-ldup/mail-archive/msg01569.html
http://www.imc.org/ietf-ldup/mail-archive/msg01571.html
Response:
The LCUP 04 draft says that a "client SHOULD wait 5 seconds before attempting a retry".  It also goes on to say that clients SHOULD use an exponential backoff strategy, but this is not required, as different clients may want to use different backoff strategies.
Issue Number: 14

Description: note about syncing to different servers

Summary:

What does the "(Note that the client can synchronize with different
servers during different synchronization sessions.) " mean in the
context of the paragraph it's in?

Concensus:

No further discussion took place on the list on this topic.

Relevant Posting(s):

http://www.imc.org/ietf-ldup/mail-archive/msg01529.html
Response:
This has been removed.
Issue Number: 15

Description: Need for lcupReloadRequired

Summary:

Why is this error needed? It seems that if this scenario exists, the
server would simply send the full set of entries, and a new cookie. The
current specification indicates that the client would try to sync,
receive an error, then try to sync again with an empty cookie. Is there
a benefit to the extra step?

Concensus:

Yes, it tells the client to delete everything it has.  Otherwise
it might be left with entries which should be have been deleted
but were not.

Of course, given that LCUP doesn't ensure this doesn't happen
under success resync is of concern.

Relevant Posting(s):

http://www.imc.org/ietf-ldup/mail-archive/msg01531.html
http://www.imc.org/ietf-ldup/mail-archive/msg01535.html
http://www.imc.org/ietf-ldup/mail-archive/msg01533.html
Response:
LCUP 04 provides a mechanism for servers to tell clients, at any time, that a reload is required.  I believe the extra step is nice if the client is not currently prepared to do a resync.  Why?  Is it really that much trouble for the client to issue another LCUP search request for a full resync?
Issue Number: 16

Description: sync, then sync and persist

Summary:

Why is there a suggestion in Section 6 to "perform an initial
synchronization...(synchronizeOnly)" and then immediately perform a
synchronizeAndPersist session? Why not just perform a
synchronizeAndPersist session to begin with?

Concensus:

What's needed is a intermediate response PDU indicating
the end of the synchronize phase and provide a new cookie.
This not only works when there are no sync events, but also
works when there are persist event occurring during
synchronization.  Calling it an "end of sync phase" marker
doesn't prevent an overlapping "persist" phase.

There should be no problem with allowing an overlapping
"persist" phase (as the current I-D does) AS LONG AS it
is clear to the client when it has a complete copy of the
DIT fragment.

Then, we can work on providing the client with a complete
and accurate copy...

Relevant Posting(s):

http://www.imc.org/ietf-ldup/mail-archive/msg01536.html
http://www.imc.org/ietf-ldup/mail-archive/msg01541.html
http://www.imc.org/ietf-ldup/mail-archive/msg01550.html
http://www.imc.org/ietf-ldup/mail-archive/msg01551.html
Response:
No intermediate response PDU is required.  The LCUP 04 draft provides a "Sync Update Informational Response" to handle this case.  Also, the new draft clearly states that overlap of sync and persist phase is not permitted.
Issue Number: 17

Description: rename of baseObject (was something else)

Summary:

At 10:20 PM 2002-09-03, Jim Sermersheim wrote:
  
The scenario I was thinking of is one where the base existed when a
persistent LCUP session starts, but later is renamed or deleted.
    

Concensus:

Client Considerations implies noSuchObject is
returned in this case.  This needs to be detailed
in Section 4 (along with many other protocol
details found in sections 6 and 7).

Relevant Posting(s):

http://www.imc.org/ietf-ldup/mail-archive/msg01538.html
http://www.imc.org/ietf-ldup/mail-archive/msg01543.html
http://www.imc.org/ietf-ldup/mail-archive/msg01548.html
http://www.imc.org/ietf-ldup/mail-archive/msg01549.html
Response:
This is addressed in section "4.2 Renaming the Base Object" in the LCUP 04 draft.
Issue Number: 18

Description: subordinate references

Summary:

The document is quite unclear how references are to be
handled.  What happens when a named subordinate referral
object [RFC 3296] within scope of the search is added,
deleted, or modified?

Concensus:

One approach would be to return a searchResultReference
with a control much like the EntryUpdateControl, but with
the UUID of the referral object.

Or one could just redefine (and rename) the
EntryUpdateControl to include the UUID.

Another approach would be require the presence of
the ManageDsaIT control in the request.  This, basically,
requests that all referral objects be treated as
entry objects.  However, the problem with this, is that
the ManageDsaIT control may be used to manage other kinds
of knowledge information.  It selects a management plane
within the DsaIT.  An LCUP with ManageDsaIT should be
treated as a LCUP request within the management plane
normally selected by the ManageDsaIt.

Another option is to just to say the all referral objects
are treated as entry objects when the LCUP control is
present.

There may be other options.

A preference was expressed for something like the first approach
(for add, and mod). And a comment was made that a "delete would
just be a delete."

Relevant Posting(s):

http://www.imc.org/ietf-ldup/mail-archive/msg01560.html
http://www.imc.org/ietf-ldup/mail-archive/msg01564.html
Response:
We decided to go with something like the first approach, which Kurt elaborated on in his sync I-D.
Issue Number: 19

Description: collective attributes, subentries, etc.

Summary:

Some statement should be made with how LCUP interacts
with collective attributes appearing both in the
filter and returned entries.  The simple approach
would be to say: 1) filter should not contain
assertions upon collective attributes, 2) changes to
an collective subentry will not cause entries within
the collection to be "updated", 3) clients are interested
in maintaining sync with collective attributes should
include the collective subentry within an LCUP request.

Which leads to another question:
	how does a client ask for update of both entry
	and subentry DSEs subordinate to the baseObject object?

This is similar to the subordinate referral issue.  One
could generalize the question to:

	How does a client ask for update of all DSEs of
	a particular combination of DSE types subordinate
	to the baseObject?


Concensus:

No other discussion took place on the list on this topic.

Relevant Posting(s):

http://www.imc.org/ietf-ldup/mail-archive/msg01561.html
Response:
If subentries are within the scope of the request, and the subentry control is present, the subentries are treated and returned just like normal entries.
Virtual (collective, et. al.) attributes are handled just like regular attributes.  This means that if you change a virtual attribute definition, you may cause many entries within the search scope to be returned as modified.  Alternately, the server may decide that would be too expensive of an operation and simply force the client to resync.

It would be nice if there were a search control which would allow the client to specify that no virtual attributes are to be returned.
Issue Number: 20

Description: operational attributes

Summary:

We need to state how updates to operational attributes (both stored
and not stored) affect LCUP.

Concensus:

There are different classes of this:

1) A server internally increments a numSubordinates attribute on the
parent of an entry being added or deleted (server responding to client
action)
2) A server modifies replication-related information (server responding
to bilateral processes)
3) A server updates the state of a transitional attribute (response to
an internal, timed operation)
4) An entire set of operations like those above that affect the value
of an operational attribute, but the value is generated dynamically,
only when read by a client.
5) A client updates an operational attribute.

We should also discuss any differences in behavior among the three
different types of operational attribute (directoryOperation,
distributedOperation, dSAOperation).

Relevant Posting(s):

http://www.imc.org/ietf-ldup/mail-archive/msg01565.html
http://www.imc.org/ietf-ldup/mail-archive/msg01572.html
http://www.imc.org/ietf-ldup/mail-archive/msg01573.html
http://www.imc.org/ietf-ldup/mail-archive/msg01574.html
Response:
If a client requests an operational attribute, then the client should get it - no special handling.
Issue Number: 21

Description: Changes to attributes not in attributes list

Summary:

When we implemented psearch, there was contention over whether
or not the client should be updated when a modification is made
to an attribute that was not requested by the client.

Concensus:

No other discussion occured on the list on this topic, however,
in this case, silence seems to indicate the following intent.

The case for NOT sending these entries is pretty strong. I'm not
sure what arguments can be made for sending them. In either case,
this needs to be spelled out in the draft.

Relevant Posting(s):

http://www.imc.org/ietf-ldup/mail-archive/msg01566.html
Response:
The client will only be notified of changes to requested attributes.  If a non requested attribute changes, the client will not be notified.
For deleted entries, especially in servers that use tombstones that do not contain the full attributes and values of the entry, the server MAY send deleted entry notifications for entries that are not and have never been in the client's result set - the client MUST ignore these.
Issue Number: 22

Description: Interaction with other controls?

Summary:

How does this control interact with other controls?
How does this control interact with existing search controls?
Paging? Sorting? Matched Values? Duplicate Entries? VLV? etc.

Concensus:

There was no further discussion about this topic on the list.

Relevant Posting(s):

http://www.imc.org/ietf-ldup/mail-archive/msg01570.html
Response:
"LCUP defines neither restrictions nor guarantees about the ability to use the controls defined in this document in conjunction with other LDAP controls, except for the following:  A server MAY ignore non-critical controls supplied with the LCUP control.  A server MAY ignore an LCUP defined control if it is non-critical and it is supplied with other critical controls.  If a server receives a critical LCUP control with another critical control, and the server does not support both controls at the same time, the server SHOULD return unavailableCriticalExtension.

It is up to the server implementation to determine if the server supports controls such as the Sort or VLV or similar controls that change the order of the entries sent to the client.  But note that it may be difficult or impossible for a server to perform an incremental synchronization in the presence of such controls, since the cookie will typically be based off a change number, or CSN, or timestamp, or some criteria other than an alphabetical order."
Issue Number: 23

Description: cookie schemes, why?

Summary:

The document doesn't adequately describe why cookie schemes
are necessary...  in particular, why would a client ever
want to request a particular scheme?  How would a client
determine which schemes where supported by the server?  And,
if the server is allowed to support differ schemes in different
subtrees, how would a client determine which schemes where
supported in which subtrees. 

The need to allow the client to request particular cookie
schemes is being questioned after prior concensus was
established on this topic. It was suggested that there
if there is a need for this, then we need to make sure
adequate discovery mechanisms are provided so that client
can which schemes are supported where (yuk). Which is
a topic that has been discussed during the WG meeting
prior to the issuance of this WG Last Call.

It was also suggested that if there is no reason, that no
means be provided to allow a client to request a particular
scheme.  If later some need arises, LCUP can be extended.
That extension would have to deal with scheme discovery
issues.

Concensus:

>From past discussions, the main purpose of the scheme was
to facilitate protocol operations in replicated environments.
That is, where the client resumes an LCUP session on a
different server then that which provided the cookie, the
scheme allows the server to determine the cookie format
used by the other server.  If the doesn't recognize the
scheme, it can return an error (or a referral to the
servers which do understand the scheme?).

Concensus in the WG Meeting Prior to the issuance of
this WG Last Call was that a cookie discovery mechanism
was not needed. This was posted to the mailing list in the
form of meeting minutes from that WG Meeting.

Relevant Posting(s):

http://www.imc.org/ietf-ldup/mail-archive/msg01607.html
Response:
The cookie discovery mechanism has been removed.
Issue Number: 24

Description: various LCUP issues

Summary:

A posting was made shortly prior to the end of the WG Last call
period containing several comments/issues.

Concensus:

No further discussion took place on the list in response to this posting.

Relevant Posting(s):

http://www.imc.org/ietf-ldup/mail-archive/msg01608.html
Response:
(Below, I assumed RUV (as in section 7) as the cookie.)
In the case that RUV is returned to the client periodically
during a synchronize session, it may not have much
meaning unless the returned entries are sorted
(as in size limit case in section 7).
I would consider that to be a server implementation detail - if the server returns a cookie, it should be able to accept it and use it whenever it is presented with an LCUP search request.  I think it is outside the scope of the LCUP draft to impose this sort of implementation detail.
Otherwise, upon error during a synchronization session,
the next synchronization should restart from
the RUV before the failed synchronization not from the last
received RUV before error.
If this is the case, periodic delivery of cookies during
a synchronize section may be meaningless.
It's up to the server implementation - if the server returns a cookie, it should be able to use it.

> It seems that the above paragraph also holds when a time limit is imposed.
> A possible issue with the time limit is that the time to sort the result set
> may be larger than the time limit itself.
> The sorting may also be required when we decided to cope with errors during
> a synchronization session in such a way that avoids restart from the pre-session state.

Again, that is a server implementation detail that won't be specified by LCUP.  The server should ensure that it returns a cookie to the client if a size or time limit is exceeded. 
Issue Number: 25

Description: LCUP Draft inline comments

Summary:

Many comments, some of which were editorial, are included in the posting
associated with this issue.

Concensus:

Some of these issues were discussed separately and would be duplicates of
those above if documented seperately here. Some of them are editorial and
should be incorporated. Comments classified otherwise should be posted to
the mailing list by the document editors for further discussion.

Relevant Posting(s):

http://www.imc.org/ietf-ldup/mail-archive/msg01598.html
Response:

   Several features of the protocol distinguish it from LDUP
   replication. LCUP is designed such that the server does not need to
   maintain state information on behalf of the client.

TJH: I don't understand how servers won't have to maintain some level
of information related to the client if deleted entries are going
to have to be "remembered"
Tombstones?  No client state information needs to be saved.
and potentially "cookie" values will
have to be "remembered" as well.
If the cookie value is an RUV, then server will have to store this, but it doesn't have to store them on a client by client basis.  Each client will just refer to the RUV used by the server.  Unless I misunderstand what you're getting at here?
   LCUP operations are subject to administrative and access            control policies enforced by the server.

TJH: Might be good to note that something like a change
to a server's access control settings may cause a client to be
UNABLE to synchronize (for all of the information that it might
be holding already).
Right. The server may then, at any time, return to the client that a reload is required.
   A part of the DIT

TJH: clarify "part".
 which is enabled for LCUP is referred to as an
   LCUP Context.  A server may support one or more LCUP Contexts.
Done.  For example, a naming context can be an LCUP context.


>      synchronizeOnly - the server sends all the data needed to
>        synchronize the client with the server, then closes the
>        connection
>
> TJH: When this is specified, is it possible that the same entry may
> be sent to the client MULTIPLE times, if, for example, the entry
> was modified by some other client while the LCUP session was still
> processing/returning data?  If so, this should be noted.

Right.  This is noted in detail in the new draft.



    entryDeleted - if set to TRUE, indicates that the entry to which
      the control is attached was deleted.  The server MAY also set
      this to TRUE if the entry has left the client's search result
      set.  As far as the client is concerned, a deleted entry is no
      different than an entry that has left the result set.

TJH: How long must a server "remember" that a client "knew"
about an entry in order to know when to send/set this flag on
an entry returned to the client over the LCUP session?

It is entirely up to the server implementation.  The server implementer and administrator will need to keep in mind the presence of replication and LCUP clients in order to set the tombstone reap policy, for example.
    S->C   Stops sending changes to the client and closes the connection.

TJH: Why does it close the connection?  What if other concurrent operations
are being performed over the connection?
You're right.  It doesn't need to close the connection - it just needs to finish the LCUP request.


.  The client SHOULD maintain a cache of the LDAP URLs returned
   in the continuation references and the cookies associated with them.     The client is responsible for performing another LCUP search to
   follow the references, and SHOULD use the cookie corresponding to
   the LDAP URL for that reference (if it has a cookie).

TJH: I don't think I understand this one.  Does this imply that one server
can add cookies that would be interpretable by some other server that is
pointed to by the searchResultReference?
No, it means a server can send references to itself, in order to maintain different cookies for different LCUP contexts.
The server SHOULD send a
   SearchResultReference [RFC2251, SECTION 4.5.3] when the LCUP Context
   for a returned entry changes.  The server SHOULD return all entries
   for a particular LCUP Context before returning a reference to other
   LCUP Contexts or non-LCUP enabled parts of the DIT, in order to
   minimize the processing burden on the clients.

TJH: I disagree with this SHOULD.  By sending references "early",
a multi-threaded client has the "opportunity" to do things in parallel.
But by sending the references "late", the client has no choice but to
serialize the operations - prohibiting parallel operation.
That's a good idea.  I'll change the wording so that the server MAY return all searchResultReferences first.

--------------060503000400070307000309-- From owner-ietf-ldup@mail.imc.org Fri Mar 7 15:37:39 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29767 for ; Fri, 7 Mar 2003 15:37:38 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h27KaIe17779 for ietf-ldup-bks; Fri, 7 Mar 2003 12:36:18 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h27KaG317775 for ; Fri, 7 Mar 2003 12:36:17 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28982; Fri, 7 Mar 2003 15:34:12 -0500 (EST) Message-Id: <200303072034.PAA28982@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-zeilenga-ldup-sync-01.txt Date: Fri, 07 Mar 2003 15:34:12 -0500 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : LDAP Content Synchronization Operation Author(s) : K. Zeilenga, J. Choi Filename : draft-zeilenga-ldup-sync-01.txt Pages : 18 Date : 2003-3-7 This specification describes the LDAP (Lightweight Directory Access Protocol) Content Synchronization operation offering eventual-convergent data consistency. The operation allows a client to maintain a shadow copy of a fragment of directory information tree. The operation supports both polling for changes and listening for changes. The LDAP Content Synchronization operation is defined as an extension of the LDAP Search operation. This specification defines the Sync Request, Sync State, and Sync Done controls, the Sync Intermediate Response message, and a number of other protocol elements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldup-sync-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-zeilenga-ldup-sync-01.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-zeilenga-ldup-sync-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-7143847.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldup-sync-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldup-sync-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-7143847.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Sun Mar 9 11:18:15 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13777 for ; Sun, 9 Mar 2003 11:18:14 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h29GFDE18229 for ietf-ldup-bks; Sun, 9 Mar 2003 08:15:13 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h29GFB318222 for ; Sun, 9 Mar 2003 08:15:12 -0800 (PST) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h29GFCCa036923 for ; Sun, 9 Mar 2003 16:15:12 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030309080317.02a3a428@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sun, 09 Mar 2003 08:13:25 -0800 To: ietf-ldup@imc.org From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-ldup-lcup-04.txt In-Reply-To: <200303071153.GAA21349@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Is it the authors intent to allow state-based server implementation of this protocol? It appears to me that server implementations would need to maintain historical information in order to appropriately support this protocol. Kurt At 03:53 AM 3/7/2003, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF. > > Title : LDAP Client Update Protocol > Author(s) : R. Megginson, M. Smith, O. Natkovich, J. Parham > Filename : draft-ietf-ldup-lcup-04.txt > Pages : 27 > Date : 2003-3-6 > >This document defines the Lightweight Directory Access Protocol >(LDAP) Client Update Protocol (LCUP). The protocol is intended to >allow an LDAP client to synchronize with the content of a directory >information tree (DIT) stored by an LDAP server and to be notified >about the changes to that content. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-04.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-ldup-lcup-04.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-ldup-lcup-04.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. >Content-Type: text/plain >Content-ID: <2003-3-6125307.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-ldup-lcup-04.txt > > From owner-ietf-ldup@mail.imc.org Mon Mar 10 10:15:58 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28681 for ; Mon, 10 Mar 2003 10:15:57 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2AFAmI08379 for ietf-ldup-bks; Mon, 10 Mar 2003 07:10:48 -0800 (PST) Received: from netscape.com (c3po.aoltw.net [64.236.137.25]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2AFAk308375 for ; Mon, 10 Mar 2003 07:10:46 -0800 (PST) Received: from dredd.mcom.com (dredd.nscp.aoltw.net [10.169.8.48]) by netscape.com (8.10.0/8.10.0) with ESMTP id h2AFAel27583 for ; Mon, 10 Mar 2003 07:10:40 -0800 (PST) Received: from netscape.com ([10.169.192.27]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HBJGT300.9N7; Mon, 10 Mar 2003 07:10:15 -0800 Message-ID: <3E6CAA96.40405@netscape.com> Date: Mon, 10 Mar 2003 08:09:10 -0700 From: richm@netscape.com (Rich Megginson) Organization: Netscape - Directory Server User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-ldup@imc.org Subject: Re: I-D ACTION:draft-ietf-ldup-lcup-04.txt References: <5.2.0.9.0.20030309080317.02a3a428@127.0.0.1> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030000080700070200090204" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030000080700070200090204 Content-Type: multipart/alternative; boundary="------------030103030209060801010901" --------------030103030209060801010901 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: >Is it the authors intent to allow state-based server >implementation of this protocol? > Yes. >It appears to me that >server implementations would need to maintain historical >information in order to appropriately support this >protocol. > Could you elaborate? > >Kurt > >At 03:53 AM 3/7/2003, Internet-Drafts@ietf.org wrote: > > >>A New Internet-Draft is available from the on-line Internet-Drafts directories. >>This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF. >> >> Title : LDAP Client Update Protocol >> Author(s) : R. Megginson, M. Smith, O. Natkovich, J. Parham >> Filename : draft-ietf-ldup-lcup-04.txt >> Pages : 27 >> Date : 2003-3-6 >> >>This document defines the Lightweight Directory Access Protocol >>(LDAP) Client Update Protocol (LCUP). The protocol is intended to >>allow an LDAP client to synchronize with the content of a directory >>information tree (DIT) stored by an LDAP server and to be notified >>about the changes to that content. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-04.txt >> >>To remove yourself from the IETF Announcement list, send a message to >>ietf-announce-request with the word unsubscribe in the body of the message. >> >>Internet-Drafts are also available by anonymous FTP. Login with the username >>"anonymous" and a password of your e-mail address. After logging in, >>type "cd internet-drafts" and then >> "get draft-ietf-ldup-lcup-04.txt". >> >>A list of Internet-Drafts directories can be found in >>http://www.ietf.org/shadow.html >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >>Internet-Drafts can also be obtained by e-mail. >> >>Send a message to: >> mailserv@ietf.org. >>In the body type: >> "FILE /internet-drafts/draft-ietf-ldup-lcup-04.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. >>Content-Type: text/plain >>Content-ID: <2003-3-6125307.I-D@ietf.org> >> >>ENCODING mime >>FILE /internet-drafts/draft-ietf-ldup-lcup-04.txt >> >> >> >> > > > --------------030103030209060801010901 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote:
Is it the authors intent to allow state-based server 
implementation of this protocol?
Yes.
It appears to me that
server implementations would need to maintain historical
information in order to appropriately support this
protocol.
Could you elaborate?

Kurt

At 03:53 AM 3/7/2003, Internet-Drafts@ietf.org wrote:
  
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF.

       Title           : LDAP Client Update Protocol
       Author(s)       : R. Megginson, M. Smith, O. Natkovich, J. Parham
       Filename        : draft-ietf-ldup-lcup-04.txt
       Pages           : 27
       Date            : 2003-3-6
       
This document defines the Lightweight Directory Access Protocol 
(LDAP) Client Update Protocol (LCUP). The protocol is intended to 
allow an LDAP client to synchronize with the content of a directory 
information tree (DIT) stored by an LDAP server and to be notified 
about the changes to that content.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
       "get draft-ietf-ldup-lcup-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
       mailserv@ietf.org.
In the body type:
       "FILE /internet-drafts/draft-ietf-ldup-lcup-04.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.
Content-Type: text/plain
Content-ID:     <2003-3-6125307.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ldup-lcup-04.txt

<ftp://ftp.ietf.org/internet-drafts/draft-ietf-ldup-lcup-04.txt>

--------------030103030209060801010901-- --------------ms030000080700070200090204 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK6TCC A4MwggLsoAMCAQICAmXjMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5l IEluYzEZMBcGA1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2Vy dGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAyMTEyNjE4MTQwOFoXDTAzMDUyNTE4MTQwOFowfTEL MAkGA1UEBhMCVVMxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEVMBMGCgmSJomT8ixk AQETBXJpY2htMSEwHwYJKoZIhvcNAQkBFhJyaWNobUBuZXRzY2FwZS5jb20xFzAVBgNVBAMT DlJpY2ggTWVnZ2luc29uMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCjtycvO35sPdLF Stqay5K2LMKyD7e51X7uhDLV+/3Hlg76kaZ54H/KBj32h7PCn3+QZZFOLdHN3aEBFm+xepBb 0XQ69ikarFc5z5ize/BgTJlNbo8go0PUPlHM40Q+Lwiq8psjaGZST7G+gE9NeObvJ4AGg3+l xnFOXzz331HNuQIDAQABo4H6MIH3MA4GA1UdDwEB/wQEAwIFIDAdBgNVHSUEFjAUBggrBgEF BQcDAgYIKwYBBQUHAwQwQwYJYIZIAYb4QgENBDYWNElzc3VlZCBieSBOZXRzY2FwZSBDZXJ0 aWZpY2F0ZSBNYW5hZ2VtZW50IFN5c3RlbSA0LjUwHQYDVR0RBBYwFIEScmljaG1AbmV0c2Nh cGUuY29tMB8GA1UdIwQYMBaAFCnbsi2Dfn+LI7vCzGa5Oegp8wKGMEEGCCsGAQUFBwEBBDUw MzAxBggrBgEFBQcwAYYlaHR0cDovL2NlcnRpZmljYXRlcy5uZXRzY2FwZS5jb20vb2NzcDAN BgkqhkiG9w0BAQUFAAOBgQCwXDFoep/l+//YCFgo2LSyTsPmP1cjsqCZ7gVG1HAequjZm0KK zBI55bWiEaK9Vd7InSHZdF/hj8ACZsfrWA8y1xSo8AuKBVkTp1Hh76zmQQitAGP1DxN85Sgm 86kBzcZbqMNW5aNkW5K4Izpb+6N0EhwGx6Uv5AXlEGtUkQroijCCA4QwggLtoAMCAQICAmXk MA0GCSqGSIb3DQEBBAUAMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAUBgNVBAcT DU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcGA1UECxMQ QU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUgQXV0aG9y aXR5MB4XDTAyMTEyNjE4MTQwOFoXDTAzMDUyNTE4MTQwOFowfTELMAkGA1UEBhMCVVMxGzAZ BgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEVMBMGCgmSJomT8ixkAQETBXJpY2htMSEwHwYJ KoZIhvcNAQkBFhJyaWNobUBuZXRzY2FwZS5jb20xFzAVBgNVBAMTDlJpY2ggTWVnZ2luc29u MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDFUh7DaFJ6LKg4po0qdNFKLPsbudM37rcQ AUU3YnD02FBbiRm1Jk/0duPoenqDZ/TZ9wexCkeK79DH4cw8VZhPqGoXFSsXv3OhTfgKNir6 VEVLJsHVhkm6bbiVOIn/nuYcC7brb/+wUiL0fJB07kFzuflsgek+0pJ2tcvXcwmiOQIDAQAB o4H7MIH4MA8GA1UdDwEB/wQFAwMHgAAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MEMGCWCGSAGG+EIBDQQ2FjRJc3N1ZWQgYnkgTmV0c2NhcGUgQ2VydGlmaWNhdGUgTWFuYWdl bWVudCBTeXN0ZW0gNC41MB0GA1UdEQQWMBSBEnJpY2htQG5ldHNjYXBlLmNvbTAfBgNVHSME GDAWgBQp27Itg35/iyO7wsxmuTnoKfMChjBBBggrBgEFBQcBAQQ1MDMwMQYIKwYBBQUHMAGG JWh0dHA6Ly9jZXJ0aWZpY2F0ZXMubmV0c2NhcGUuY29tL29jc3AwDQYJKoZIhvcNAQEEBQAD gYEAqAyCrRh04NLX4Away7B39CLi0RcCBk+2vQHhXjfDe8+rK0dBOJI712YZNpyodrVnVmjN 5prJVyq/j+nTT8HWst7hp4aSHebefoSGzz6ZhAxzpgzOuSvchYytj1PE39pSaVMp1X7za/Ki FpmEXDSQqND5mLjVpSUCA1LA9X2wmgswggPWMIIDP6ADAgECAgQCAAHmMA0GCSqGSIb3DQEB BQUAMEUxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9HVEUgQ29ycG9yYXRpb24xHDAaBgNVBAMT E0dURSBDeWJlclRydXN0IFJvb3QwHhcNMDEwNjAxMTI0NzAwWhcNMDQwNjAxMjM1OTAwWjCB kzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRsw GQYDVQQKExJBbWVyaWNhIE9ubGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMx JzAlBgNVBAMTHkludHJhbmV0IENlcnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0B AQEFAAOBjQAwgYkCgYEA4u9fLHZDiUsaX7Pl+Kpviy+BTWf/vUoPYy7E3IX2nixJJiD/ABfk iIhp3v2DV+CjERkRqtbcvO+z0hUuVMZufL/ZucNG0wkFhOVTXEjthIWaDjs9Fgdc8LN5q5oQ pbzBpNF4TAblZEH8BSVjJuvvDMduVKGMzlRXth+S2rISS40CAwEAAaOCAYIwggF+ME0GA1Ud HwRGMEQwQqBAoD6GPGh0dHA6Ly93d3cxLnVzLWhvc3RpbmcuYmFsdGltb3JlLmNvbS9jZ2kt YmluL0NSTC9HVEVSb290LmNnaTAdBgNVHQ4EFgQUKduyLYN+f4sju8LMZrk56CnzAoYwZgYD VR0gBF8wXTBGBgoqhkiG+GMBAgEFMDgwNgYIKwYBBQUHAgEWKmh0dHA6Ly93d3cuYmFsdGlt b3JlLmNvbS9DUFMvT21uaVJvb3QuaHRtbDATBgMqAwQwDDAKBggrBgEFBQcCATBYBgNVHSME UTBPoUmkRzBFMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPR1RFIENvcnBvcmF0aW9uMRwwGgYD VQQDExNHVEUgQ3liZXJUcnVzdCBSb290ggIBozArBgNVHRAEJDAigA8yMDAxMDYwMTEyNDcz MFqBDzIwMDMwOTAxMjM1OTAwWjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TBAgwBgEB/wIBATAN BgkqhkiG9w0BAQUFAAOBgQBKYg7Z+kZ3BApsDd3+0iI5mRAKrogthj1XhOYSJDdp+1le4hGw +Z+kV4aKaR8GY9F97jM2SRAgDx+XFywnbD1sOQR74kXohxtUtmBBbR2uBfOd+To0muN7a0xx +OuoK4OwNZBMGWhx7fBjIl7CW+wgerWwUXPpB+6BZ3Z5U/eV1DGCAqYwggKiAgEBMIGaMIGT MQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxGzAZ BgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcGA1UECxMQQU9MIFRlY2hub2xvZ2llczEn MCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AgJl5DAJBgUrDgMCGgUA oIIBYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMTAx NTA5MTBaMCMGCSqGSIb3DQEJBDEWBBRXDQiEOp8rIxmElRLaXbJv/+pKtjBSBgkqhkiG9w0B CQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDCBrQYLKoZIhvcNAQkQAgsxgZ2ggZowgZMxCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1l cmljYSBPbmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5J bnRyYW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCAmXjMA0GCSqGSIb3DQEBAQUABIGATUtz sEyRY8FlA2nTZkpNkaZXEzs0mX2oIBW6IAiydyuU4ofGvVav5fwlNw22bSxGBfkA/edZplbq vvlbqYG5EK48EACcErTlYRIr3o0OPgbMVyhGjcs7OJu6XbgFIWQrFTQDW6hydyp+7MCuNcDO 6kg3XKxEFD+2+Cz2gCXBlXUAAAAAAAA= --------------ms030000080700070200090204-- From owner-ietf-ldup@mail.imc.org Mon Mar 10 12:45:58 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05232 for ; Mon, 10 Mar 2003 12:45:57 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2AHd4W18632 for ietf-ldup-bks; Mon, 10 Mar 2003 09:39:04 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2AHd2318627 for ; Mon, 10 Mar 2003 09:39:02 -0800 (PST) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h2AHd2Ca046722; Mon, 10 Mar 2003 17:39:03 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030310073911.025bc778@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 10 Mar 2003 09:37:16 -0800 To: richm@netscape.com (Rich Megginson) From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-ldup-lcup-04.txt Cc: ietf-ldup@imc.org In-Reply-To: <3E6CAA96.40405@netscape.com> References: <5.2.0.9.0.20030309080317.02a3a428@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 07:09 AM 3/10/2003, Rich Megginson wrote: >Kurt D. Zeilenga wrote: >> >>Is it the authors intent to allow state-based server >>implementation of this protocol? >Yes. >> >>It appears to me that >>server implementations would need to maintain historical >>information in order to appropriately support this >>protocol. >Could you elaborate? The most obvious problems are with the requests for content refresh. Without historical information, a server has no means to determine whether or not an entry whose state indicates it was updated (add,modify,rename) since the previous refresh request has left the content. It can only determine whether the updated entry is currently in the content or not. The server must assume the entry was previously in the content. Hence, the server must generate a message (update or entryLeft) for each updated entry in the context or require a reload. But worse, if any entry was deleted from the context, a server which maintains no historical information is forced to respond that a reload is required. Kurt >>Kurt >> >>At 03:53 AM 3/7/2003, Internet-Drafts@ietf.org wrote: >> >>> >>>A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF. >>> >>> Title : LDAP Client Update Protocol >>> Author(s) : R. Megginson, M. Smith, O. Natkovich, J. Parham >>> Filename : draft-ietf-ldup-lcup-04.txt >>> Pages : 27 >>> Date : 2003-3-6 >>> >>>This document defines the Lightweight Directory Access Protocol >>>(LDAP) Client Update Protocol (LCUP). The protocol is intended to >>>allow an LDAP client to synchronize with the content of a directory >>>information tree (DIT) stored by an LDAP server and to be notified >>>about the changes to that content. >>> >>>A URL for this Internet-Draft is: >>>http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-04.txt >>> >>>To remove yourself from the IETF Announcement list, send a message to >>>ietf-announce-request with the word unsubscribe in the body of the message. >>> >>>Internet-Drafts are also available by anonymous FTP. Login with the username >>>"anonymous" and a password of your e-mail address. After logging in, >>>type "cd internet-drafts" and then >>> "get draft-ietf-ldup-lcup-04.txt". >>> >>>A list of Internet-Drafts directories can be found in >>>http://www.ietf.org/shadow.html >>>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> >>>Internet-Drafts can also be obtained by e-mail. >>> >>>Send a message to: >>> mailserv@ietf.org. >>>In the body type: >>> "FILE /internet-drafts/draft-ietf-ldup-lcup-04.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. >>>Content-Type: text/plain >>>Content-ID: <2003-3-6125307.I-D@ietf.org> >>> >>>ENCODING mime >>>FILE /internet-drafts/draft-ietf-ldup-lcup-04.txt >>> >>> >>> >> >> >> > From owner-ietf-ldup@mail.imc.org Mon Mar 10 13:35:03 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07112 for ; Mon, 10 Mar 2003 13:35:02 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2AIY2W20383 for ietf-ldup-bks; Mon, 10 Mar 2003 10:34:02 -0800 (PST) Received: from triplerock.olsons.net (root@adsl-63-194-211-87.dsl.snfc21.pacbell.net [63.194.211.87]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2AIY0320379 for ; Mon, 10 Mar 2003 10:34:00 -0800 (PST) Received: from sleepycat.com (12-234-118-3.client.attbi.com [12.234.118.3]) (authenticated bits=0) by triplerock.olsons.net (8.12.8/8.12.8) with ESMTP id h2AIXi6F028883; Mon, 10 Mar 2003 10:33:44 -0800 (PST) (envelope-from merrells@sleepycat.com) Message-ID: <3E6CDA94.4070500@sleepycat.com> Date: Mon, 10 Mar 2003 10:33:56 -0800 From: John Merrells User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Rich Megginson , ietf-ldup@imc.org Subject: Re: I-D ACTION:draft-ietf-ldup-lcup-04.txt References: <5.2.0.9.0.20030309080317.02a3a428@127.0.0.1> <5.2.0.9.0.20030310073911.025bc778@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hmm. I can't resist dipping into this thread. >The most obvious problems are with the requests for content >refresh. > >Without historical information, > In a state-based system the state records the history. >a server has no means to >determine whether or not an entry whose state indicates it was >updated (add,modify,rename) since the previous refresh >request has left the content. It can only determine whether >the updated entry is currently in the content or not. The >server must assume the entry was previously in the content. >Hence, the server must generate a message (update or entryLeft) >for each updated entry in the context or require a reload. > A state-based system can record the deleted/left entires in its state. >But worse, if any entry was deleted from the context, a >server which maintains no historical information is forced >to respond that a reload is required. > Too bad. The server implementation is up to the server implementor. The server can store no state, some state, or all state. The trade off is server storage and server code complexity against client efficiency, John From owner-ietf-ldup@mail.imc.org Mon Mar 10 14:23:22 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09308 for ; Mon, 10 Mar 2003 14:23:21 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2AJKWL23346 for ietf-ldup-bks; Mon, 10 Mar 2003 11:20:32 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2AJKU323341 for ; Mon, 10 Mar 2003 11:20:31 -0800 (PST) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h2AJKVCa047295; Mon, 10 Mar 2003 19:20:31 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030310103618.025ec998@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 10 Mar 2003 11:18:44 -0800 To: John Merrells From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-ldup-lcup-04.txt Cc: Rich Megginson , ietf-ldup@imc.org In-Reply-To: <3E6CDA94.4070500@sleepycat.com> References: <5.2.0.9.0.20030309080317.02a3a428@127.0.0.1> <5.2.0.9.0.20030310073911.025bc778@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:33 AM 3/10/2003, John Merrells wrote: >Hmm. I can't resist dipping into this thread. >>The most obvious problems are with the requests for content >>refresh. >> >>Without historical information, >In a state-based system the state records the history. When I referred to a "state-based" system, I hoped it was obvious that I was referring to a system which maintained the current state of directory and meta information but did not maintain historical state information, in particular histories of state and/or content updates. If this was unclear, I apologize. >>a server has no means to >>determine whether or not an entry whose state indicates it was >>updated (add,modify,rename) since the previous refresh >>request has left the content. It can only determine whether >>the updated entry is currently in the content or not. The >>server must assume the entry was previously in the content. >>Hence, the server must generate a message (update or entryLeft) >>for each updated entry in the context or require a reload. >A state-based system can record the deleted/left entires in its state. I do not view such a system as being a state-based system. I view it as a log-based system. Do we need to more precisely defined these terms? >>But worse, if any entry was deleted from the context, a >>server which maintains no historical information is forced >>to respond that a reload is required. >Too bad. The server implementation is up to the server implementor. I disagree. Every technical specifications limit implementation approaches to those which can produce conformant implementations. However, standard track technical specifications should avoid placing undue constraints on implementation details. Here I believe, as the author clarified, it was not/is not the intent of the authors to preclude a state-based implementation approach. My follow-up message serves only to elaborate on why I believe the technical specification does preclude state-based implementation approaches. It is possible that the authors misunderstood my initial question in this thread. If so, I assume they will post a clarification. >The server can store no state, some state, or all state. I believe that LCUP should be designed such that implementors may choose whether to pursue a state-based or a log-based approach (or, possibly, some hybrid approach). I am attempting to demonstrate how the current specification precludes the state-base (e.g., no history) approach. Kurt From owner-ietf-ldup@mail.imc.org Mon Mar 10 14:38:44 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09880 for ; Mon, 10 Mar 2003 14:38:43 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2AJYsH24132 for ietf-ldup-bks; Mon, 10 Mar 2003 11:34:54 -0800 (PST) Received: from triplerock.olsons.net (root@adsl-63-194-211-87.dsl.snfc21.pacbell.net [63.194.211.87]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2AJYq324126 for ; Mon, 10 Mar 2003 11:34:52 -0800 (PST) Received: from sleepycat.com (12-234-118-3.client.attbi.com [12.234.118.3]) (authenticated bits=0) by triplerock.olsons.net (8.12.8/8.12.8) with ESMTP id h2AJYZ6G094732 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO); Mon, 10 Mar 2003 11:34:36 -0800 (PST) (envelope-from merrells@sleepycat.com) Date: Mon, 10 Mar 2003 11:34:56 -0800 Subject: Re: I-D ACTION:draft-ietf-ldup-lcup-04.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Rich Megginson , ietf-ldup@imc.org To: "Kurt D. Zeilenga" From: John Merrells In-Reply-To: <5.2.0.9.0.20030310103618.025ec998@127.0.0.1> Message-Id: <5FF34B13-532F-11D7-A90E-000A95770846@sleepycat.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Monday, March 10, 2003, at 11:18 AM, Kurt D. Zeilenga wrote: > When I referred to a "state-based" system, I hoped it was > obvious that I was referring to a system which maintained > the current state of directory and meta information but > did not maintain historical state information, in particular > histories of state and/or content updates. If this was > unclear, I apologize. Yes... the ldup documents use state-based to refer to systems that store the historical information as state, rather than log-based systems which store the historical information in a change log. Let's call your scenario 'no-history'. This is how I think a 'no- history' session would work... The client has a snapshot of the directory at some point. This point is defined by the lcup cookie it received with the data. The server is in a particular state, and knows nothing about its previous states. When the client begins an lcup session with the server it offers up its cookie. The server is unable to determine the difference between the cookie point and the current point so must therefore send everything. The client now has a current snapshot and a new cookie. Synchronization has been achieved, albeit rather inefficiently. John From owner-ietf-ldup@mail.imc.org Mon Mar 10 14:47:28 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10199 for ; Mon, 10 Mar 2003 14:47:28 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2AJiow24939 for ietf-ldup-bks; Mon, 10 Mar 2003 11:44:50 -0800 (PST) Received: from netscape.com (c3po.aoltw.net [64.236.137.25]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2AJin324935 for ; Mon, 10 Mar 2003 11:44:49 -0800 (PST) Received: from dredd.mcom.com (dredd.nscp.aoltw.net [10.169.8.48]) by netscape.com (8.10.0/8.10.0) with ESMTP id h2AJiil07359 for ; Mon, 10 Mar 2003 11:44:44 -0800 (PST) Received: from netscape.com ([10.169.192.27]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HBJTHS00.AV8; Mon, 10 Mar 2003 11:44:16 -0800 Message-ID: <3E6CEACE.50807@netscape.com> Date: Mon, 10 Mar 2003 12:43:10 -0700 From: richm@netscape.com (Rich Megginson) Organization: Netscape - Directory Server User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: John Merrells , ietf-ldup@imc.org Subject: Re: I-D ACTION:draft-ietf-ldup-lcup-04.txt References: <5.2.0.9.0.20030309080317.02a3a428@127.0.0.1> <5.2.0.9.0.20030310073911.025bc778@127.0.0.1> <5.2.0.9.0.20030310103618.025ec998@127.0.0.1> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040004080507090607050508" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040004080507090607050508 Content-Type: multipart/alternative; boundary="------------020308010809010601040602" --------------020308010809010601040602 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: >At 10:33 AM 3/10/2003, John Merrells wrote: > > >>Hmm. I can't resist dipping into this thread. >> >> >>>The most obvious problems are with the requests for content >>>refresh. >>> >>>Without historical information, >>> >>> >>In a state-based system the state records the history. >> >> >When I referred to a "state-based" system, I hoped it was >obvious that I was referring to a system which maintained >the current state of directory and meta information but >did not maintain historical state information, in particular >histories of state and/or content updates. If this was >unclear, I apologize. > I think we do need to be clear on the definitions. I assumed that a state based system would store some historical state information. That's one of the implicit assumptions of the LCUP draft. It is definitely not the intention of the authors of LCUP that the server has to store any histories of content updates. That is in fact stated pretty clearly in the document. If there is some wording in the document that suggests otherwise, I'd like to know about it and remove it/change it. >>>a server has no means to >>>determine whether or not an entry whose state indicates it was >>>updated (add,modify,rename) since the previous refresh >>>request has left the content. It can only determine whether >>>the updated entry is currently in the content or not. The >>>server must assume the entry was previously in the content. >>>Hence, the server must generate a message (update or entryLeft) >>>for each updated entry in the context or require a reload. >>> >>> >>A state-based system can record the deleted/left entires in its state. >> >> > >I do not view such a system as being a state-based system. >I view it as a log-based system. Do we need to more precisely >defined these terms? > Yes. A state based system can store historical state. One of the assumptions of LCUP is that the server already has some sort of underlying historical information storage model, like a log or a state-based system with historical information. >>>But worse, if any entry was deleted from the context, a >>>server which maintains no historical information is forced >>>to respond that a reload is required. >>> >>> >>Too bad. The server implementation is up to the server implementor. >> >> >I disagree. Every technical specifications limit implementation >approaches to those which can produce conformant implementations. >However, standard track technical specifications should avoid >placing undue constraints on implementation details. > Define "undue". >Here I believe, as the author clarified, it was not/is not the >intent of the authors to preclude a state-based implementation >approach. My follow-up message serves only to elaborate on why I >believe the technical specification does preclude state-based >implementation approaches. > >It is possible that the authors misunderstood my initial question >in this thread. If so, I assume they will post a clarification. > > > >>The server can store no state, some state, or all state. >> >> > >I believe that LCUP should be designed such that implementors may >choose whether to pursue a state-based or a log-based approach >(or, possibly, some hybrid approach). I am attempting to demonstrate >how the current specification precludes the state-base (e.g., no >history) approach. > But I don't want to force implementations to have to send every single entry in the LCUP context for every sync session, either the full entry (or at least the requested set of attributes) or just the DN. I just don't think that approach will scale and I think it will be more unpopular than having to store some historical information. > >Kurt > > > --------------020308010809010601040602 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote:
At 10:33 AM 3/10/2003, John Merrells wrote:
  
Hmm. I can't resist dipping into this thread.
    
The most obvious problems are with the requests for content
refresh.

Without historical information, 
      
In a state-based system the state records the history.
    
When I referred to a "state-based" system, I hoped it was
obvious that I was referring to a system which maintained
the current state of directory and meta information but
did not maintain historical state information, in particular
histories of state and/or content updates.  If this was
unclear, I apologize.
I think we do need to be clear on the definitions.  I assumed that a state based system would store some historical state information.  That's one of the implicit assumptions of the LCUP draft.

It is definitely not the intention of the authors of LCUP that the server has to store any histories of content updates.  That is in fact stated pretty clearly in the document.  If there is some wording in the document that suggests otherwise, I'd like to know about it and remove it/change it.
a server has no means to
determine whether or not an entry whose state indicates it was
updated (add,modify,rename) since the previous refresh
request has left the content.  It can only determine whether
the updated entry is currently in the content or not.  The
server must assume the entry was previously in the content.
Hence, the server must generate a message (update or entryLeft)
for each updated entry in the context or require a reload.
      
A state-based system can record the deleted/left entires in its state.
    

I do not view such a system as being a state-based system.
I view it as a log-based system.   Do we need to more precisely
defined these terms?
Yes.  A state based system can store historical state.  One of the assumptions of LCUP is that the server already has some sort of underlying historical information storage model, like a log or a state-based system with historical information.
But worse, if any entry was deleted from the context, a
server which maintains no historical information is forced
to respond that a reload is required.
      
Too bad. The server implementation is up to the server implementor.
    
I disagree.  Every technical specifications limit implementation
approaches to those which can produce conformant implementations.
However, standard track technical specifications should avoid
placing undue constraints on implementation details.
Define "undue".
Here I believe, as the author clarified, it was not/is not the
intent of the authors to preclude a state-based implementation
approach.  My follow-up message serves only to elaborate on why I
believe the technical specification does preclude state-based
implementation approaches.

It is possible that the authors misunderstood my initial question
in this thread.  If so, I assume they will post a clarification.

  
The server can store no state, some state, or all state.
    

I believe that LCUP should be designed such that implementors may
choose whether to pursue a state-based or a log-based approach
(or, possibly, some hybrid approach).  I am attempting to demonstrate
how the current specification precludes the state-base (e.g., no
history) approach.
But I don't want to force implementations to have to send every single entry in the LCUP context for every sync session, either the full entry (or at least the requested set of attributes) or just the DN.  I just don't think that approach will scale and I think it will be more unpopular than having to store some historical information.

Kurt

--------------020308010809010601040602-- --------------ms040004080507090607050508 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK6TCC A4MwggLsoAMCAQICAmXjMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5l IEluYzEZMBcGA1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2Vy dGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAyMTEyNjE4MTQwOFoXDTAzMDUyNTE4MTQwOFowfTEL MAkGA1UEBhMCVVMxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEVMBMGCgmSJomT8ixk AQETBXJpY2htMSEwHwYJKoZIhvcNAQkBFhJyaWNobUBuZXRzY2FwZS5jb20xFzAVBgNVBAMT DlJpY2ggTWVnZ2luc29uMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCjtycvO35sPdLF Stqay5K2LMKyD7e51X7uhDLV+/3Hlg76kaZ54H/KBj32h7PCn3+QZZFOLdHN3aEBFm+xepBb 0XQ69ikarFc5z5ize/BgTJlNbo8go0PUPlHM40Q+Lwiq8psjaGZST7G+gE9NeObvJ4AGg3+l xnFOXzz331HNuQIDAQABo4H6MIH3MA4GA1UdDwEB/wQEAwIFIDAdBgNVHSUEFjAUBggrBgEF BQcDAgYIKwYBBQUHAwQwQwYJYIZIAYb4QgENBDYWNElzc3VlZCBieSBOZXRzY2FwZSBDZXJ0 aWZpY2F0ZSBNYW5hZ2VtZW50IFN5c3RlbSA0LjUwHQYDVR0RBBYwFIEScmljaG1AbmV0c2Nh cGUuY29tMB8GA1UdIwQYMBaAFCnbsi2Dfn+LI7vCzGa5Oegp8wKGMEEGCCsGAQUFBwEBBDUw MzAxBggrBgEFBQcwAYYlaHR0cDovL2NlcnRpZmljYXRlcy5uZXRzY2FwZS5jb20vb2NzcDAN BgkqhkiG9w0BAQUFAAOBgQCwXDFoep/l+//YCFgo2LSyTsPmP1cjsqCZ7gVG1HAequjZm0KK zBI55bWiEaK9Vd7InSHZdF/hj8ACZsfrWA8y1xSo8AuKBVkTp1Hh76zmQQitAGP1DxN85Sgm 86kBzcZbqMNW5aNkW5K4Izpb+6N0EhwGx6Uv5AXlEGtUkQroijCCA4QwggLtoAMCAQICAmXk MA0GCSqGSIb3DQEBBAUAMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAUBgNVBAcT DU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcGA1UECxMQ QU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUgQXV0aG9y aXR5MB4XDTAyMTEyNjE4MTQwOFoXDTAzMDUyNTE4MTQwOFowfTELMAkGA1UEBhMCVVMxGzAZ BgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEVMBMGCgmSJomT8ixkAQETBXJpY2htMSEwHwYJ KoZIhvcNAQkBFhJyaWNobUBuZXRzY2FwZS5jb20xFzAVBgNVBAMTDlJpY2ggTWVnZ2luc29u MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDFUh7DaFJ6LKg4po0qdNFKLPsbudM37rcQ AUU3YnD02FBbiRm1Jk/0duPoenqDZ/TZ9wexCkeK79DH4cw8VZhPqGoXFSsXv3OhTfgKNir6 VEVLJsHVhkm6bbiVOIn/nuYcC7brb/+wUiL0fJB07kFzuflsgek+0pJ2tcvXcwmiOQIDAQAB o4H7MIH4MA8GA1UdDwEB/wQFAwMHgAAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MEMGCWCGSAGG+EIBDQQ2FjRJc3N1ZWQgYnkgTmV0c2NhcGUgQ2VydGlmaWNhdGUgTWFuYWdl bWVudCBTeXN0ZW0gNC41MB0GA1UdEQQWMBSBEnJpY2htQG5ldHNjYXBlLmNvbTAfBgNVHSME GDAWgBQp27Itg35/iyO7wsxmuTnoKfMChjBBBggrBgEFBQcBAQQ1MDMwMQYIKwYBBQUHMAGG JWh0dHA6Ly9jZXJ0aWZpY2F0ZXMubmV0c2NhcGUuY29tL29jc3AwDQYJKoZIhvcNAQEEBQAD gYEAqAyCrRh04NLX4Away7B39CLi0RcCBk+2vQHhXjfDe8+rK0dBOJI712YZNpyodrVnVmjN 5prJVyq/j+nTT8HWst7hp4aSHebefoSGzz6ZhAxzpgzOuSvchYytj1PE39pSaVMp1X7za/Ki FpmEXDSQqND5mLjVpSUCA1LA9X2wmgswggPWMIIDP6ADAgECAgQCAAHmMA0GCSqGSIb3DQEB BQUAMEUxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9HVEUgQ29ycG9yYXRpb24xHDAaBgNVBAMT E0dURSBDeWJlclRydXN0IFJvb3QwHhcNMDEwNjAxMTI0NzAwWhcNMDQwNjAxMjM1OTAwWjCB kzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRsw GQYDVQQKExJBbWVyaWNhIE9ubGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMx JzAlBgNVBAMTHkludHJhbmV0IENlcnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0B AQEFAAOBjQAwgYkCgYEA4u9fLHZDiUsaX7Pl+Kpviy+BTWf/vUoPYy7E3IX2nixJJiD/ABfk iIhp3v2DV+CjERkRqtbcvO+z0hUuVMZufL/ZucNG0wkFhOVTXEjthIWaDjs9Fgdc8LN5q5oQ pbzBpNF4TAblZEH8BSVjJuvvDMduVKGMzlRXth+S2rISS40CAwEAAaOCAYIwggF+ME0GA1Ud HwRGMEQwQqBAoD6GPGh0dHA6Ly93d3cxLnVzLWhvc3RpbmcuYmFsdGltb3JlLmNvbS9jZ2kt YmluL0NSTC9HVEVSb290LmNnaTAdBgNVHQ4EFgQUKduyLYN+f4sju8LMZrk56CnzAoYwZgYD VR0gBF8wXTBGBgoqhkiG+GMBAgEFMDgwNgYIKwYBBQUHAgEWKmh0dHA6Ly93d3cuYmFsdGlt b3JlLmNvbS9DUFMvT21uaVJvb3QuaHRtbDATBgMqAwQwDDAKBggrBgEFBQcCATBYBgNVHSME UTBPoUmkRzBFMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPR1RFIENvcnBvcmF0aW9uMRwwGgYD VQQDExNHVEUgQ3liZXJUcnVzdCBSb290ggIBozArBgNVHRAEJDAigA8yMDAxMDYwMTEyNDcz MFqBDzIwMDMwOTAxMjM1OTAwWjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TBAgwBgEB/wIBATAN BgkqhkiG9w0BAQUFAAOBgQBKYg7Z+kZ3BApsDd3+0iI5mRAKrogthj1XhOYSJDdp+1le4hGw +Z+kV4aKaR8GY9F97jM2SRAgDx+XFywnbD1sOQR74kXohxtUtmBBbR2uBfOd+To0muN7a0xx +OuoK4OwNZBMGWhx7fBjIl7CW+wgerWwUXPpB+6BZ3Z5U/eV1DGCAqYwggKiAgEBMIGaMIGT MQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxGzAZ BgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcGA1UECxMQQU9MIFRlY2hub2xvZ2llczEn MCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AgJl5DAJBgUrDgMCGgUA oIIBYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMTAx OTQzMTBaMCMGCSqGSIb3DQEJBDEWBBS/2b5m7r+oZHY5DSaZV6v2aEYXTjBSBgkqhkiG9w0B CQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDCBrQYLKoZIhvcNAQkQAgsxgZ2ggZowgZMxCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1l cmljYSBPbmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5J bnRyYW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCAmXjMA0GCSqGSIb3DQEBAQUABIGAo4xc Gw2XZn77r5zKJcAwnhb4uxr94/FXoDJwORvxlUXUD5NUzDtExwtuhMwp57RumYlbTLwXywp9 IzMvAUAx4S/TXuy4qSUH606wHw+usWnjmj0IVkpubZIC3dypvInoQy7STRYv+ZvBk3XfWWQd Xf/IH5sIGBcjtUnjeHzCdPkAAAAAAAA= --------------ms040004080507090607050508-- From owner-ietf-ldup@mail.imc.org Mon Mar 10 15:19:38 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12041 for ; Mon, 10 Mar 2003 15:19:37 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2AKHFw29031 for ietf-ldup-bks; Mon, 10 Mar 2003 12:17:15 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2AKHD329024 for ; Mon, 10 Mar 2003 12:17:13 -0800 (PST) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h2AKHECa047569 for ; Mon, 10 Mar 2003 20:17:15 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030310120623.025e8be8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 10 Mar 2003 12:15:28 -0800 To: ietf-ldup@imc.org From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-ldup-lcup-04.txt In-Reply-To: <5.2.0.9.0.20030309080317.02a3a428@127.0.0.1> References: <200303071153.GAA21349@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Given the confusion over terminology, I suggest we start over. Is it the authors intent to allow a "no-histories"-based server implementation approach of this protocol? A "no-histories" implementation approach is one where the server does not maintain histories of directory or meta information changes but instead relies on the current directory and meta information and the "cookie". It appears to me that server implementations would need to maintain historical directory and meta information in order to appropriately support this protocol. Kurt From owner-ietf-ldup@mail.imc.org Mon Mar 10 15:20:24 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12083 for ; Mon, 10 Mar 2003 15:20:23 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2AKGfq28943 for ietf-ldup-bks; Mon, 10 Mar 2003 12:16:41 -0800 (PST) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2AKGa328928 for ; Mon, 10 Mar 2003 12:16:36 -0800 (PST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e3.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h2AKGXl9194814 for ; Mon, 10 Mar 2003 15:16:33 -0500 Received: from d27ml001.rchland.ibm.com (d27ml001.rchland.ibm.com [9.10.226.52]) by northrelay02.pok.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h2AKGU2q023344 for ; Mon, 10 Mar 2003 15:16:30 -0500 Subject: Re: I-D ACTION:draft-ietf-ldup-lcup-04.txt To: ietf-ldup@imc.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: John McMeeking Date: Mon, 10 Mar 2003 14:16:30 -0600 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 6.0.1|February 07, 2003) at 03/10/2003 14:16:32 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: It seem like the log-based vs state-based distinctions may not be necessary if we borrow some ideas from LDUP. LDUP has the notion that deleted entries be maintained by the server for some period of time. A client search never returns these entries, but the server keeps knowledge that the entry with UUID 'x-uuid' was deleted at time 'x-deleted-time'. This could be implemented using a log (search log for deleted entries) or state (meta-data). LDUP doesn't care (though at some level it starts to be awfully hard to be state/log based agnostic). If a cookie has some sort of time information, then a server can: - find entries that have been added (createTimestamp attribute or equivalent) - find entries that have been modified (modifyTimestamp or equivalent) - find entries that have been deleted (delete timestamp described above) Modify DN presents problems. Perhaps we could add a superior timestamp (new superior) and RDN timestamp (rename). Not knowing where the entry came from, all modify DN operations (with appropriate time) would be treated as "entered result set" if they are now in the result set, and as "left result set" if they are not now in the result set. I think modify would not follow the letter of the draft. Any change to an entry would have to be treated as a change to the attributes the client was interested in. But I don't think that should cause problems, unless there are a lot of these changes relative to changes the client is really interested in (whatever "a lot" is). A server probably wouldn't want to keep deleted entry state information around forever. A server implementation should be able to prune this -- could be as arbitrary as discarding deleted entry information after a fixed period. Any LCUP cookie that corresponded to a time prior to this period would require a resync. Deletes should be relatively infrequent, so it should be possible for this time period to be fairly long. Assuming everyone views this as appropriate state information, a log-based implementation is not required. I doubt LCUP needs to say any of this, but maybe others think such "hints" are appropriate. John McMeeking "Kurt D. Zeilenga" To: John Merrells , ietf-ldup@imc.org g> Subject: Re: I-D ACTION:draft-ietf-ldup-lcup-04.txt Sent by: owner-ietf-ldup@m ail.imc.org 03/10/2003 01:18 PM At 10:33 AM 3/10/2003, John Merrells wrote: >Hmm. I can't resist dipping into this thread. >>The most obvious problems are with the requests for content >>refresh. >> >>Without historical information, >In a state-based system the state records the history. When I referred to a "state-based" system, I hoped it was obvious that I was referring to a system which maintained the current state of directory and meta information but did not maintain historical state information, in particular histories of state and/or content updates. If this was unclear, I apologize. >>a server has no means to >>determine whether or not an entry whose state indicates it was >>updated (add,modify,rename) since the previous refresh >>request has left the content. It can only determine whether >>the updated entry is currently in the content or not. The >>server must assume the entry was previously in the content. >>Hence, the server must generate a message (update or entryLeft) >>for each updated entry in the context or require a reload. >A state-based system can record the deleted/left entires in its state. I do not view such a system as being a state-based system. I view it as a log-based system. Do we need to more precisely defined these terms? >>But worse, if any entry was deleted from the context, a >>server which maintains no historical information is forced >>to respond that a reload is required. >Too bad. The server implementation is up to the server implementor. I disagree. Every technical specifications limit implementation approaches to those which can produce conformant implementations. However, standard track technical specifications should avoid placing undue constraints on implementation details. Here I believe, as the author clarified, it was not/is not the intent of the authors to preclude a state-based implementation approach. My follow-up message serves only to elaborate on why I believe the technical specification does preclude state-based implementation approaches. It is possible that the authors misunderstood my initial question in this thread. If so, I assume they will post a clarification. >The server can store no state, some state, or all state. I believe that LCUP should be designed such that implementors may choose whether to pursue a state-based or a log-based approach (or, possibly, some hybrid approach). I am attempting to demonstrate how the current specification precludes the state-base (e.g., no history) approach. Kurt From owner-ietf-ldup@mail.imc.org Mon Mar 10 15:39:08 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13048 for ; Mon, 10 Mar 2003 15:39:07 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2AKZsS00882 for ietf-ldup-bks; Mon, 10 Mar 2003 12:35:54 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2AKZq300878 for ; Mon, 10 Mar 2003 12:35:52 -0800 (PST) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h2AKZrCa047728; Mon, 10 Mar 2003 20:35:53 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030310121655.025d3fc8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 10 Mar 2003 12:34:06 -0800 To: richm@netscape.com (Rich Megginson) From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-ldup-lcup-04.txt Cc: John Merrells , ietf-ldup@imc.org In-Reply-To: <3E6CEACE.50807@netscape.com> References: <5.2.0.9.0.20030309080317.02a3a428@127.0.0.1> <5.2.0.9.0.20030310073911.025bc778@127.0.0.1> <5.2.0.9.0.20030310103618.025ec998@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:43 AM 3/10/2003, Rich Megginson wrote: >It is definitely not the intention of the authors of LCUP that the server has to store any histories of content updates. [...] >A state based system can store historical state. One of the assumptions of LCUP is that the server already has some sort of underlying historical information storage model, like a log or a state-based system with historical information. How do you reconcile your statement that a server need not store any histories with your statement that LCUP assumes an historical information storage model? They seem counter to each other. >>I disagree. Every technical specifications limit implementation >>approaches to those which can produce conformant implementations. >>However, standard track technical specifications should avoid >>placing undue constraints on implementation details. >Define "undue". "inappropriate" or "improper". From owner-ietf-ldup@mail.imc.org Mon Mar 10 15:50:40 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13631 for ; Mon, 10 Mar 2003 15:50:39 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2AKkpq01145 for ietf-ldup-bks; Mon, 10 Mar 2003 12:46:51 -0800 (PST) Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2AKkj301139 for ; Mon, 10 Mar 2003 12:46:45 -0800 (PST) Received: from dredd.mcom.com (dredd.nscp.aoltw.net [10.169.8.48]) by netscape.com (8.10.0/8.10.0) with ESMTP id h2AKkfR24749 for ; Mon, 10 Mar 2003 12:46:41 -0800 (PST) Received: from netscape.com ([10.169.192.27]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HBJWD100.0R5; Mon, 10 Mar 2003 12:46:13 -0800 Message-ID: <3E6CF956.7040301@netscape.com> Date: Mon, 10 Mar 2003 13:45:10 -0700 From: richm@netscape.com (Rich Megginson) Organization: Netscape - Directory Server User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: John Merrells , ietf-ldup@imc.org Subject: Re: I-D ACTION:draft-ietf-ldup-lcup-04.txt References: <5.2.0.9.0.20030309080317.02a3a428@127.0.0.1> <5.2.0.9.0.20030310073911.025bc778@127.0.0.1> <5.2.0.9.0.20030310103618.025ec998@127.0.0.1> <5.2.0.9.0.20030310121655.025d3fc8@127.0.0.1> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000008080102030604080709" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000008080102030604080709 Content-Type: multipart/alternative; boundary="------------090807010301070105010703" --------------090807010301070105010703 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: >At 11:43 AM 3/10/2003, Rich Megginson wrote: > > >>It is definitely not the intention of the authors of LCUP that the server has to store any histories of content updates. >> >> >[...] > > >>A state based system can store historical state. One of the assumptions of LCUP is that the server already has some sort of underlying historical information storage model, like a log or a state-based system with historical information. >> >> > >How do you reconcile your statement that a server need not store >any histories with your statement that LCUP assumes an historical >information storage model? They seem counter to each other. > Another misunderstanding. I meant that we did not intend a server implementing LCUP to have to store any information specific to a client, like the last content update for a particular client. >>>I disagree. Every technical specifications limit implementation >>>approaches to those which can produce conformant implementations. >>>However, standard track technical specifications should avoid >>>placing undue constraints on implementation details. >>> >>> >>Define "undue". >> >> > >"inappropriate" or "improper". > I just don't see how ANY synchronization protocol that attempts to not send every entry every sync session can be useful or even possible if the server stores no historical (even very recent) state information. > > --------------090807010301070105010703 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote:
At 11:43 AM 3/10/2003, Rich Megginson wrote:
  
It is definitely not the intention of the authors of LCUP that the server has to store any histories of content updates.
    
[...]
  
A state based system can store historical state.  One of the assumptions of LCUP is that the server already has some sort of underlying historical information storage model, like a log or a state-based system with historical information.
    

How do you reconcile your statement that a server need not store
any histories with your statement that LCUP assumes an historical
information storage model?  They seem counter to each other.
Another misunderstanding.  I meant that we did not intend a server implementing LCUP to have to store any information specific to a client, like the last content update for a particular client.
I disagree.  Every technical specifications limit implementation
approaches to those which can produce conformant implementations.
However, standard track technical specifications should avoid
placing undue constraints on implementation details.
      
Define "undue".
    

"inappropriate" or "improper".
I just don't see how ANY synchronization protocol that attempts to not send every entry every sync session can be useful or even possible if the server stores no historical (even very recent) state information.
--------------090807010301070105010703-- --------------ms000008080102030604080709 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK6TCC A4MwggLsoAMCAQICAmXjMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5l IEluYzEZMBcGA1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2Vy dGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAyMTEyNjE4MTQwOFoXDTAzMDUyNTE4MTQwOFowfTEL MAkGA1UEBhMCVVMxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEVMBMGCgmSJomT8ixk AQETBXJpY2htMSEwHwYJKoZIhvcNAQkBFhJyaWNobUBuZXRzY2FwZS5jb20xFzAVBgNVBAMT DlJpY2ggTWVnZ2luc29uMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCjtycvO35sPdLF Stqay5K2LMKyD7e51X7uhDLV+/3Hlg76kaZ54H/KBj32h7PCn3+QZZFOLdHN3aEBFm+xepBb 0XQ69ikarFc5z5ize/BgTJlNbo8go0PUPlHM40Q+Lwiq8psjaGZST7G+gE9NeObvJ4AGg3+l xnFOXzz331HNuQIDAQABo4H6MIH3MA4GA1UdDwEB/wQEAwIFIDAdBgNVHSUEFjAUBggrBgEF BQcDAgYIKwYBBQUHAwQwQwYJYIZIAYb4QgENBDYWNElzc3VlZCBieSBOZXRzY2FwZSBDZXJ0 aWZpY2F0ZSBNYW5hZ2VtZW50IFN5c3RlbSA0LjUwHQYDVR0RBBYwFIEScmljaG1AbmV0c2Nh cGUuY29tMB8GA1UdIwQYMBaAFCnbsi2Dfn+LI7vCzGa5Oegp8wKGMEEGCCsGAQUFBwEBBDUw MzAxBggrBgEFBQcwAYYlaHR0cDovL2NlcnRpZmljYXRlcy5uZXRzY2FwZS5jb20vb2NzcDAN BgkqhkiG9w0BAQUFAAOBgQCwXDFoep/l+//YCFgo2LSyTsPmP1cjsqCZ7gVG1HAequjZm0KK zBI55bWiEaK9Vd7InSHZdF/hj8ACZsfrWA8y1xSo8AuKBVkTp1Hh76zmQQitAGP1DxN85Sgm 86kBzcZbqMNW5aNkW5K4Izpb+6N0EhwGx6Uv5AXlEGtUkQroijCCA4QwggLtoAMCAQICAmXk MA0GCSqGSIb3DQEBBAUAMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAUBgNVBAcT DU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcGA1UECxMQ QU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUgQXV0aG9y aXR5MB4XDTAyMTEyNjE4MTQwOFoXDTAzMDUyNTE4MTQwOFowfTELMAkGA1UEBhMCVVMxGzAZ BgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEVMBMGCgmSJomT8ixkAQETBXJpY2htMSEwHwYJ KoZIhvcNAQkBFhJyaWNobUBuZXRzY2FwZS5jb20xFzAVBgNVBAMTDlJpY2ggTWVnZ2luc29u MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDFUh7DaFJ6LKg4po0qdNFKLPsbudM37rcQ AUU3YnD02FBbiRm1Jk/0duPoenqDZ/TZ9wexCkeK79DH4cw8VZhPqGoXFSsXv3OhTfgKNir6 VEVLJsHVhkm6bbiVOIn/nuYcC7brb/+wUiL0fJB07kFzuflsgek+0pJ2tcvXcwmiOQIDAQAB o4H7MIH4MA8GA1UdDwEB/wQFAwMHgAAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MEMGCWCGSAGG+EIBDQQ2FjRJc3N1ZWQgYnkgTmV0c2NhcGUgQ2VydGlmaWNhdGUgTWFuYWdl bWVudCBTeXN0ZW0gNC41MB0GA1UdEQQWMBSBEnJpY2htQG5ldHNjYXBlLmNvbTAfBgNVHSME GDAWgBQp27Itg35/iyO7wsxmuTnoKfMChjBBBggrBgEFBQcBAQQ1MDMwMQYIKwYBBQUHMAGG JWh0dHA6Ly9jZXJ0aWZpY2F0ZXMubmV0c2NhcGUuY29tL29jc3AwDQYJKoZIhvcNAQEEBQAD gYEAqAyCrRh04NLX4Away7B39CLi0RcCBk+2vQHhXjfDe8+rK0dBOJI712YZNpyodrVnVmjN 5prJVyq/j+nTT8HWst7hp4aSHebefoSGzz6ZhAxzpgzOuSvchYytj1PE39pSaVMp1X7za/Ki FpmEXDSQqND5mLjVpSUCA1LA9X2wmgswggPWMIIDP6ADAgECAgQCAAHmMA0GCSqGSIb3DQEB BQUAMEUxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9HVEUgQ29ycG9yYXRpb24xHDAaBgNVBAMT E0dURSBDeWJlclRydXN0IFJvb3QwHhcNMDEwNjAxMTI0NzAwWhcNMDQwNjAxMjM1OTAwWjCB kzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRsw GQYDVQQKExJBbWVyaWNhIE9ubGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMx JzAlBgNVBAMTHkludHJhbmV0IENlcnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0B AQEFAAOBjQAwgYkCgYEA4u9fLHZDiUsaX7Pl+Kpviy+BTWf/vUoPYy7E3IX2nixJJiD/ABfk iIhp3v2DV+CjERkRqtbcvO+z0hUuVMZufL/ZucNG0wkFhOVTXEjthIWaDjs9Fgdc8LN5q5oQ pbzBpNF4TAblZEH8BSVjJuvvDMduVKGMzlRXth+S2rISS40CAwEAAaOCAYIwggF+ME0GA1Ud HwRGMEQwQqBAoD6GPGh0dHA6Ly93d3cxLnVzLWhvc3RpbmcuYmFsdGltb3JlLmNvbS9jZ2kt YmluL0NSTC9HVEVSb290LmNnaTAdBgNVHQ4EFgQUKduyLYN+f4sju8LMZrk56CnzAoYwZgYD VR0gBF8wXTBGBgoqhkiG+GMBAgEFMDgwNgYIKwYBBQUHAgEWKmh0dHA6Ly93d3cuYmFsdGlt b3JlLmNvbS9DUFMvT21uaVJvb3QuaHRtbDATBgMqAwQwDDAKBggrBgEFBQcCATBYBgNVHSME UTBPoUmkRzBFMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPR1RFIENvcnBvcmF0aW9uMRwwGgYD VQQDExNHVEUgQ3liZXJUcnVzdCBSb290ggIBozArBgNVHRAEJDAigA8yMDAxMDYwMTEyNDcz MFqBDzIwMDMwOTAxMjM1OTAwWjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TBAgwBgEB/wIBATAN BgkqhkiG9w0BAQUFAAOBgQBKYg7Z+kZ3BApsDd3+0iI5mRAKrogthj1XhOYSJDdp+1le4hGw +Z+kV4aKaR8GY9F97jM2SRAgDx+XFywnbD1sOQR74kXohxtUtmBBbR2uBfOd+To0muN7a0xx +OuoK4OwNZBMGWhx7fBjIl7CW+wgerWwUXPpB+6BZ3Z5U/eV1DGCAqYwggKiAgEBMIGaMIGT MQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxGzAZ BgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcGA1UECxMQQU9MIFRlY2hub2xvZ2llczEn MCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AgJl5DAJBgUrDgMCGgUA oIIBYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMTAy MDQ1MTBaMCMGCSqGSIb3DQEJBDEWBBSYXWUFssSeSKiJxVJPOb3l8i0hhDBSBgkqhkiG9w0B CQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDCBrQYLKoZIhvcNAQkQAgsxgZ2ggZowgZMxCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1l cmljYSBPbmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5J bnRyYW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCAmXjMA0GCSqGSIb3DQEBAQUABIGAFoBN v0RWFsYDG+iFjuTuAh4nSBASA3Y7JsrhASV+XZrqDjQMRMtbQzaBvyYZVwb1Kbjk9KKXP/Mg vy6vHaY5rm44uAgDMEAPq7p8cVEPgO25pPp6B8g09v7ryzA5lKC00xp2DFqo1PlOlMlfEaAL YKcgX/Vt9ulfkW92W0JRL0YAAAAAAAA= --------------ms000008080102030604080709-- From owner-ietf-ldup@mail.imc.org Mon Mar 10 17:29:40 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17476 for ; Mon, 10 Mar 2003 17:29:37 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2AMQhw04382 for ietf-ldup-bks; Mon, 10 Mar 2003 14:26:43 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2AMQf304378 for ; Mon, 10 Mar 2003 14:26:41 -0800 (PST) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h2AMQgCa048506; Mon, 10 Mar 2003 22:26:42 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030310135214.025ceb08@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 10 Mar 2003 14:24:55 -0800 To: John McMeeking From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-ldup-lcup-04.txt Cc: ietf-ldup@imc.org 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:16 PM 3/10/2003, John McMeeking wrote: >It seem like the log-based vs state-based distinctions may not be necessary >if we borrow some ideas from LDUP. > >LDUP has the notion that deleted entries be maintained by the server for >some period of time. A client search never returns these entries, but the >server keeps knowledge that the entry with UUID 'x-uuid' was deleted at >time 'x-deleted-time'. This could be implemented using a log (search log >for deleted entries) or state (meta-data). LDUP doesn't care (though at >some level it starts to be awfully hard to be state/log based agnostic). > >If a cookie has some sort of time information, then a server can: >- find entries that have been added (createTimestamp attribute or >equivalent) >- find entries that have been modified (modifyTimestamp or equivalent) >- find entries that have been deleted (delete timestamp described above) Without additional historical information, the server however would not in general be able to determine whether or not an updated entry presently not currently within the content was in the content at the time indicated by the cookie. The server must assume it was in the content at the time indicated by the cookie and generate an appropriate message to the client. >Modify DN presents problems. Perhaps we could add a superior timestamp >(new superior) and RDN timestamp (rename). Not knowing where the entry >came from, all modify DN operations (with appropriate time) would be >treated as "entered result set" if they are now in the result set, and as >"left result set" if they are not now in the result set. >I think modify would not follow the letter of the draft. Any change to an >entry would have to be treated as a change to the attributes the client was >interested in. Yes. Say the updated entry is within scope of the search but currently doesn't match the search criteria. Without additional historical information, the server would not be able to determine if the entry was in the content at the time indicated by the cookie. The server must assume it was in the content at the time indicated by the cookie and generate an appropriate message to the client. >But I don't think that should cause problems, unless there >are a lot of these changes relative to changes the client is really >interested in (whatever "a lot" is). The problem here is that the server is unable to determine whether an updated entry in the CONTEXT was previously in the content without additional historical information and hence must assume that it was in the CONTENT at the time indicated by the cookie. That is, the problem severity is relative to the changes to the CONTEXT not just to CONTENT. >A server probably wouldn't want to keep deleted entry state information >around forever. A server implementation should be able to prune this -- >could be as arbitrary as discarding deleted entry information after a fixed >period. Any LCUP cookie that corresponded to a time prior to this period >would require a resync. Deletes should be relatively infrequent, so it >should be possible for this time period to be fairly long. > >Assuming everyone views this as appropriate state information, a log-based >implementation is not required. I doubt LCUP needs to say any of this, but >maybe others think such "hints" are appropriate. Well, I thin that if we believe that certain implementation approaches would lead to implementations which would do harm, that we should state these beliefs and, where appropriate, detail implementation-approach-neutral imperatives of what behaviors are considered harmful. Lack of "eventual convergence data consistency" and/or "overly chattiness" would be harmful. Kurt Kurt From owner-ietf-ldup@mail.imc.org Mon Mar 10 17:53:17 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18276 for ; Mon, 10 Mar 2003 17:53:17 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2AMmHm05771 for ietf-ldup-bks; Mon, 10 Mar 2003 14:48:17 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2AMmD305765 for ; Mon, 10 Mar 2003 14:48:14 -0800 (PST) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h2AMmFCa048706; Mon, 10 Mar 2003 22:48:15 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030310144235.01a22810@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 10 Mar 2003 14:46:28 -0800 To: John McMeeking From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-ldup-lcup-04.txt Cc: ietf-ldup@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [resent to fix some nasty typos] At 12:16 PM 3/10/2003, John McMeeking wrote: >It seem like the log-based vs state-based distinctions may not be necessary >if we borrow some ideas from LDUP. > >LDUP has the notion that deleted entries be maintained by the server for >some period of time. A client search never returns these entries, but the >server keeps knowledge that the entry with UUID 'x-uuid' was deleted at >time 'x-deleted-time'. This could be implemented using a log (search log >for deleted entries) or state (meta-data). LDUP doesn't care (though at >some level it starts to be awfully hard to be state/log based agnostic). > >If a cookie has some sort of time information, then a server can: >- find entries that have been added (createTimestamp attribute or >equivalent) >- find entries that have been modified (modifyTimestamp or equivalent) >- find entries that have been deleted (delete timestamp described above) Without additional historical information, the server however would not, in general, be able to determine whether or not an updated entry within the context was in the content at the time indicated by the cookie. The server must assume it was in the content at the time indicated by the cookie and generate an appropriate message to the client. >Modify DN presents problems. Perhaps we could add a superior timestamp >(new superior) and RDN timestamp (rename). Not knowing where the entry >came from, all modify DN operations (with appropriate time) would be >treated as "entered result set" if they are now in the result set, and as >"left result set" if they are not now in the result set. >I think modify would not follow the letter of the draft. Any change to an >entry would have to be treated as a change to the attributes the client was >interested in. Yes. Say the updated entry is within scope of the search but currently doesn't match the search criteria. Without additional historical information, the server would not be able to determine if the updated entry was in the content at the time indicated by the cookie. The server must assume it was in the content at the time indicated by the cookie and generate an appropriate message to the client. >But I don't think that should cause problems, unless there >are a lot of these changes relative to changes the client is really >interested in (whatever "a lot" is). The problem here is that the server is unable to determine whether an updated entry in the CONTEXT was previously in the CONTENT without additional historical information and hence must assume that it was in the CONTENT at the time indicated by the cookie. That is, the problem severity is relative to the changes to the CONTEXT not just to CONTENT. >A server probably wouldn't want to keep deleted entry state information >around forever. A server implementation should be able to prune this -- >could be as arbitrary as discarding deleted entry information after a fixed >period. Any LCUP cookie that corresponded to a time prior to this period >would require a resync. Deletes should be relatively infrequent, so it >should be possible for this time period to be fairly long. > >Assuming everyone views this as appropriate state information, a log-based >implementation is not required. I doubt LCUP needs to say any of this, but >maybe others think such "hints" are appropriate. Well, I thin that if we believe that certain implementation approaches would lead to implementations which would do harm, that we should state these beliefs and, where appropriate, detail implementation-approach-neutral imperatives of what behaviors are considered harmful. Lack of "eventual convergence data consistency" and/or "overly chattiness" would be harmful. Kurt From owner-ietf-ldup@mail.imc.org Mon Mar 10 18:17:06 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20410 for ; Mon, 10 Mar 2003 18:17:06 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2ANEDu07284 for ietf-ldup-bks; Mon, 10 Mar 2003 15:14:13 -0800 (PST) Received: from triplerock.olsons.net (root@adsl-63-194-211-87.dsl.snfc21.pacbell.net [63.194.211.87]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2ANEC307276 for ; Mon, 10 Mar 2003 15:14:12 -0800 (PST) Received: from sleepycat.com (12-234-118-3.client.attbi.com [12.234.118.3]) (authenticated bits=0) by triplerock.olsons.net (8.12.8/8.12.8) with ESMTP id h2ANDu6F094273; Mon, 10 Mar 2003 15:13:56 -0800 (PST) (envelope-from merrells@sleepycat.com) Message-ID: <3E6D1C49.6090409@sleepycat.com> Date: Mon, 10 Mar 2003 15:14:17 -0800 From: John Merrells User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: John McMeeking , ietf-ldup@imc.org Subject: Re: I-D ACTION:draft-ietf-ldup-lcup-04.txt References: <5.2.0.9.0.20030310135214.025ceb08@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: >Well, I thin that if we believe that certain implementation >approaches would lead to implementations which would do harm, >that we should state these beliefs and, where appropriate, >detail implementation-approach-neutral imperatives of what >behaviors are considered harmful. > In other words you're suggesting that the specification document that implementors should implement the specification correctly. >Lack of "eventual convergence data consistency" > What does LCUP currently state? You're looking for a guarentee from LCUP that the client state be exactly the same as a server state at some point? >and/or "overly chattiness" would be harmful. > That's implementation defined. John From owner-ietf-ldup@mail.imc.org Mon Mar 10 20:58:02 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24000 for ; Mon, 10 Mar 2003 20:58:02 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2B1W7911435 for ietf-ldup-bks; Mon, 10 Mar 2003 17:32:07 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2B1W5311431 for ; Mon, 10 Mar 2003 17:32:05 -0800 (PST) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h2B1W3Ca049649; Tue, 11 Mar 2003 01:32:03 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030310160606.025e40c0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 10 Mar 2003 17:30:16 -0800 To: John Merrells From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-ldup-lcup-04.txt Cc: John McMeeking , ietf-ldup@imc.org In-Reply-To: <3E6D1C49.6090409@sleepycat.com> References: <5.2.0.9.0.20030310135214.025ceb08@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 03:14 PM 3/10/2003, John Merrells wrote: >Kurt D. Zeilenga wrote: >>Well, I thin that if we believe that certain implementation >>approaches would lead to implementations which would do harm, >>that we should state these beliefs and, where appropriate, >>detail implementation-approach-neutral imperatives of what >>behaviors are considered harmful. >In other words you're suggesting that the specification document that implementors should implement the specification correctly. I'm suggesting the specification discuss areas where the implementor should take care not to do harm. >>Lack of "eventual convergence data consistency" >What does LCUP currently state? Presently, the I-D is a bit lacking in its data consistency statements. It needs to be more explicit in stating that servers are to either generate messages which will lead to convergence or return an error. This, I think, can be resolved by rewording portions of 3.3.7. >You're looking for a guarentee from LCUP that the client state be >exactly the same as a server state at some point? I am looking for the LCUP to be designed to support content synchronization with eventual convergent data consistency. I'm not yet convinced that LCUP provides this, hence this dialog. >>and/or "overly chattiness" would be harmful. >That's implementation defined. Chattiness should be defined in terms of the protocol and the operations they perform. Not only should protocols be designed to avoid overly chattiness, where the protocol implementation allows for chatty protocol exchanges, the specification should discuss chattiness issues and state appropriate imperatives. The LCUP I-D makes some statements in this area, I believe more is necessary and will over specific suggestions at a later date. Kurt From owner-ietf-ldup@mail.imc.org Mon Mar 10 21:44:19 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24721 for ; Mon, 10 Mar 2003 21:44:18 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2B2gXJ13771 for ietf-ldup-bks; Mon, 10 Mar 2003 18:42:33 -0800 (PST) Received: from netscape.com (c3po.aoltw.net [64.236.137.25]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2B2gR313767 for ; Mon, 10 Mar 2003 18:42:27 -0800 (PST) Received: from dredd.mcom.com (dredd.nscp.aoltw.net [10.169.8.48]) by netscape.com (8.10.0/8.10.0) with ESMTP id h2B2ful06402 for ; Mon, 10 Mar 2003 18:41:59 -0800 (PST) Received: from netscape.com ([10.169.192.27]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HBKCT400.L42; Mon, 10 Mar 2003 18:41:28 -0800 Message-ID: <3E6D4C99.7060102@netscape.com> Date: Mon, 10 Mar 2003 19:40:25 -0700 From: richm@netscape.com (Rich Megginson) Organization: Netscape - Directory Server User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: John Merrells , ietf-ldup@imc.org Subject: Re: I-D ACTION:draft-ietf-ldup-lcup-04.txt References: <5.2.0.9.0.20030310135214.025ceb08@127.0.0.1> <5.2.0.9.0.20030310160606.025e40c0@127.0.0.1> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010907080100060004070205" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010907080100060004070205 Content-Type: multipart/alternative; boundary="------------030205070300030500030303" --------------030205070300030500030303 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: >At 03:14 PM 3/10/2003, John Merrells wrote: > > >>Kurt D. Zeilenga wrote: >> >> >>>Well, I thin that if we believe that certain implementation >>>approaches would lead to implementations which would do harm, >>>that we should state these beliefs and, where appropriate, >>>detail implementation-approach-neutral imperatives of what >>>behaviors are considered harmful. >>> >>> >>In other words you're suggesting that the specification document that implementors should implement the specification correctly. >> >> > >I'm suggesting the specification discuss areas where the >implementor should take care not to do harm. > > > >>>Lack of "eventual convergence data consistency" >>> >>> >>What does LCUP currently state? >> >> > >Presently, the I-D is a bit lacking in its data consistency >statements. It needs to be more explicit in stating that >servers are to either generate messages which will lead to >convergence or return an error. This, I think, can be resolved >by rewording portions of 3.3.7. > Reword to say what? Change the SHOULD in the first paragraph of 3.3.7 to a MUST? >>You're looking for a guarentee from LCUP that the client state be >>exactly the same as a server state at some point? >> >> > >I am looking for the LCUP to be designed to support content >synchronization with eventual convergent data consistency. > >I'm not yet convinced that LCUP provides this, hence this >dialog. > > > >>>and/or "overly chattiness" would be harmful. >>> >>> >>That's implementation defined. >> >> > >Chattiness should be defined in terms of the protocol >and the operations they perform. Not only should >protocols be designed to avoid overly chattiness, >where the protocol implementation allows for >chatty protocol exchanges, the specification should >discuss chattiness issues and state appropriate >imperatives. > >The LCUP I-D makes some statements in this area, I believe >more is necessary and will over specific suggestions >at a later date. > >Kurt > > > > --------------030205070300030500030303 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote:
At 03:14 PM 3/10/2003, John Merrells wrote:
  
Kurt D. Zeilenga wrote:
    
Well, I thin that if we believe that certain implementation
approaches would lead to implementations which would do harm,
that we should state these beliefs and, where appropriate,
detail implementation-approach-neutral imperatives of what
behaviors are considered harmful.  
      
In other words you're suggesting that the specification document that implementors should implement the specification correctly.
    

I'm suggesting the specification discuss areas where the
implementor should take care not to do harm.

  
Lack of "eventual convergence data consistency" 
      
What does LCUP currently state?
    

Presently, the I-D is a bit lacking in its data consistency
statements.  It needs to be more explicit in stating that
servers are to either generate messages which will lead to
convergence or return an error.  This, I think, can be resolved
by rewording portions of 3.3.7.
Reword to say what?  Change the SHOULD in the first paragraph of 3.3.7 to a MUST?
You're looking for a guarentee from LCUP that the client state be
exactly the same as a server state at some point?
    

I am looking for the LCUP to be designed to support content
synchronization with eventual convergent data consistency.

I'm not yet convinced that LCUP provides this, hence this
dialog.

  
and/or "overly chattiness" would be harmful.
      
That's implementation defined.
    

Chattiness should be defined in terms of the protocol
and the operations they perform.  Not only should
protocols be designed to avoid overly chattiness,
where the protocol implementation allows for
chatty protocol exchanges, the specification should
discuss chattiness issues and state appropriate
imperatives.

The LCUP I-D makes some statements in this area, I believe
more is necessary and will over specific suggestions
at a later date.

Kurt

--------------030205070300030500030303-- --------------ms010907080100060004070205 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK6TCC A4MwggLsoAMCAQICAmXjMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5l IEluYzEZMBcGA1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2Vy dGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAyMTEyNjE4MTQwOFoXDTAzMDUyNTE4MTQwOFowfTEL MAkGA1UEBhMCVVMxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEVMBMGCgmSJomT8ixk AQETBXJpY2htMSEwHwYJKoZIhvcNAQkBFhJyaWNobUBuZXRzY2FwZS5jb20xFzAVBgNVBAMT DlJpY2ggTWVnZ2luc29uMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCjtycvO35sPdLF Stqay5K2LMKyD7e51X7uhDLV+/3Hlg76kaZ54H/KBj32h7PCn3+QZZFOLdHN3aEBFm+xepBb 0XQ69ikarFc5z5ize/BgTJlNbo8go0PUPlHM40Q+Lwiq8psjaGZST7G+gE9NeObvJ4AGg3+l xnFOXzz331HNuQIDAQABo4H6MIH3MA4GA1UdDwEB/wQEAwIFIDAdBgNVHSUEFjAUBggrBgEF BQcDAgYIKwYBBQUHAwQwQwYJYIZIAYb4QgENBDYWNElzc3VlZCBieSBOZXRzY2FwZSBDZXJ0 aWZpY2F0ZSBNYW5hZ2VtZW50IFN5c3RlbSA0LjUwHQYDVR0RBBYwFIEScmljaG1AbmV0c2Nh cGUuY29tMB8GA1UdIwQYMBaAFCnbsi2Dfn+LI7vCzGa5Oegp8wKGMEEGCCsGAQUFBwEBBDUw MzAxBggrBgEFBQcwAYYlaHR0cDovL2NlcnRpZmljYXRlcy5uZXRzY2FwZS5jb20vb2NzcDAN BgkqhkiG9w0BAQUFAAOBgQCwXDFoep/l+//YCFgo2LSyTsPmP1cjsqCZ7gVG1HAequjZm0KK zBI55bWiEaK9Vd7InSHZdF/hj8ACZsfrWA8y1xSo8AuKBVkTp1Hh76zmQQitAGP1DxN85Sgm 86kBzcZbqMNW5aNkW5K4Izpb+6N0EhwGx6Uv5AXlEGtUkQroijCCA4QwggLtoAMCAQICAmXk MA0GCSqGSIb3DQEBBAUAMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAUBgNVBAcT DU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcGA1UECxMQ QU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUgQXV0aG9y aXR5MB4XDTAyMTEyNjE4MTQwOFoXDTAzMDUyNTE4MTQwOFowfTELMAkGA1UEBhMCVVMxGzAZ BgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEVMBMGCgmSJomT8ixkAQETBXJpY2htMSEwHwYJ KoZIhvcNAQkBFhJyaWNobUBuZXRzY2FwZS5jb20xFzAVBgNVBAMTDlJpY2ggTWVnZ2luc29u MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDFUh7DaFJ6LKg4po0qdNFKLPsbudM37rcQ AUU3YnD02FBbiRm1Jk/0duPoenqDZ/TZ9wexCkeK79DH4cw8VZhPqGoXFSsXv3OhTfgKNir6 VEVLJsHVhkm6bbiVOIn/nuYcC7brb/+wUiL0fJB07kFzuflsgek+0pJ2tcvXcwmiOQIDAQAB o4H7MIH4MA8GA1UdDwEB/wQFAwMHgAAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MEMGCWCGSAGG+EIBDQQ2FjRJc3N1ZWQgYnkgTmV0c2NhcGUgQ2VydGlmaWNhdGUgTWFuYWdl bWVudCBTeXN0ZW0gNC41MB0GA1UdEQQWMBSBEnJpY2htQG5ldHNjYXBlLmNvbTAfBgNVHSME GDAWgBQp27Itg35/iyO7wsxmuTnoKfMChjBBBggrBgEFBQcBAQQ1MDMwMQYIKwYBBQUHMAGG JWh0dHA6Ly9jZXJ0aWZpY2F0ZXMubmV0c2NhcGUuY29tL29jc3AwDQYJKoZIhvcNAQEEBQAD gYEAqAyCrRh04NLX4Away7B39CLi0RcCBk+2vQHhXjfDe8+rK0dBOJI712YZNpyodrVnVmjN 5prJVyq/j+nTT8HWst7hp4aSHebefoSGzz6ZhAxzpgzOuSvchYytj1PE39pSaVMp1X7za/Ki FpmEXDSQqND5mLjVpSUCA1LA9X2wmgswggPWMIIDP6ADAgECAgQCAAHmMA0GCSqGSIb3DQEB BQUAMEUxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9HVEUgQ29ycG9yYXRpb24xHDAaBgNVBAMT E0dURSBDeWJlclRydXN0IFJvb3QwHhcNMDEwNjAxMTI0NzAwWhcNMDQwNjAxMjM1OTAwWjCB kzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRsw GQYDVQQKExJBbWVyaWNhIE9ubGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMx JzAlBgNVBAMTHkludHJhbmV0IENlcnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0B AQEFAAOBjQAwgYkCgYEA4u9fLHZDiUsaX7Pl+Kpviy+BTWf/vUoPYy7E3IX2nixJJiD/ABfk iIhp3v2DV+CjERkRqtbcvO+z0hUuVMZufL/ZucNG0wkFhOVTXEjthIWaDjs9Fgdc8LN5q5oQ pbzBpNF4TAblZEH8BSVjJuvvDMduVKGMzlRXth+S2rISS40CAwEAAaOCAYIwggF+ME0GA1Ud HwRGMEQwQqBAoD6GPGh0dHA6Ly93d3cxLnVzLWhvc3RpbmcuYmFsdGltb3JlLmNvbS9jZ2kt YmluL0NSTC9HVEVSb290LmNnaTAdBgNVHQ4EFgQUKduyLYN+f4sju8LMZrk56CnzAoYwZgYD VR0gBF8wXTBGBgoqhkiG+GMBAgEFMDgwNgYIKwYBBQUHAgEWKmh0dHA6Ly93d3cuYmFsdGlt b3JlLmNvbS9DUFMvT21uaVJvb3QuaHRtbDATBgMqAwQwDDAKBggrBgEFBQcCATBYBgNVHSME UTBPoUmkRzBFMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPR1RFIENvcnBvcmF0aW9uMRwwGgYD VQQDExNHVEUgQ3liZXJUcnVzdCBSb290ggIBozArBgNVHRAEJDAigA8yMDAxMDYwMTEyNDcz MFqBDzIwMDMwOTAxMjM1OTAwWjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TBAgwBgEB/wIBATAN BgkqhkiG9w0BAQUFAAOBgQBKYg7Z+kZ3BApsDd3+0iI5mRAKrogthj1XhOYSJDdp+1le4hGw +Z+kV4aKaR8GY9F97jM2SRAgDx+XFywnbD1sOQR74kXohxtUtmBBbR2uBfOd+To0muN7a0xx +OuoK4OwNZBMGWhx7fBjIl7CW+wgerWwUXPpB+6BZ3Z5U/eV1DGCAqYwggKiAgEBMIGaMIGT MQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxGzAZ BgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcGA1UECxMQQU9MIFRlY2hub2xvZ2llczEn MCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AgJl5DAJBgUrDgMCGgUA oIIBYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMTEw MjQwMjVaMCMGCSqGSIb3DQEJBDEWBBRf+p3LMhxrSvimv0O3zk/LFNMp+jBSBgkqhkiG9w0B CQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDCBrQYLKoZIhvcNAQkQAgsxgZ2ggZowgZMxCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1l cmljYSBPbmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5J bnRyYW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCAmXjMA0GCSqGSIb3DQEBAQUABIGASzz/ lh7M7ICSmcfLAWZyEF5qfdSsbstCsboebPToY4d19N97f7h7QJrSGbMTD8HnGjTDIIaEPOKt F2RLxCkUEiFjzvK2OSHrHVEm6I8F1bMwvf+HiRz3QzLds/GXMLJ8mJaUH/VYNIDXcZUH28jl QRUdSnaJidaqzmNz/d/2RpAAAAAAAAA= --------------ms010907080100060004070205-- From owner-ietf-ldup@mail.imc.org Mon Mar 10 23:14:31 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26457 for ; Mon, 10 Mar 2003 23:14:30 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2B4DG116182 for ietf-ldup-bks; Mon, 10 Mar 2003 20:13:16 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2B4DE316176 for ; Mon, 10 Mar 2003 20:13:14 -0800 (PST) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h2B4DECa050917; Tue, 11 Mar 2003 04:13:15 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030310200106.0268f840@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 10 Mar 2003 20:11:27 -0800 To: richm@netscape.com (Rich Megginson) From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-ldup-lcup-04.txt Cc: John Merrells , ietf-ldup@imc.org In-Reply-To: <3E6D4C99.7060102@netscape.com> References: <5.2.0.9.0.20030310135214.025ceb08@127.0.0.1> <5.2.0.9.0.20030310160606.025e40c0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 06:40 PM 3/10/2003, Rich Megginson wrote: >>>>Lack of "eventual convergence data consistency" >>>What does LCUP currently state? >>Presently, the I-D is a bit lacking in its data consistency >>statements. It needs to be more explicit in stating that >>servers are to either generate messages which will lead to >>convergence or return an error. This, I think, can be resolved >>by rewording portions of 3.3.7. >Reword to say what? >Change the SHOULD in the first paragraph of 3.3.7 to a MUST? The first paragraph says what the server is to do if it detects an inconsistency. It does not require the server to implement any inconsistency detection. It's my opinion that the server should be REQUIRED to either produce a set of messages which cause convergence at conformant client or return an appropriate error. Kurt From owner-ietf-ldup@mail.imc.org Tue Mar 11 00:02:39 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27164 for ; Tue, 11 Mar 2003 00:02:39 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2B4wkK17490 for ietf-ldup-bks; Mon, 10 Mar 2003 20:58:46 -0800 (PST) Received: from triplerock.olsons.net (root@adsl-63-194-211-87.dsl.snfc21.pacbell.net [63.194.211.87]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2B4wj317485 for ; Mon, 10 Mar 2003 20:58:45 -0800 (PST) Received: from sleepycat.com (12-234-118-3.client.attbi.com [12.234.118.3]) (authenticated bits=0) by triplerock.olsons.net (8.12.8/8.12.8) with ESMTP id h2B4wU6F021262; Mon, 10 Mar 2003 20:58:30 -0800 (PST) (envelope-from merrells@sleepycat.com) Message-ID: <3E6D6D0E.7040601@sleepycat.com> Date: Mon, 10 Mar 2003 20:58:54 -0800 From: John Merrells User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: Jonghyuk Choi CC: Rich Megginson , "Kurt D. Zeilenga" , ietf-ldup@imc.org Subject: Re: I-D ACTION:draft-ietf-ldup-lcup-04.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jonghyuk Choi wrote: >Because the protocol does not explicitly exclude the so called 'no-history' >implementation, the server would have to return lcupReloadRequired >so often to achieve a reasonable degree of consistency. > Yep. >An optimization for this is that the client sends a lightweight >reload request to the server in response to lcupReloadRequired. >The server then sends the entries changed after the client cookie >as normal search entries and sends only DNs and UUIDs of unchanged >entries in order to reduce chattiness. The client can then consider >unarrived entries as deleted or scoped-out ones and delete them. > In this case the server is using some historical information to optimize the amount of information that needs to be sent back to the client. The more historical information stored the more you can optimize the amount of data that needs to be sent back. John From owner-ietf-ldup@mail.imc.org Tue Mar 11 00:08:40 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27338 for ; Tue, 11 Mar 2003 00:08:39 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2B55C717695 for ietf-ldup-bks; Mon, 10 Mar 2003 21:05:12 -0800 (PST) Received: from triplerock.olsons.net (root@adsl-63-194-211-87.dsl.snfc21.pacbell.net [63.194.211.87]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2B55B317691 for ; Mon, 10 Mar 2003 21:05:11 -0800 (PST) Received: from sleepycat.com (12-234-118-3.client.attbi.com [12.234.118.3]) (authenticated bits=0) by triplerock.olsons.net (8.12.8/8.12.8) with ESMTP id h2B54v6F027957; Mon, 10 Mar 2003 21:04:57 -0800 (PST) (envelope-from merrells@sleepycat.com) Message-ID: <3E6D6E91.60204@sleepycat.com> Date: Mon, 10 Mar 2003 21:05:21 -0800 From: John Merrells User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: John McMeeking , ietf-ldup@imc.org Subject: Re: I-D ACTION:draft-ietf-ldup-lcup-04.txt References: <5.2.0.9.0.20030310135214.025ceb08@127.0.0.1> <5.2.0.9.0.20030310160606.025e40c0@127.0.0.1> Content-Type: multipart/alternative; boundary="------------060600030003070206080906" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------060600030003070206080906 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: >>>and/or "overly chattiness" would be harmful. >>> >>That's implementation defined. >> > >Chattiness should be defined in terms of the protocol >and the operations they perform. Not only should >protocols be designed to avoid overly chattiness, >where the protocol implementation allows for >chatty protocol exchanges, the specification should >discuss chattiness issues and state appropriate >imperatives. > >The LCUP I-D makes some statements in this area, I believe >more is necessary and will over specific suggestions >at a later date. > Sure, add implementation advise, but you can't mandate against bad implementations. John --------------060600030003070206080906 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Kurt D. Zeilenga wrote:
and/or "overly chattiness" would be harmful.
That's implementation defined.

Chattiness should be defined in terms of the protocol
and the operations they perform.  Not only should
protocols be designed to avoid overly chattiness,
where the protocol implementation allows for
chatty protocol exchanges, the specification should
discuss chattiness issues and state appropriate
imperatives.

The LCUP I-D makes some statements in this area, I believe
more is necessary and will over specific suggestions
at a later date.
Sure, add implementation advise, but you can't mandate against
bad implementations.

John
--------------060600030003070206080906-- From owner-ietf-ldup@mail.imc.org Tue Mar 11 09:27:02 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20543 for ; Tue, 11 Mar 2003 09:27:01 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BEJp009258 for ietf-ldup-bks; Tue, 11 Mar 2003 06:19:51 -0800 (PST) Received: from netscape.com (c3po.aoltw.net [64.236.137.25]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BEJo309254 for ; Tue, 11 Mar 2003 06:19:50 -0800 (PST) Received: from dredd.mcom.com (dredd.nscp.aoltw.net [10.169.8.48]) by netscape.com (8.10.0/8.10.0) with ESMTP id h2BEJil17950 for ; Tue, 11 Mar 2003 06:19:44 -0800 (PST) Received: from netscape.com ([10.169.192.56]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HBL94500.GH2; Tue, 11 Mar 2003 06:19:17 -0800 Message-ID: <3E6DF026.8050502@netscape.com> Date: Tue, 11 Mar 2003 07:18:14 -0700 From: richm@netscape.com (Rich Megginson) Organization: Netscape - Directory Server User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-ldup@imc.org Subject: Re: I-D ACTION:draft-ietf-ldup-lcup-04.txt References: <5.2.0.9.0.20030310135214.025ceb08@127.0.0.1> <5.2.0.9.0.20030310160606.025e40c0@127.0.0.1> <5.2.0.9.0.20030310200106.0268f840@127.0.0.1> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030100030501000700000202" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030100030501000700000202 Content-Type: multipart/alternative; boundary="------------030304010109070604070205" --------------030304010109070604070205 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: >At 06:40 PM 3/10/2003, Rich Megginson wrote: > > >>>>>Lack of "eventual convergence data consistency" >>>>> >>>>> >>>>What does LCUP currently state? >>>> >>>> >>>Presently, the I-D is a bit lacking in its data consistency >>>statements. It needs to be more explicit in stating that >>>servers are to either generate messages which will lead to >>>convergence or return an error. This, I think, can be resolved >>>by rewording portions of 3.3.7. >>> >>> >>Reword to say what? >>Change the SHOULD in the first paragraph of 3.3.7 to a MUST? >> >> > >The first paragraph says what the server is to do if it detects >an inconsistency. It does not require the server to implement >any inconsistency detection. > >It's my opinion that the server should be REQUIRED to either >produce a set of messages which cause convergence at conformant >client or return an appropriate error. > >Kurt > > To summarize the discussion of the past two days - there are a couple of problems with the current LCUP 04 draft: 1) The draft has an implicit assumption that the server will store some historical change information in order to reduce the amount of data sent to the client during resync. This precludes server implementations that do not store any historical information. Such a server could simply use the createTimestamp or modifyTimestamp in conjunction with a cookie that simply has a timestamp as its value. This server could just return all entries whose createTimestamp and modifyTimestamp are greater than the timestamp in the cookie, and return only a DN or UUID for other entries within the search scope. The client would presume those entries have not changed. At the end of the sync session, the client would assume that entries that have not been received in full (changed entries) or entries for which a DN or UUID has not been received (unchanged entries) have been deleted or moved out of the search scope. I think the LCUP draft could be changed to allow this, but this would be an optional feature of the protocol. However, I would like to know of any existing or planned server implementation that does not store any historical information, either in a state or log based system. Could I see a "show of hands"? 2) The draft should state an absolute convergence requirement. That is, the server is REQUIRED to do one of the following: Produce a set of operations that will bring the client into complete synchronization with the server Tell the client that incremental synchronization is not possible and require the client to do a full resync I believe this could be easily done with some slight rewording of section 3.3.7 of the LCUP 04 draft. Are there any other problems? Come on, don't be shy. --------------030304010109070604070205 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote:
At 06:40 PM 3/10/2003, Rich Megginson wrote:
  
Lack of "eventual convergence data consistency"      
          
What does LCUP currently state?
        
Presently, the I-D is a bit lacking in its data consistency
statements.  It needs to be more explicit in stating that
servers are to either generate messages which will lead to
convergence or return an error.  This, I think, can be resolved
by rewording portions of 3.3.7.
      
Reword to say what?
Change the SHOULD in the first paragraph of 3.3.7 to a MUST?
    

The first paragraph says what the server is to do if it detects
an inconsistency.  It does not require the server to implement
any inconsistency detection.

It's my opinion that the server should be REQUIRED to either
produce a set of messages which cause convergence at conformant
client or return an appropriate error.

Kurt
To summarize the discussion of the past two days - there are a couple of problems with the current LCUP 04 draft:

1) The draft has an implicit assumption that the server will store some historical change information in order to reduce the amount of data sent to the client during resync.  This precludes server implementations that do not store any historical information.  Such a server could simply use the createTimestamp or modifyTimestamp in conjunction with a cookie that simply has a timestamp as its value.  This server could just return all entries whose createTimestamp and modifyTimestamp are greater than the timestamp in the cookie, and return only a DN or UUID for other entries within the search scope.  The client would presume those entries have not changed.  At the end of the sync session, the client would assume that entries that have not been received in full (changed entries) or entries for which a DN or UUID has not been received (unchanged entries) have been deleted or moved out of the search scope.

I think the LCUP draft could be changed to allow this, but this would be an optional feature of the protocol.

However, I would like to know of any existing or planned server implementation that does not store any historical information, either in a state or log based system.  Could I see a "show of hands"?

2) The draft should state an absolute convergence requirement.  That is, the server is REQUIRED to do one of the following:
Produce a set of operations that will bring the client into complete synchronization with the server
Tell the client that incremental synchronization is not possible and require the client to do a full resync

I believe this could be easily done with some slight rewording of section 3.3.7 of the LCUP 04 draft.



Are there any other problems?  Come on, don't be shy.

--------------030304010109070604070205-- --------------ms030100030501000700000202 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK6TCC A4MwggLsoAMCAQICAmXjMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5l IEluYzEZMBcGA1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2Vy dGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAyMTEyNjE4MTQwOFoXDTAzMDUyNTE4MTQwOFowfTEL MAkGA1UEBhMCVVMxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEVMBMGCgmSJomT8ixk AQETBXJpY2htMSEwHwYJKoZIhvcNAQkBFhJyaWNobUBuZXRzY2FwZS5jb20xFzAVBgNVBAMT DlJpY2ggTWVnZ2luc29uMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCjtycvO35sPdLF Stqay5K2LMKyD7e51X7uhDLV+/3Hlg76kaZ54H/KBj32h7PCn3+QZZFOLdHN3aEBFm+xepBb 0XQ69ikarFc5z5ize/BgTJlNbo8go0PUPlHM40Q+Lwiq8psjaGZST7G+gE9NeObvJ4AGg3+l xnFOXzz331HNuQIDAQABo4H6MIH3MA4GA1UdDwEB/wQEAwIFIDAdBgNVHSUEFjAUBggrBgEF BQcDAgYIKwYBBQUHAwQwQwYJYIZIAYb4QgENBDYWNElzc3VlZCBieSBOZXRzY2FwZSBDZXJ0 aWZpY2F0ZSBNYW5hZ2VtZW50IFN5c3RlbSA0LjUwHQYDVR0RBBYwFIEScmljaG1AbmV0c2Nh cGUuY29tMB8GA1UdIwQYMBaAFCnbsi2Dfn+LI7vCzGa5Oegp8wKGMEEGCCsGAQUFBwEBBDUw MzAxBggrBgEFBQcwAYYlaHR0cDovL2NlcnRpZmljYXRlcy5uZXRzY2FwZS5jb20vb2NzcDAN BgkqhkiG9w0BAQUFAAOBgQCwXDFoep/l+//YCFgo2LSyTsPmP1cjsqCZ7gVG1HAequjZm0KK zBI55bWiEaK9Vd7InSHZdF/hj8ACZsfrWA8y1xSo8AuKBVkTp1Hh76zmQQitAGP1DxN85Sgm 86kBzcZbqMNW5aNkW5K4Izpb+6N0EhwGx6Uv5AXlEGtUkQroijCCA4QwggLtoAMCAQICAmXk MA0GCSqGSIb3DQEBBAUAMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAUBgNVBAcT DU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcGA1UECxMQ QU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUgQXV0aG9y aXR5MB4XDTAyMTEyNjE4MTQwOFoXDTAzMDUyNTE4MTQwOFowfTELMAkGA1UEBhMCVVMxGzAZ BgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEVMBMGCgmSJomT8ixkAQETBXJpY2htMSEwHwYJ KoZIhvcNAQkBFhJyaWNobUBuZXRzY2FwZS5jb20xFzAVBgNVBAMTDlJpY2ggTWVnZ2luc29u MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDFUh7DaFJ6LKg4po0qdNFKLPsbudM37rcQ AUU3YnD02FBbiRm1Jk/0duPoenqDZ/TZ9wexCkeK79DH4cw8VZhPqGoXFSsXv3OhTfgKNir6 VEVLJsHVhkm6bbiVOIn/nuYcC7brb/+wUiL0fJB07kFzuflsgek+0pJ2tcvXcwmiOQIDAQAB o4H7MIH4MA8GA1UdDwEB/wQFAwMHgAAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MEMGCWCGSAGG+EIBDQQ2FjRJc3N1ZWQgYnkgTmV0c2NhcGUgQ2VydGlmaWNhdGUgTWFuYWdl bWVudCBTeXN0ZW0gNC41MB0GA1UdEQQWMBSBEnJpY2htQG5ldHNjYXBlLmNvbTAfBgNVHSME GDAWgBQp27Itg35/iyO7wsxmuTnoKfMChjBBBggrBgEFBQcBAQQ1MDMwMQYIKwYBBQUHMAGG JWh0dHA6Ly9jZXJ0aWZpY2F0ZXMubmV0c2NhcGUuY29tL29jc3AwDQYJKoZIhvcNAQEEBQAD gYEAqAyCrRh04NLX4Away7B39CLi0RcCBk+2vQHhXjfDe8+rK0dBOJI712YZNpyodrVnVmjN 5prJVyq/j+nTT8HWst7hp4aSHebefoSGzz6ZhAxzpgzOuSvchYytj1PE39pSaVMp1X7za/Ki FpmEXDSQqND5mLjVpSUCA1LA9X2wmgswggPWMIIDP6ADAgECAgQCAAHmMA0GCSqGSIb3DQEB BQUAMEUxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9HVEUgQ29ycG9yYXRpb24xHDAaBgNVBAMT E0dURSBDeWJlclRydXN0IFJvb3QwHhcNMDEwNjAxMTI0NzAwWhcNMDQwNjAxMjM1OTAwWjCB kzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRsw GQYDVQQKExJBbWVyaWNhIE9ubGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMx JzAlBgNVBAMTHkludHJhbmV0IENlcnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0B AQEFAAOBjQAwgYkCgYEA4u9fLHZDiUsaX7Pl+Kpviy+BTWf/vUoPYy7E3IX2nixJJiD/ABfk iIhp3v2DV+CjERkRqtbcvO+z0hUuVMZufL/ZucNG0wkFhOVTXEjthIWaDjs9Fgdc8LN5q5oQ pbzBpNF4TAblZEH8BSVjJuvvDMduVKGMzlRXth+S2rISS40CAwEAAaOCAYIwggF+ME0GA1Ud HwRGMEQwQqBAoD6GPGh0dHA6Ly93d3cxLnVzLWhvc3RpbmcuYmFsdGltb3JlLmNvbS9jZ2kt YmluL0NSTC9HVEVSb290LmNnaTAdBgNVHQ4EFgQUKduyLYN+f4sju8LMZrk56CnzAoYwZgYD VR0gBF8wXTBGBgoqhkiG+GMBAgEFMDgwNgYIKwYBBQUHAgEWKmh0dHA6Ly93d3cuYmFsdGlt b3JlLmNvbS9DUFMvT21uaVJvb3QuaHRtbDATBgMqAwQwDDAKBggrBgEFBQcCATBYBgNVHSME UTBPoUmkRzBFMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPR1RFIENvcnBvcmF0aW9uMRwwGgYD VQQDExNHVEUgQ3liZXJUcnVzdCBSb290ggIBozArBgNVHRAEJDAigA8yMDAxMDYwMTEyNDcz MFqBDzIwMDMwOTAxMjM1OTAwWjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TBAgwBgEB/wIBATAN BgkqhkiG9w0BAQUFAAOBgQBKYg7Z+kZ3BApsDd3+0iI5mRAKrogthj1XhOYSJDdp+1le4hGw +Z+kV4aKaR8GY9F97jM2SRAgDx+XFywnbD1sOQR74kXohxtUtmBBbR2uBfOd+To0muN7a0xx +OuoK4OwNZBMGWhx7fBjIl7CW+wgerWwUXPpB+6BZ3Z5U/eV1DGCAqYwggKiAgEBMIGaMIGT MQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxGzAZ BgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcGA1UECxMQQU9MIFRlY2hub2xvZ2llczEn MCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AgJl5DAJBgUrDgMCGgUA oIIBYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMTEx NDE4MTRaMCMGCSqGSIb3DQEJBDEWBBSv8EnayccVdvOsdvg+5aUNAgfnMDBSBgkqhkiG9w0B CQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDCBrQYLKoZIhvcNAQkQAgsxgZ2ggZowgZMxCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1l cmljYSBPbmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5J bnRyYW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCAmXjMA0GCSqGSIb3DQEBAQUABIGAknIL YqfDEaPx3uTOaOf0bdzj+MjtvjJlwVxxu82Ilsu5iUxR/ksqpCl4J3U2x8SDevmFpBp13n49 geLEP/ddBELYTkpiZZFAqEHWiUaL8vXDPwMAQGWMsF5eMWRSPg1T9YY/zbYBy60ZYkbNuhpB WiJjI6y1GuV2G/LUQ8I5nswAAAAAAAA= --------------ms030100030501000700000202-- From owner-ietf-ldup@mail.imc.org Tue Mar 11 09:34:58 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20667 for ; Tue, 11 Mar 2003 09:34:57 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BEVTE09954 for ietf-ldup-bks; Tue, 11 Mar 2003 06:31:29 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BEVS309950 for ; Tue, 11 Mar 2003 06:31:28 -0800 (PST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h2BESoW8090784; Tue, 11 Mar 2003 09:28:50 -0500 Received: from d01ml233.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h2BESm3f038396; Tue, 11 Mar 2003 09:28:49 -0500 Importance: Normal Subject: Re: I-D ACTION:draft-ietf-ldup-lcup-04.txt To: John Merrells Cc: Rich Megginson , "Kurt D. Zeilenga" , ietf-ldup@imc.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Jonghyuk Choi Date: Tue, 11 Mar 2003 09:28:47 -0500 X-MIMETrack: Serialize by Router on D01ML233/01/M/IBM(Release 6.0.1 [IBM]NP|March 10, 2003) at 03/11/2003 09:28:48 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >In this case the server is using some historical information to optimize the >amount of information that needs to be sent back to the client. The more >historical information stored the more you can optimize the amount of data >that needs to be sent back. No. Client cookie is not historical information. It's client state information. On the other hand, the maintained deleted entries are historical information to which the last sentence of the above holds. ------------------------ Jong Hyuk Choi IBM Thomas J. Watson Research Center - Enterprise Linux Group P. O. Box 218, Yorktown Heights, NY 10598 email: jongchoi@us.ibm.com (phone) 914-945-3979 (fax) 914-945-4425 TL: 862-3979 From owner-ietf-ldup@mail.imc.org Tue Mar 11 09:59:41 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21364 for ; Tue, 11 Mar 2003 09:59:40 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BEuEL10772 for ietf-ldup-bks; Tue, 11 Mar 2003 06:56:14 -0800 (PST) Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BEuD310767 for ; Tue, 11 Mar 2003 06:56:13 -0800 (PST) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h2BEu5R02633 for ; Tue, 11 Mar 2003 06:56:05 -0800 (PST) Received: from netscape.com ([10.178.168.17]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HBLATQ01.DSI; Tue, 11 Mar 2003 06:56:14 -0800 Message-ID: <3E6DF904.2020300@netscape.com> Date: Tue, 11 Mar 2003 09:56:04 -0500 From: mcs@netscape.com (Mark C Smith) Organization: Netscape Communications Corp. User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.3b) Gecko/20030211 X-Accept-Language: English/United States [en-US],English [en] MIME-Version: 1.0 To: John Merrells CC: Jonghyuk Choi , Rich Megginson , "Kurt D. Zeilenga" , ietf-ldup@imc.org Subject: Re: I-D ACTION:draft-ietf-ldup-lcup-04.txt References: <3E6D6D0E.7040601@sleepycat.com> In-Reply-To: <3E6D6D0E.7040601@sleepycat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Merrells wrote: > > In this case the server is using some historical information to optimize > the > amount of information that needs to be sent back to the client. The more > historical information stored the more you can optimize the amount of data > that needs to be sent back. Exactly. There is a big tradeoff here between complexity of implementation and the efficiency of the LCUP protocol exchange. It is important to allow implementors to have some flexibility while still assuring that the protocol works reliably. In many cases, efficiency tradeoffs can and should be left in the hands of the implementors. -Mark Smith Netscape From owner-ietf-ldup@mail.imc.org Tue Mar 11 10:18:44 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23264 for ; Tue, 11 Mar 2003 10:18:44 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BFDBF11487 for ietf-ldup-bks; Tue, 11 Mar 2003 07:13:11 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BFD9311483 for ; Tue, 11 Mar 2003 07:13:09 -0800 (PST) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h2BFD9Ca055039; Tue, 11 Mar 2003 15:13:09 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030311063806.09f70ec0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 11 Mar 2003 07:11:20 -0800 To: richm@netscape.com (Rich Megginson) From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-ldup-lcup-04.txt Cc: ietf-ldup@imc.org In-Reply-To: <3E6DF026.8050502@netscape.com> References: <5.2.0.9.0.20030310135214.025ceb08@127.0.0.1> <5.2.0.9.0.20030310160606.025e40c0@127.0.0.1> <5.2.0.9.0.20030310200106.0268f840@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 06:18 AM 3/11/2003, Rich Megginson wrote: >Kurt D. Zeilenga wrote: >> >>At 06:40 PM 3/10/2003, Rich Megginson wrote: >> >>>>>> >>>>>>Lack of "eventual convergence data consistency" >>>>>> >>>>> >>>>>What does LCUP currently state? >>>>> >>>> >>>>Presently, the I-D is a bit lacking in its data consistency >>>>statements. It needs to be more explicit in stating that >>>>servers are to either generate messages which will lead to >>>>convergence or return an error. This, I think, can be resolved >>>>by rewording portions of 3.3.7. >>>> >>> >>>Reword to say what? >>>Change the SHOULD in the first paragraph of 3.3.7 to a MUST? >>> >> >> >>The first paragraph says what the server is to do if it detects >>an inconsistency. It does not require the server to implement >>any inconsistency detection. >> >>It's my opinion that the server should be REQUIRED to either >>produce a set of messages which cause convergence at conformant >>client or return an appropriate error. >> >>Kurt >> >To summarize the discussion of the past two days - there are a couple of problems with the current LCUP 04 draft: > >1) The draft has an implicit assumption that the server will store some historical change information in order to reduce the amount of data sent to the client during resync. This precludes server implementations that do not store any historical information. Such a server could simply use the createTimestamp or modifyTimestamp (or entryCSN) >in conjunction with a cookie that simply has a timestamp as its value. This server could just return all entries whose createTimestamp and modifyTimestamp are greater than the timestamp in the cookie, and return only a DN or UUID for other entries within the search scope. The client would presume those entries have not changed. At the end of the sync session, the client would assume that entries that have not been received in full (changed entries) or entries for which a DN or UUID has not been received (unchanged entries) have been deleted or moved out of the search scope. >I think the LCUP draft could be changed to allow this, but this would be an optional feature of the protocol. I assume you mean optional to the server... >However, I would like to know of any existing or planned server implementation that does not store any historical information, either in a state or log based system. Could I see a "show of hands"? OpenLDAP has "early" no-history implementations of LCUP (circa -03) and LDAP-Sync presently available for experimentation. >2) The draft should state an absolute convergence requirement. That is, the server is REQUIRED to do one of the following: >Produce a set of operations that will bring the client into complete synchronization with the server >Tell the client that incremental synchronization is not possible and require the client to do a full resync > >I believe this could be easily done with some slight rewording of section 3.3.7 of the LCUP 04 draft. > >Are there any other problems? Come on, don't be shy. Many (mostly minor). When I first looked at -04, I found many of the same problems I found in -03 (and raised in my "laundry list" and/or the WG Last Call). I have not yet attempted to put an updated "laundry list" together for -04, I prefer to remain focused on a couple of critical issues. Kurt From owner-ietf-ldup@mail.imc.org Tue Mar 11 10:39:11 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24102 for ; Tue, 11 Mar 2003 10:39:11 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BFZiB12698 for ietf-ldup-bks; Tue, 11 Mar 2003 07:35:44 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BFZg312690 for ; Tue, 11 Mar 2003 07:35:43 -0800 (PST) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h2BFZgCa055263; Tue, 11 Mar 2003 15:35:42 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030311071211.02727f28@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 11 Mar 2003 07:33:54 -0800 To: mcs@netscape.com (Mark C Smith) From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-ldup-lcup-04.txt Cc: John Merrells , Jonghyuk Choi , Rich Megginson , ietf-ldup@imc.org In-Reply-To: <3E6DF904.2020300@netscape.com> References: <3E6D6D0E.7040601@sleepycat.com> <3E6D6D0E.7040601@sleepycat.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: At 06:56 AM 3/11/2003, Mark C Smith wrote: >John Merrells wrote: >>In this case the server is using some historical information to optimize the >>amount of information that needs to be sent back to the client. The more >>historical information stored the more you can optimize the amount of data >>that needs to be sent back. > >Exactly. There is a big tradeoff here between complexity of implementation and the efficiency of the LCUP protocol exchange. It is important to allow implementors to have some flexibility while still assuring that the protocol works reliably. In many cases, efficiency tradeoffs can and should be left in the hands of the implementors. I would agree that in many (if not most) cases, such tradeoffs can be and should be left in the hands of the implementors. However, where behaviors of one implementor is likely to cause harm to others (either its peer or to other components of the Internet), we need to place restrictions upon all implementor to prevent that harm from occurring. Kurt From owner-ietf-ldup@mail.imc.org Tue Mar 11 11:04:38 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24947 for ; Tue, 11 Mar 2003 11:04:38 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BG0vZ15679 for ietf-ldup-bks; Tue, 11 Mar 2003 08:00:57 -0800 (PST) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BG0s315669 for ; Tue, 11 Mar 2003 08:00:54 -0800 (PST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h2BG0glO183766; Tue, 11 Mar 2003 11:00:42 -0500 Received: from d01ml233.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h2BG0e3f150724; Tue, 11 Mar 2003 11:00:40 -0500 Importance: Normal Subject: Re: I-D ACTION:draft-ietf-ldup-lcup-04.txt To: mcs@netscape.com (Mark C Smith) Cc: John Merrells , Rich Megginson , "Kurt D. Zeilenga" , ietf-ldup@imc.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Jonghyuk Choi Date: Tue, 11 Mar 2003 11:00:39 -0500 X-MIMETrack: Serialize by Router on D01ML233/01/M/IBM(Release 6.0.1 [IBM]NP|March 10, 2003) at 03/11/2003 11:00:40 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: >Exactly. There is a big tradeoff here between complexity of >implementation and the efficiency of the LCUP protocol exchange. It is >important to allow implementors to have some flexibility while still >assuring that the protocol works reliably. In many cases, efficiency >tradeoffs can and should be left in the hands of the implementors. Yes. A protocol that exhibits refined complexity-efficiency characterics for wide range of scenarios would be considered thorough. Efficiency tradeoffs in the hands of the implementors are within the range that the protocol offers. > >-Mark Smith >Netscape From owner-ietf-ldup@mail.imc.org Thu Mar 13 10:58:40 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06619 for ; Thu, 13 Mar 2003 10:58:39 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2DFrCH20652 for ietf-ldup-bks; Thu, 13 Mar 2003 07:53:12 -0800 (PST) Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DFrB320647 for ; Thu, 13 Mar 2003 07:53:11 -0800 (PST) Received: from D7ST2111 (dpvc-141-152-21-16.rich.east.verizon.net [141.152.21.16]) by dns.caledonia.net; Thu, 13 Mar 2003 08:53:17 -0700 Reply-To: From: "Chris Apple" To: Cc: Subject: LDUP WG Meeting Agenda Date: Thu, 13 Mar 2003 10:52:31 -0500 Organization: DSI-Consulting, Inc. Message-ID: <004301c2e978$92c0a040$3400000a@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit LDUP WG Meeting Agenda 1. Consensus on a path to conclude. 2. Status of various documents. 3. WG Charter Revision/Review. 4. Next steps. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com From owner-ietf-ldup@mail.imc.org Thu Mar 13 15:26:22 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17770 for ; Thu, 13 Mar 2003 15:26:21 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2DKIfL05156 for ietf-ldup-bks; Thu, 13 Mar 2003 12:18:41 -0800 (PST) Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DKId305151 for ; Thu, 13 Mar 2003 12:18:39 -0800 (PST) Received: from D7ST2111 (dpvc-141-152-21-16.rich.east.verizon.net [141.152.21.16]) by dns.caledonia.net; Thu, 13 Mar 2003 13:17:44 -0700 Reply-To: From: "Chris Apple" To: Subject: RE: LDUP WG Meeting Agenda Date: Thu, 13 Mar 2003 15:17:05 -0500 Organization: DSI-Consulting, Inc. Message-ID: <000f01c2e99d$850faed0$3400000a@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <004301c2e978$92c0a040$3400000a@D7ST2111> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit A more specific agenda will follow before the meeting. As a minimum addition I will list all the recently republished and revised documents. I simply ran out of time due to other commitments in getting the official agenda submitted and sent in what I had time to create in a spare minute this morning. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] On Behalf Of Chris Apple Sent: Thursday, March 13, 2003 10:53 AM To: agenda@ietf.org Cc: ietf-ldup@imc.org Subject: LDUP WG Meeting Agenda LDUP WG Meeting Agenda 1. Consensus on a path to conclude. 2. Status of various documents. 3. WG Charter Revision/Review. 4. Next steps. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com From owner-ietf-ldup@mail.imc.org Thu Mar 13 15:27:29 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17826 for ; Thu, 13 Mar 2003 15:27:28 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2DKOXa05350 for ietf-ldup-bks; Thu, 13 Mar 2003 12:24:33 -0800 (PST) Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DKOQ305344 for ; Thu, 13 Mar 2003 12:24:28 -0800 (PST) Received: from D7ST2111 (dpvc-141-152-21-16.rich.east.verizon.net [141.152.21.16]) by dns.caledonia.net; Thu, 13 Mar 2003 13:23:58 -0700 Reply-To: From: "Chris Apple" To: Subject: Input for document status review Date: Thu, 13 Mar 2003 15:23:15 -0500 Organization: DSI-Consulting, Inc. Message-ID: <001001c2e99e$6397ea00$3400000a@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit If you are a document editor and cannot attend the San Francisco IETF LDUP WG Session to cover the status of your document, please send me input so that I can cover it for you. Plain text bullets in an e-mail are sufficient, but I won't say no to a few PowerPoint slides. Otherwise, please plan to spend a few minutes during the WG meeting discussing the status of your document in terms of outstanding issues that need to be resolved. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com From owner-ietf-ldup@mail.imc.org Tue Mar 18 06:56:01 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08243 for ; Tue, 18 Mar 2003 06:56:00 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2IBqx329294 for ietf-ldup-bks; Tue, 18 Mar 2003 03:52:59 -0800 (PST) Received: from marsha.smtp.stsn.com (p49.n-sfpop03.stsn.com [199.107.154.49]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2IBqsg29276 for ; Tue, 18 Mar 2003 03:52:57 -0800 (PST) Received: from D7ST2111 ([10.57.44.50]) by marsha.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 17 Mar 2003 03:55:49 -0800 Reply-To: From: "Chris Apple" To: Subject: Revised WG Charter Proposal Date: Tue, 18 Mar 2003 06:52:37 -0500 Organization: DSI-Consulting, Inc. Message-ID: <001201c2ed44$df5b8030$322c390a@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-OriginalArrivalTime: 17 Mar 2003 11:55:49.0296 (UTC) FILETIME=[26ECFB00:01C2EC7C] Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit LDAP Duplication/Replication/Update Protocols (ldup) Chair(s): Chris Apple John Strassner Applications Area Director(s): Ned Freed Patrik Faltstrom Applications Area Advisor: Patrik Faltstrom Mailing Lists: General Discussion: ietf-ldup@imc.org To Subscribe: ietf-ldup-request@imc.org In Body: subscribe Archive: http://www.imc.org/ietf-ldup/ Description of Working Group: As LDAPv3 becomes more widely deployed, replication of data across servers running different implementations becomes an important part of providing a distributed directory service. However, the LDAPv3 community, to date, has focused on standardizing the client-server access protocol. Therefore, this group will standardize master-slave and multi-master LDAPv3 replication as defined below: o Multi-Master Replication - A replication model where entries can be written and updated on any of several replica copies, without requiring communication with other masters before the write or update is performed. o Master-Slave, or Single-Master Replication - A replication model that assumes only one server, the master, allows write access to the replicated data. Note that Master-Slave replication can be considered a proper subset of multi-master replication. The WG's approach is to first develop a set of requirements for LDAPv3 directory replication and write an applicability statement defining scenarios on which replication requirements are based. An engineering team was formed consisting of different vendors and the co-chairs in order to harmonize the existing approaches into a single standard approach. All of these have been accomplished during the pre-working group stage. It should be noted, however, that replication using heterogeneous servers is dependent on resolving access control issues, which are the domain of other working groups. The new replication architecture support all forms of replication mentioned above. Seven areas of working group focus have been identified through LDUP Engineering Team discussions, each leading to one or more documents to be published: o LDAPv3 Replication Architecture This documents a general-purpose LDAPv3 replication architecture, defines key components of this architecture, describes how these key components functionally behave, and describes how these components interact with each other when in various modes of operation o LDAPv3 Replication Information Model Defines the schema and semantics of information used to operate, administer, maintain, and provision replication between LDAPv3 servers. Specifically, this document will contain common schema specifications intended to facilitate interoperable implementations with respect to: + replication agreements + consistency models + replication topologies + managing deleted objects and their states + administration and management o LDAPv3 Replication Information Transport Protocol LDAPv3 extended operation and control specifications required to allow LDAPv3 to be used as the transport protocol for information being replicated o LDAPv3 Mandatory Replica Management Specifications required to allow administration, maintenance, and provisioning of replicas and replication agreements. These specifications may take the form of definitions for LDAPv3 extended operations, controls, and/or new schema elements. o LDAPv3 Update Reconciliation Procedures Procedures for detection and resolution of conflicts between the state of multiple replicas that contain information from the same unit of replication. o LDAPv3 Profiles Including the LDAPv3 Replication Architecture, Information Model, Protocol Extensions, and Update Reconciliation Procedures for: + LDAPv3 Replication General Usage + LDAPv3 Single-Master Directory Replication + LDAPv3 Multi-Master Directory Replication o LDAPv3 Client Update A protocol that enables an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content. The work being done in the LDUP WG should be coordinated to the closest extent possible with similar work being done in the ITU. This is necessary both because LDAP depends on X.500 and because it makes sense from an operational perspective. Goals and Milestones: Done Submit I-D on LDAPv3 Directory Replication Requirements. Done Submit I-D on LDAPv3 Replication Information Model Done Submit I-D on LDAPv3 Update Reconciliation Procedures. Done Revise I-D on LDAPv3 Directory Replication Requirements. Done Revise I-D on LDAPv3 Replication Architecture. Done Revise I-D on LDAPv3 Replication Information Model. Done Submit I-D on LDAPv3 Replication Information Transport Protocol. Done Revise I-D on LDAPv3 Replication Architecture. Done LDAPv3 Directory Replication Requirements I-D goes to WG Last Call as Informational. Done Submit I-D on LDAPv3 Mandatory Replica Management. Done Submit I-D on LDAPv3 Replication General Usage Profile. MAY 03 Revise LDAPv3 Update Reconciliation Procedures I-D. MAY 03 Revise LDAPv3 Replication Information Model I-D. MAY 03 Revise LDAPv3 Replication Architecture I-D. MAY 03 Revise LDAPv3 Client Update Protocol I-D. MAY 03 Revise LDAPv3 Replication Information Transport Protocol I-D. MAY 03 LDAPv3 Extended Operations for Framing I-D goes to WG Last Call as Proposed Standard. MAY 03 Revise LDAPv3 Mandatory Replica Management I-D. JUN 03 Revise LDAPv3 Replication General Usage Profile I-D. JUN 03 Submit I-D on LDAPv3 Single-Master Directory Replication Profile. JUN 03 Submit I-D on LDAPv3 Multi-Master Directory Replication Profile. JUN 03 Poll the mailing list to request that issues be raised on all I-Ds. JUL 03 Revise any I-Ds as required according to consensus of issue resolution on the mailing list. AUG 03 Consider which documents are ready for WG Last Call and establish sequencing. SEP 03 Reevaluate Charter and Milestones Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com From owner-ietf-ldup@mail.imc.org Tue Mar 18 07:08:10 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08611 for ; Tue, 18 Mar 2003 07:08:10 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2IC3L301010 for ietf-ldup-bks; Tue, 18 Mar 2003 04:03:21 -0800 (PST) Received: from marsha.smtp.stsn.com (p49.n-sfpop03.stsn.com [199.107.154.49]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2IC3Lg01006 for ; Tue, 18 Mar 2003 04:03:21 -0800 (PST) Received: from D7ST2111 ([10.57.44.50]) by marsha.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 17 Mar 2003 04:06:16 -0800 Reply-To: From: "Chris Apple" To: Subject: More Detailed WG Agenda Date: Tue, 18 Mar 2003 07:03:05 -0500 Organization: DSI-Consulting, Inc. Message-ID: <001301c2ed46$552532b0$322c390a@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-OriginalArrivalTime: 17 Mar 2003 12:06:16.0515 (UTC) FILETIME=[9CC70130:01C2EC7D] Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit LDAP Duplication/Replication/Update Protocols WG (ldup) Tuesday, March 18 at 1300-1400 =============================== CHAIRS: Chris Apple John Strassner AGENDA: 1. Consensus on a path to conclude. 2. Status of various documents. LDAP Client Update Protocol http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-04.txt LDUP Update Reconciliation Procedures http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-07.txt LDAP Replication Architecture http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-08.txt LDUP Replication Information Model http://www.ietf.org/internet-drafts/draft-ietf-ldup-infomod-06.txt The LDUP Replication Update Protocol http://www.ietf.org/internet-drafts/draft-ietf-ldup-protocol-04.txt General Usage Profile for LDAPv3 Replication http://www.ietf.org/internet-drafts/draft-ietf-ldup-usage-profile-04.txt Mandatory LDAP Replica Management http://www.ietf.org/internet-drafts/draft-ietf-ldup-mrm-02.txt 3. WG Charter Revision/Review. 4. Next steps. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com From owner-ietf-ldup@mail.imc.org Tue Mar 18 09:19:28 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11251 for ; Tue, 18 Mar 2003 09:19:27 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2IEGnU11774 for ietf-ldup-bks; Tue, 18 Mar 2003 06:16:49 -0800 (PST) Received: from netscape.com (c3po.aoltw.net [64.236.137.25]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2IEGmg11768 for ; Tue, 18 Mar 2003 06:16:48 -0800 (PST) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h2IEGhm17665 for ; Tue, 18 Mar 2003 06:16:43 -0800 (PST) Received: from netscape.com ([10.169.192.16]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HBY7NV00.XP0; Tue, 18 Mar 2003 06:16:43 -0800 Message-ID: <3E772A4B.8040205@netscape.com> Date: Tue, 18 Mar 2003 09:16:43 -0500 From: mcs@netscape.com (Mark C Smith) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: capple@dsi-consulting.net CC: ietf-ldup@imc.org Subject: Re: Revised WG Charter Proposal References: <001201c2ed44$df5b8030$322c390a@D7ST2111> In-Reply-To: <001201c2ed44$df5b8030$322c390a@D7ST2111> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Chris Apple wrote: > > MAY 03 Revise LDAPv3 Client Update Protocol I-D. Since LCUP has already been through one WG last call, I would expect it to be ready for another one, followed by submission to the IESG in the May or June 2003 timeframe. LCUP has no dependencies on the core LDUP replication documents. > SEP 03 Reevaluate Charter and Milestones Are the area directors going to be happy with this? I don't see any date on the proposed charter for when a document leaves the working group, which seems strange to me. -- Mark Smith Netscape Directory Product Development My words are my own, not my employer's. From owner-ietf-ldup@mail.imc.org Tue Mar 18 19:53:48 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09508 for ; Tue, 18 Mar 2003 19:53:48 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2J0nA418295 for ietf-ldup-bks; Tue, 18 Mar 2003 16:49:10 -0800 (PST) Received: from marsha.smtp.stsn.com (p49.n-sfpop03.stsn.com [199.107.154.49]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2J0n9g18291 for ; Tue, 18 Mar 2003 16:49:09 -0800 (PST) Received: from D7ST2111 ([10.57.45.8]) by marsha.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 17 Mar 2003 16:52:07 -0800 Reply-To: From: "Chris Apple" To: Subject: RE: Revised WG Charter Proposal Date: Tue, 18 Mar 2003 19:49:00 -0500 Organization: DSI-Consulting, Inc. Message-ID: <000001c2edb1$550b1860$082d390a@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <3E772A4B.8040205@netscape.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 18 Mar 2003 00:52:07.0781 (UTC) FILETIME=[99DDC150:01C2ECE8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h2J0n9g18292 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit It was my intent to be fuzzy about the end game milestones. This milestone is where documents would leave the WG (after they pass through a last call successfully). >AUG 03 Consider which documents are ready for WG Last Call and establish sequencing. You are correct about the additional WG Last Call for LCUP. An error that I will correct with the next revision of the WG Charter Proposal. My intent behind the SEP 03 milestone is that it's a drop dead date. If all of the documents are not at least ready to enter WG Last Call by this date, we will have missed the schedule by too much to justify continuing and "the plug will be pulled." I expect that we will have a number of documents that have Actually passed WG Last Call before then. However, given the WG's history, I think its prudent to have a drop dead date in mind. We may change the wording of the milestone so that this intent is more clear. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] On Behalf Of Mark C Smith Sent: Tuesday, March 18, 2003 9:17 AM To: capple@dsi-consulting.net Cc: ietf-ldup@imc.org Subject: Re: Revised WG Charter Proposal Chris Apple wrote: > > MAY 03 Revise LDAPv3 Client Update Protocol I-D. Since LCUP has already been through one WG last call, I would expect it to be ready for another one, followed by submission to the IESG in the May or June 2003 timeframe. LCUP has no dependencies on the core LDUP replication documents. > SEP 03 Reevaluate Charter and Milestones Are the area directors going to be happy with this? I don't see any date on the proposed charter for when a document leaves the working group, which seems strange to me. -- Mark Smith Netscape Directory Product Development My words are my own, not my employer's. From owner-ietf-ldup@mail.imc.org Tue Mar 18 19:54:05 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09522 for ; Tue, 18 Mar 2003 19:54:04 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2J0nKX18309 for ietf-ldup-bks; Tue, 18 Mar 2003 16:49:20 -0800 (PST) Received: from marsha.smtp.stsn.com (p49.n-sfpop03.stsn.com [199.107.154.49]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2J0nIg18303 for ; Tue, 18 Mar 2003 16:49:18 -0800 (PST) Received: from D7ST2111 ([10.57.45.8]) by marsha.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 17 Mar 2003 16:52:11 -0800 Reply-To: From: "Chris Apple" To: Cc: , "John Strassner" Subject: LDUP WG Presentations Date: Tue, 18 Mar 2003 19:49:00 -0500 Organization: DSI-Consulting, Inc. Message-ID: <000901c2edb1$5a17d1e0$082d390a@D7ST2111> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000A_01C2ED87.7141C9E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 18 Mar 2003 00:52:16.0328 (UTC) FILETIME=[9EF5EC80:01C2ECE8] 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_000A_01C2ED87.7141C9E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Two MS PowerPoint files from the WG Meeting at IETF-56 are attached. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com ------=_NextPart_000_000A_01C2ED87.7141C9E0 Content-Type: application/vnd.ms-powerpoint; name="Selected LDUP Documents Status.ppt" Content-Disposition: attachment; filename="Selected LDUP Documents Status.ppt" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAGQAAAAAAAAAA EAAAGwAAAAEAAAD+////AAAAABoAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////9 ////GAAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8A AAAQAAAAEQAAAP7////+////FAAAABUAAAAWAAAAFwAAAP7////+//////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////////1IA bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAWAAUA//////////8BAAAAEI2BZJtPzxGG6gCqALkp6AAAAAAAAAAAAAAAAHB2CX9I7cIB EwAAAAAJAAAAAAAAUABvAHcAZQByAFAAbwBpAG4AdAAgAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACgAAgECAAAAAwAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAACAAAAQh8AAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0 AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQQAAAD//////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADMBQAAAAAAAAUARABvAGMAdQBtAGUAbgB0 AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB//////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAAFQCAAAAAAAADwDo A2YKAAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAAFAAAACgAAAAAAAAAAAAAAAQAAAAAAAAEPAPID FAEAAC8AyA8MAAAAMADSDwQAAAABAAAADwDVB0wAAAAAALcPRAAAAEEAcgBpAGEAbAAAAAgAAAAA AAAAqLkTAKi5EwB8fKQAKLgTABC4EwCh0AcwCAAAAAAAAAAouBMAOkEJMCC4EwAAAAYiAACkDwgA AACAAEAAAAD//wAApQ8MAAAAAAAACC4AAAAHAAAAAACpDwoAAAAHAAAAAgAJBAAAQACjD24AAAAF AP/9PwAAACIgAABkAAAAAP8AAGQAAAAAAAAAAABAAgAAAAAHAAAA///vAAAAAAD///////8SAAAA AAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAA8ACwSg AAAADwAA8JgAAAAAAAbwQAAAAAQYAAAHAAAAFQAAAAYAAAABAAAABwAAAAIAAAAEAAAAAwAAAAQA AAAEAAAABAAAAAUAAAAEAAAABgAAAAQAAACDAAvwMAAAAIEBBAAACIMBAAAACIZBAAAAAL8BEAAQ AMABAQAACMVBAAAAAP8BCAAIAAECAgAACEAAHvEQAAAABAAACAEAAAgCAAAI9wAAEB8A8A8cAAAA AADzAxQAAAACAAAAAAAAAAAAAAAAAACAAAAAAA8A0AczAQAAHwAUBBwAAAAAABUEFAAAALqTsPYA ypo7rQeUxwDKmjsBAQAADwD6A2cAAAAAAP4DAwAAAAABAAAA/QM0AAAAUQAAAGQAAABRAAAAZAAA AAgAAAAAAAAAQLgTADpBCTAAAAAAAAAAAKb///+8+///AQATAHAA+wMIAAAAAAAAAHAIAABwAPsD CAAAAAEAAABACwAAHwATBDwAAAAAAP0DNAAAAGQAAABkAAAAZAAAAGQAAABsuBMA6iQJMKi5EwBU fKQAAAAAAAAAAAAAAAAAAAAAAAABEwAfAP8DFAAAAAIAAAQMAAAAAAAAAAAAAAACAAAADwCIEzgA AAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAAANBAgAAAAAwAAAAMAA AA8A8A8DBwAAAADzAxQAAAADAAAAAAAAAAIAAAAAAQAAAAAAAAAAnw8EAAAABgAAAAAAqA8eAAAA U2VsZWN0ZWQgTERVUCBEb2N1bWVudHMgU3RhdHVzEACfDwQAAAAFAAAAAACoDxcAAABJRVRGLTU2 DQ1NYXJjaCAxOCwgMjAwMwAA8wMUAAAABAAAAAAAAAACAAAAAQEAAAAAAAAAAJ8PBAAAAAAAAAAA AKgPHgAAAFJlcGxpY2F0aW9uIFRyYW5zcG9ydCBQcm90b2NvbBAAnw8EAAAAAQAAAAAAqA9UAQAA SW4gZ29vZCBzaGFwZSBmb3IgcHVycG9zZXMgb2Ygd3JhcHBpbmcgdXAgTERVUCBhcyBhIHNldCBv ZiBleHBlcmltZW50YWwgZHJhZnRzLg1ObyBzaWduaWZpY2FudCB1bnJlc29sdmVkIGlzc3VlcyBm b3IgdGhpcyBkb2N1bWVudCBhcmUgYmVsaWV2ZWQgdG8gZXhpc3QuDURvY3VtZW50IEVkaXRvciBz dGlsbCBuZWVkcyB0byBjb21wbGV0ZSBzZWFyY2ggb2YgdGhlIG1haWxpbmcgbGlzdCBhcmNoaXZl cyB0byBiZSBzdXJlLg1DaGFuZ2VzIHRvIG90aGVyIGRvY3MgKGZvciB0aGluZ3MgbGlrZSBvdmVy bGFwcGluZyBhcmVhcyBvZiByZXBsaWNhdGlvbikgbWF5IGFmZmVjdCB0aGlzIGRvY3VtZW50LgAA oQ8UAAAAVQEAAAAAAAAAAFUBAAAAAAIAHAAAAPMDFAAAAAUAAAAAAAAAAgAAAAIBAAAAAAAAAACf DwQAAAAAAAAAAACoDxEAAABJbmZvcm1hdGlvbiBNb2RlbBAAnw8EAAAAAQAAAAAAoA90AQAAVQBw AGQAYQB0AGUAZAAgAGQAcgBhAGYAdAAgAG0AaQBkACAAdABvACAAbABhAHQAZQAgAEEAcAByAGkA bAAuAA0ASQBmACAAdwBlAGwAbAAgAHIAZQBjAGUAaQB2AGUAZAAsACAAaQB0ACAAYwBhAG4AIABn AG8AIAB0AG8AIABXAEcAIABMAGEAcwB0ACAAQwBhAGwAbAAgAHMAbwBvAG4ALgANAEIAZQBjAGEA dQBzAGUAIABtAGEAbgB5ACAAbwB0AGgAZQByACAAZABvAGMAdQBtAGUAbgB0AHMAIABkAGUAcABl AG4AZAAgAG8AbgAgAGkAdAAsACAAaQB0ABkgcwAgAHIAZQB2AGkAZQB3ACAAcwBoAG8AdQBsAGQA IABiAGUAIAB0AGgAZQAgAGkAbgBpAHQAaQBhAGwAIABmAG8AYwB1AHMAIABvAGYAIAB0AGgAZQAg AHcAcgBhAHAAIAB1AHAAIAB3AG8AcgBrAC4AAADzAxQAAAAGAAAAAAAAAAIAAAADAQAAAAAAAAAA nw8EAAAAAAAAAAAAqA8cAAAATWFuZGF0b3J5IFJlcGxpY2EgTWFuYWdlbWVudAAAoQ8UAAAAHQAA AAAAAAAAAB0AAAAAAAIAKAAQAJ8PBAAAAAEAAAAAAKgPawAAAERlcGVuZGVudCBvbiB0aGUgSW5m b3JtYXRpb24gTW9kZWwNV2UnbGwgbmVlZCB0aGUgdXBkYXRlcyB0byBJbmZvIE1vZCBiZWZvcmUg YW4gdXBkYXRlIGRyYWZ0IGNhbiBiZSB3cml0dGVuAADzAxQAAAAHAAAAAAAAAAIAAAAEAQAAAAAA AAAAnw8EAAAAAAAAAAAAqA8OAAAAVXNhZ2UgUHJvZmlsZXMQAJ8PBAAAAAEAAAAAAKgPmgEAAFRo ZXNlIHdpbGwgYmUgdXBkYXRlZC9jcmVhdGVkIGxhc3QgYXMgdGhleSBkZXBlbmQgb24gYWxsIG90 aGVyIGRvY3VtZW50cy4NTERBUHYzIFJlcGxpY2F0aW9uIEdlbmVyYWwgVXNhZ2UgUHJvZmlsZSBh dmFpbGFibGUgZm9yIGNvbW1lbnQuDVNpbmdsZS1NYXN0ZXIgYW5kIE11bHRpLU1hc3RlciBQcm9m aWxlcyBTdGlsbCBuZWVkIHRvIGhhdmUgdGhlIGluaXRpYWwgdmVyc2lvbiBjcmVhdGVkLg1HaXZl biB0aGUgY29uc2Vuc3VzIG9uIGNvbmNsdWRpbmcgdGhlIFdHIHdlIG5lZWQgdG8gcmVldmFsdWF0 ZSB3aGV0aGVyIHRoZSBnZW5lcmFsIHByb2ZpbGUgaXMgc3VmZmljaWVudCBvciBpZiB3ZSBzdGls bCBuZWVkIHRvIHB1Ymxpc2ggc2luZ2xlLW1hc3RlciBhbmQgbXVsdGktbWFzdGVyIHByb2ZpbGVz IGFzIHdlbGwuAAChDxQAAACbAQAAAAAAAAAAmwEAAAAAAgAcAAAA6gMAAAAADwD4A6QJAAACAO8D GAAAAAEAAAABAgcJCAAAAAAAAAAAAAAAAAATAGAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAz M5kAAJmZAJnMAABgAPAHIAAAAP///wAAAAAAlpaWAAAAAAD731MA/5lmAMwzAACZZgAAYADwByAA AAD///8AAAAAAICAgAAAAAAAmcz/AMzM/wAzM8wAr2f/AGAA8AcgAAAA3vbxAAAAAACWlpYAAAAA AP///wCNxv8AAGbMAACoAABgAPAHIAAAAP//2QAAAAAAd3d3AAAAAAD///cAM8zMAP9QUAD/mQAA YADwByAAAAAAgIAA////AABaWAD//5kAAGRiAG1vxwAA//8AAP8AAGAA8AcgAAAAgAAAAP///wBc HwAA39KTAMwzAAC+eWAA//+ZANOiGQBgAPAHIAAAAAAAmQD///8AADNmAMz//wAzZswAALAAAGbM /wD/5wEAYADwByAAAAAAAAAA////ADNmmQDj6/EAADOZAEaKSwBmzP8A8OUAAGAA8AcgAAAAaGtd AP///wB3d3cA0dHLAJCQggCAnqgA/8xmAOncuQBgAPAHIAAAAGZmmQD///8APj5cAP///wBgWXsA Zmb/AJnM/wD//5kAYADwByAAAABSPiYA////AC0gFQDfwI0AjHtwAI9fLwDMtAAAjJ6gAAAAow8+ AAAAAQD//T8AAAAiIAAAZAAAAAD/AQBkAAAAAAAAAAAAQAIAAAAABwAAAP//7wAAAAAA//////// LAAAAAADAAAQAKMPfAAAAAUA//0/AAEAIiAAAGQAAAAA/wAAZAAUAAAA2AAAAEACAAAAAAcAAAD/ /+8AAAAAAP///////yAAAAAAAQAAgAUAABMg1AEgAQAAAgAcAIAFAAAiINACQAIAAAIAGACABQAA EyDwA2ADAAACABQAgAUAALsAEAWABAAAAAAgAKMPbgAAAAUA//0/AAAAIiAAAGQAAAAA/wAAZAAe AAAAAAAAAEACAAAAAAcAAAD//+8AAAAAAP///////wwAAAAAAQAAAAUAACABIAEAAAAAAAUAAEAC QAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAAUACjD1IAAAAFAAAAAQkAAAAAAQAAAAAAAAAB AAEJAAAAAAEAIAEAAAAAAgABCQAAAAABAEACAAAAAAMAAQkAAAAAAQBgAwAAAAAEAAEJAAAAAAEA gAQAAAAAYACjDwwAAAABAAAAAAAAAAAAAABwAKMPPgAAAAUAAAAAAAAAAAACABwAAQAAAAAAAAAC ABgAAgAAAAAAAAACABQAAwAAAAAAAAACABIABAAAAAAAAAACABIAgACjDz4AAAAFAAAAAAAAAAAA AgAYAAEAAAAAAAAAAgAUAAIAAAAAAAAAAgASAAMAAAAAAAAAAgAQAAQAAAAAAAAAAgAQAA8ADATW BAAADwAC8M4EAAAQAAjwCAAAAAYAAAAGBAAADwAD8GYEAAAPAATwKAAAAAEACfAQAAAAAAAAAAAA AAAAAAAAAAAAAAIACvAIAAAAAAQAAAUAAAAPAATw0gAAABIACvAIAAAAAgQAAAAKAACTAAvwNgAA AH8AAQAFAIAAgLSkAIcAAQAAAIEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAA EPAIAAAArQAgAWAVfQMPABHwEAAAAAAAwwsIAAAAAAAAAAEApAAPAA3wVAAAAAAAnw8EAAAAAAAA AAAAqA8gAAAAQ2xpY2sgdG8gZWRpdCBNYXN0ZXIgdGl0bGUgc3R5bGUAAKIPBgAAACEAAAAAAAAA qg8KAAAAIQAAAAEAAAAAAA8ABPAWAQAAEgAK8AgAAAADBAAAAAoAAIMAC/AwAAAAfwABAAUAgAAs 3qQAgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAADwAyABYBUTDw8A EfAQAAAAAADDCwgAAAABAAAAAgCkAA8ADfCeAAAAAACfDwQAAAABAAAAAACoD1IAAABDbGljayB0 byBlZGl0IE1hc3RlciB0ZXh0IHN0eWxlcw1TZWNvbmQgbGV2ZWwNVGhpcmQgbGV2ZWwNRm91cnRo IGxldmVsDUZpZnRoIGxldmVsAACiDx4AAAAhAAAAAAANAAAAAQAMAAAAAgANAAAAAwAMAAAABAAA AKoPCgAAAFMAAAABAAAAAAAPAATwtgAAABIACvAIAAAABAQAAAAKAACDAAvwMAAAAH8AAQAFAIAA zN2kAIEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAAEPAIAAAAXg8gAWAGihAP ABHwEAAAAAAAwwsIAAAAAgAAAAcBpAAPAA3wPgAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEP FAAAAAIAAAAAAAAAAAACAAAAAAACAA4AAAD4DwQAAAAAAAAADwAE8LgAAAASAArwCAAAAAUEAAAA CgAAgwAL8DAAAAB/AAEABQCAAIzvpACBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIA AAgAABDwCAAAAF4PsAfQDooQDwAR8BAAAAAAAMMLCAAAAAMAAAAJAqQADwAN8EAAAAAAAJ8PBAAA AAQAAAAAAKAPAgAAACoAAAChDxYAAAACAAAAAAAACAAAAQACAAAAAAACAA4AAAD6DwQAAAAAAAAA DwAE8LgAAAASAArwCAAAAAYEAAAACgAAgwAL8DAAAAB/AAEABQCAACz2pACBAQQAAAiDAQAAAAi/ AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAF4PIBBgFYoQDwAR8BAAAAAAAMMLCAAAAAQA AAAIAqQADwAN8EAAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxYAAAACAAAAAAAACAAAAgAC AAAAAAACAA4AAADYDwQAAAAAAAAADwAE8EgAAAASAArwCAAAAAEEAAAADAAAgwAL8DAAAACBAQAA AAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAA AAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIEzgAAAAPAIoTMAAAAAAAug8QAAAAXwBfAF8A UABQAFQAMQAwAAAAixMQAAAAAADrLggAAABG7cIBgNyF/CAAug8cAAAARABlAGYAYQB1AGwAdAAg AEQAZQBzAGkAZwBuAA8A7gMkAgAAAgDvAxgAAAAAAAAADxAAAAAAAAAAAACAAAAAAAcAEwAPAAwE lAEAAA8AAvCMAQAAIAAI8AgAAAADAAAAAwgAAA8AA/AkAQAADwAE8CgAAAABAAnwEAAAAAAAAAAA AAAAAAAAAAAAAAACAArwCAAAAAAIAAAFAAAADwAE8HIAAAASAArwCAAAAAIIAAAgAgAAUwAL8B4A AAB/AAAABACAAAT/pAC/AQAAAQD/AQAAAQABAwIEAAAAABDwCAAAAD4FsAHQFNwIDwAR8BAAAAAA AMMLCAAAAAAAAAAPAKQADwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAAABIACvAIAAAAAwgAACAC AABTAAvwHgAAAH8AAAAEAIAA/AK4Ar8BAAABAP8BAAABAAEDAwQAAAAAEPAIAAAAkAlgAyAT4A0P ABHwEAAAAAAAwwsIAAAAAQAAABAAuAIPAA3wDAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgA AAABCAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJ AAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBM4AAAA DwCKEzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAA6y4IAAAARu3CAYDchfwP AO4DJAIAAAIA7wMYAAAAAQAAAA0OAAAAAAAAAAAAgAAAAAAHABMADwAMBJQBAAAPAALwjAEAADAA CPAIAAAAAwAAAAMMAAAPAAPwJAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK 8AgAAAAADAAABQAAAA8ABPByAAAAEgAK8AgAAAACDAAAIAIAAFMAC/AeAAAAfwAAAAQAgADkd7gC vwEAAAEA/wEAAAEAAQMCBAAAAAAQ8AgAAACtACABYBV9Aw8AEfAQAAAAAADDCwgAAAAAAAAADQC4 Ag8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HIAAAASAArwCAAAAAMMAAAgAgAAUwAL8B4AAAB/AAAA BACAABjFuAK/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAPADIAFgFRMPDwAR8BAAAAAAAMMLCAAA AAEAAAAOALgCDwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAAABIACvAIAAAAAQwAAAAMAACDAAvw MAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8Acg AAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTOAAAAA8AihMwAAAAAAC6DxAA AABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAAOsuCAAAAEftwgHgO+wcDwDuAyQCAAACAO8DGAAA AAEAAAANDgAAAAAAAAAAAIAAAAAABwATAA8ADASUAQAADwAC8IwBAABAAAjwCAAAAAMAAAADEAAA DwAD8CQBAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAABAAAAUAAAAP AATwcgAAABIACvAIAAAAAhAAACACAABTAAvwHgAAAH8AAAAEAIAATDm4Ar8BAAABAP8BAAABAAED AgQAAAAAEPAIAAAArQAgAWAVfQMPABHwEAAAAAAAwwsIAAAAAAAAAA0AuAIPAA3wDAAAAAAAng8E AAAAAAAAAA8ABPByAAAAEgAK8AgAAAADEAAAIAIAAFMAC/AeAAAAfwAAAAQAgABA6bgCvwEAAAEA /wEAAAEAAQMDBAAAAAAQ8AgAAADwAyABYBUTDw8AEfAQAAAAAADDCwgAAAABAAAADgC4Ag8ADfAM AAAAAACeDwQAAAABAAAADwAE8EgAAAASAArwCAAAAAEQAAAADAAAgwAL8DAAAACBAQAAAAiDAQUA AAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICA AAAAAAC74OMAMzOZAACZmQCZzAAADwCIEzgAAAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQA MQAwAAAAixMQAAAAAADrLggAAABH7cIBQEzjaQ8A7gMkAgAAAgDvAxgAAAABAAAADQ4AAAAAAAAA AACAAAAAAAcAEwAPAAwElAEAAA8AAvCMAQAAUAAI8AgAAAADAAAAAxQAAA8AA/AkAQAADwAE8CgA AAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAUAAAFAAAADwAE8HIAAAASAArwCAAA AAIUAAAgAgAAUwAL8B4AAAB/AAAABACAADR6bwO/AQAAAQD/AQAAAQABAwIEAAAAABDwCAAAAK0A IAFgFX0DDwAR8BAAAAAAAMMLCAAAAAAAAAANAG8DDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAA ABIACvAIAAAAAxQAACACAABTAAvwHgAAAH8AAAAEAIAAfH1vA78BAAABAP8BAAABAAEDAwQAAAAA EPAIAAAA8AMgAWAVEw8PABHwEAAAAAAAwwsIAAAAAQAAAA4AbwMPAA3wDAAAAAAAng8EAAAAAQAA AA8ABPBIAAAAEgAK8AgAAAABFAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgA vwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAA mZkAmcwAAA8AiBM4AAAADwCKEzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAA 6y4IAAAAR+3CAdABULcPAO4DJAIAAAIA7wMYAAAAAQAAAA0OAAAAAAAAAAAAgAAAAAAHABMADwAM BJQBAAAPAALwjAEAAGAACPAIAAAAAwAAAAMYAAAPAAPwJAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAA AAAAAAAAAAAAAAAAAgAK8AgAAAAAGAAABQAAAA8ABPByAAAAEgAK8AgAAAACGAAAIAIAAFMAC/Ae AAAAfwAAAAQAgAB0hm8DvwEAAAEA/wEAAAEAAQMCBAAAAAAQ8AgAAACtACABYBV9Aw8AEfAQAAAA AADDCwgAAAAAAAAADQBvAw8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HIAAAASAArwCAAAAAMYAAAg AgAAUwAL8B4AAAB/AAAABACAAOBsbwO/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAPADIAFgFRMP DwAR8BAAAAAAAMMLCAAAAAEAAAAOAG8DDwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAAABIACvAI AAAAARgAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQD CQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTOAAA AA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAAOsuCAAAAEftwgEwk9Hf AAByFyAAAAABAHAAAAAAAG4KAAAaFAAARhYAAHIYAACeGgAAyhwAAAAA9Q8cAAAAAAEAAG0QAAMA AAAA9h4AAAEAAAAHAAAAAQDhAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAA AAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAA FAAAABUAAAAWAAAAFwAAAP7///8ZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAD+ ////IwAAAP7///////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////7/AAAFAQIAAAAAAAAAAAAAAAAA AAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAJwFAAALAAAAAQAAAGAAAAACAAAAaAAAAAQAAACI AAAACAAAAJwAAAAJAAAAsAAAABIAAAC8AAAACgAAANwAAAAMAAAA6AAAAA0AAAD0AAAADwAAAAAB AAARAAAACAEAAAIAAADkBAAAHgAAABUAAABMRFVQIERvY3VtZW50IFN0YXR1cwAAUAAeAAAADAAA AENocmlzIEFwcGxlAB4AAAAMAAAAQ2hyaXMgQXBwbGUAHgAAAAIAAAAyAHJpHgAAABUAAABNaWNy b3NvZnQgUG93ZXJQb2ludAAAUABAAAAAMKvYGQAAAABAAAAAoA8jZUjtwgFAAAAA0Lr7fkjtwgED AAAAvwAAAEcAAACKBAAA/////wMAAAAIAIkQZwwAAAEACQAAAz0CAAAFACsAAAAAAAQAAAADAQgA BQAAAAsCAAAAAAUAAAAMAu8C6QMDAAAAHgAHAAAA/AIAAP///wAAAAQAAAAtAQAACAAAAPoCBQAA AAAA////AAQAAAAtAQEADAAAAEAJIQDwAAAAAAAAAO8C6QP/////CAAAAPoCAAAAAAAAAAAAAAQA AAAtAQIABAAAAC0BAAAEAAAAJwH//xwAAAD7AsP/AAAAAAAAkAEAAAAAAEAAIkFyaWFsAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAC0BAwAEAAAALgEYAAQAAAACAQEABQAAAAkCAAAAAisA AAAyCisBfwAYAAAAU2VsZWN0ZWQgTERVUCBEb2N1bWVudHMgKQAiAA4AIgAfABEAIgAiABEAIgAs ACwAKQARACwAIgAfACIAMwAiACIAEAAfABAABAAAAC4BAAAcAAAA+wIQAAcAAAAAALwCAAAAAAEC AiJTeXN0ZW0AAAAAAAAYAAAAQLMTAAEAAADkBAAAAAAAAAQAAAAtAQQABAAAAPABAwAcAAAA+wLD /wAAAAAAAJABAAAAAABAACJBcmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQMA BAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIQAAAAMgp1AZ0BBgAAAFN0YXR1cykAEQAiABEAIgAf AAQAAAAuAQAABAAAAC0BBAAEAAAA8AEDABwAAAD7AtT/AAAAAAAAkAEAAAAAAEAAIkFyaWFsAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAC0BAwAEAAAALgEYAAQAAAACAQEABQAAAAkCAAAA Ag0AAAAyCtkBpAEEAAAASUVURgwAHgAaABsABAAAAC4BAAAEAAAALQEEAAQAAADwAQMAHAAAAPsC 1P8AAAAAAACQAQAAAAAAQAAiQXJpYWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQED AAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAACCQAAADIK2QEDAgEAAAAt1xAABAAAAC4BAAAEAAAA LQEEAAQAAADwAQMAHAAAAPsC1P8AAAAAAACQAQAAAAAAQAAiQXJpYWwAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAEAAAALQEDAAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAACCgAAADIK2QETAgIA AAA1NhgAGAAEAAAALgEAAAQAAAAtAQQABAAAAPABAwAcAAAA+wLU/wAAAAAAAJABAAAAAABAACJB cmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQMABAAAAC4BGAAEAAAAAgEBAAUA AAAJAgAAAAIcAAAAMgpZAloBDgAAAE1hcmNoIDE4LCAyMDAzJQAYAA8AFgAZAAwAGQAYAA0ADAAZ ABkAGAAYAAQAAAAuAQAABAAAAC0BBAAEAAAA8AEDAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAQIAAAAAAAAAAAAAAAAAAAAA AAEAAAAC1c3VnC4bEJOXCAArLPmuMAAAACQCAAAQAAAAAQAAAIgAAAADAAAAkAAAAA8AAACoAAAA BAAAALQAAAAGAAAAvAAAAAcAAADEAAAACAAAAMwAAAAJAAAA1AAAAAoAAADcAAAAFwAAAOQAAAAL AAAA7AAAABAAAAD0AAAAEwAAAPwAAAAWAAAABAEAAA0AAAAMAQAADAAAAMEBAAACAAAA5AQAAB4A AAAPAAAAT24tc2NyZWVuIFNob3cAAB4AAAACAAAAIAAtcwMAAABCHwAAAwAAABUAAAADAAAABQAA AAMAAAAAAAAAAwAAAAAAAAADAAAAAAAAAAMAAAB7EAoACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAA CwAAAAAAAAAeEAAABwAAAAYAAABBcmlhbAAPAAAARGVmYXVsdCBEZXNpZ24AHwAAAFNlbGVjdGVk IExEVVAgRG9jdW1lbnRzIFN0YXR1cwAfAAAAUmVwbGljYXRpb24gVHJhbnNwb3J0IFByb3RvY29s ABIAAABJbmZvcm1hdGlvbiBNb2RlbAAdAAAATWFuZGF0b3J5IFJlcGxpY2EgTWFuYWdlbWVudAAP AAAAVXNhZ2UgUHJvZmlsZXMADBAAAAYAAAAeAAAACwAAAEZvbnRzIFVzZWQAAwAAAAEAAAAeAAAA EAAAAERlc2lnbiBUZW1wbGF0ZQADAAAAAQAAAB4AAAANAAAAU2xpZGUgVGl0bGVzAAMAAAAFAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPYPIwAAABQA AABfwJHjHh8AAAsA9AMDAG8DQ2hyaXMgQXBwbGUIAAAAQwBoAHIAaQBzACAAQQBwAHAAbABlAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABDAHUAcgByAGUAbgB0ACAAVQBzAGUAcgAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAP///////////////wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACIAAABBAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFIAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUA//////////8BAAAAEI2B ZJtPzxGG6gCqALkp6AAAAAAAAAAAAAAAANDr1xmb7cIBEwAAAMAKAAAAAAAAUABvAHcAZQByAFAA bwBpAG4AdAAgAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgEC AAAAAwAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAQh8AAAAA AAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAKAACAQQAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAADMBQAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwBy AG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAGAAAAAQEAAAAAAAA//////////8DAAAABAAAAAUAAAAGAAAABwAA AAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAD+/////////xQAAAAVAAAA HQAAAP///////////v///xgAAAD9/////v////7///8eAAAAHAAAAP////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////8BAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAA CAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAW AAAAFwAAAP7///8ZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAkAAAAIwAAAP7/ //8lAAAAJgAAACcAAAAoAAAAKQAAACoAAAD+//////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////1UAUAAgAFcARwAgAFAAcgBlAHMAZQBuAHQAYQB0 AGkAbwBuAHMAAAAfAAAAGgAAAGMAYQBwAHAAbABlAEAAZABzAGkALQBjAG8AbgBzAHUAbAB0AGkA bgBnAC4AbgBlAHQAAAAfAAAADAAAAEMAaAByAGkAcwAgAEEAcABwAGwAZQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUBAgAAAAAAAAAAAAAAAAAAAAAAAgAAAALV zdWcLhsQk5cIACss+a5EAAAABdXN1ZwuGxCTlwgAKyz5rmgCAAAkAgAAEAAAAAEAAACIAAAAAwAA AJAAAAAPAAAAqAAAAAQAAAC0AAAABgAAALwAAAAHAAAAxAAAAAgAAADMAAAACQAAANQAAAAKAAAA 3AAAABcAAADkAAAACwAAAOwAAAAQAAAA9AAAABMAAAD8AAAAFgAAAAQBAAANAAAADAEAAAwAAADB AQAAAgAAAOQEAAAeAAAADwAAAE9uLXNjcmVlbiBTaG93AAAeAAAAAgAAACAALXMDAAAAQh8AAAMA AAAVAAAAAwAAAAUAAAADAAAAAAAAAAMAAAAAAAAAAwAAAAAAAAADAAAAexAKAAsAAAAAAAAACwAA AAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAAAcAAAAGAAAAQXJpYWwADwAAAERlZmF1bHQgRGVzaWdu AB8AAABTZWxlY3RlZCBMRFVQIERvY3VtZW50cyBTdGF0dXMAHwAAAFJlcGxpY2F0aW9uIFRyYW5z cG9ydCBQcm90b2NvbAASAAAASW5mb3JtYXRpb24gTW9kZWwAHQAAAE1hbmRhdG9yeSBSZXBsaWNh IE1hbmFnZW1lbnQADwAAAFVzYWdlIFByb2ZpbGVzAAwQAAAGAAAAHgAAAAsAAABGb250cyBVc2Vk AAMAAAABAAAAHgAAABAAAABEZXNpZ24gVGVtcGxhdGUAAwAAAAEAAAAeAAAADQAAAFNsaWRlIFRp dGxlcwADAAAABQAAAAAAAJwBAAAHAAAAAAAAAEAAAAABAAAA9AAAAAAA9g8jAAAAFAAAAF/AkeMe HwAACwD0AwMAbwNDaHJpcyBBcHBsZQgAAABDAGgAcgBpAHMAIABBAHAAcABsAGUAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA gPwAAAACAAAABAEAAAMAAAAMAQAABAAAAEABAAAFAAAAfAEAAAQAAAACAAAAFAAAAF8AQQBkAEgA bwBjAFIAZQB2AGkAZQB3AEMAeQBjAGwAZQBJAEQAAAADAAAADgAAAF8ARQBtAGEAaQBsAFMAdQBi AGoAZQBjAHQAAAAEAAAADQAAAF8AQQB1AHQAaABvAHIARQBtAGEAaQBsAAAAAAAFAAAAGAAAAF8A QQB1AHQAaABvAHIARQBtAGEAaQBsAEQAaQBzAHAAbABhAHkATgBhAG0AZQAAAAIAAACwBAAAEwAA AAkEAAADAAAA9klIRx8AAAAWAAAATABEAA== ------=_NextPart_000_000A_01C2ED87.7141C9E0 Content-Type: application/vnd.ms-powerpoint; name="LDUP-arch-08-status-&-plans.ppt" Content-Disposition: attachment; filename="LDUP-arch-08-status-&-plans.ppt" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAARQAAAAAAAAAA EAAARwAAAAEAAAD+////AAAAAEYAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////9 ////PwAAAP7///8EAAAABgAAAB4AAAAHAAAACAAAAAkAAAAKAAAAFAAAAAwAAAANAAAADgAAAA8A AAAQAAAAEQAAABIAAAATAAAAAwAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAA AB8AAAA+AAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAA LAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6 AAAAOwAAADwAAAA9AAAA/v///0AAAAD+////QQAAAEIAAABDAAAARAAAAP7///////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////////1IA bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAWAAUA//////////8BAAAAcK576jv7zRGpAwCqAFEOowAAAAAAAAAAAAAAAABacoea7cIB BQAAAAAQAAAAAAAAUABvAHcAZQByAFAAbwBpAG4AdAAgAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACgAAgECAAAAAwAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAALAAAAL3AAAAAAAABUAGUAeAB0AF8AQwBvAG4AdABlAG4AdAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQUAAAAGAAAA/////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADkAwAAAAAAAFAAZQByAHMAaQBzAHQAZQBu AHQAUwB0AG8AcgBhAGcAZQAgAEQAaQByAGUAYwB0AG8AcgB5AAAAAAAAAAAAAAA4AAIBBwAAAP// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAD4AAAAAAAAAAQAA AAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAA /v////7////+/////v///xQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAe AAAAHwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwA AAAtAAAALgAAAC8AAAAwAAAAMQAAADIAAAAzAAAANAAAADUAAAA2AAAA/v///zgAAAA5AAAAOgAA ADsAAAA8AAAAPQAAAD4AAAA/AAAA/v////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////8AAP// AADsAAAAAAAAAOMPAAAAAAAANAAAADIAAAAA3AAAAP2VAP//AgBkAAAAAAAAAAAAAAAAAAAAAAAA AGQAAAAeAAAAAAAAAAAAAAAAAQEB4g8AAAAAAAAYAAAAMwAAAAEAAgAMAAAAAAAAAAABYgAAAAAA AAAAAO4HAAAAAAAAAAAAADUAAADsBwAA//8AABAAAAAvAAAA7gcAAAAAAAAAAAAALwAAAOwHAAD/ /wAAEAAAADAAAADuBwAAAAAAAAAAAAAwAAAA7AcAAP//AAAQAAAAMQAAAO4HAAAAAAAAAAAAADEA AACtDwAAAAAAAAAAAAAAAAAA9wMAAAEAAAAMAAAAAAAAAAAAAAAPEAAAAAAAANkPAAD//wAAOAAA AAAAAADaDwAAAAAAAAgAAAAAAAAAAQAAAAEAAAG6DwAA//8AAAAAAAAuAAAAug8AAP//AAAAAAAA MAAAAPQDAAD//wAANAAAAHgAAADvBwAAAAAAACQAAAB4AAAACAAAAP///wAAAAAAgICAAAAAAAAA zJkAMzPMAMzM/wCysrIAwAsAAP//AACAAAAAHAAAAMELAAAAAAAAKAAAAAAAAAD9////AAAAAAAA AADA9P//kPf//0ALAABwCAAAAAAAAKjnYgAAAAAAvQsAAAEAAAA4AAAAAAAAAAEAAAEAAAD+AAAA /gABsoIAAAAAAAAAAAAAAAUBAQAAAP4AAAAAAAAAAAAACD+nOAAAAAAAAAAAuAsAAP//AACgBQAA FAAAAMILAAD//wAAWQIAABMAAADDCwAAAAAAAAgAAAAAAAAADwBiAAAAAADBCwAAAAAAACgAAAAA AAAA/f///wAAAAAA37KCoPb//4D7///ACQAAUP7//wAAAAD9////AQBiAL0LAAABAAAAOAAAAAAA AAABAAABAAAA/gAAAP4BAbKCAAAAAAAAAP4AAAD+AQEAAAD+AAAAAAAAAAAAAAA/pzgAAAAAAAAA AKEPAAD//wAAsQEAAB4AAACgDwAAAAAAABAAAAAAAAAAOgAAAB0AAAAEgASAE+RiAKIPAAD//wAA gQEAAAAAAACjDwAAAAAAACQAAAAAAAAABgAAAAS3kjATLEMBAID//wAAAADa9v//nfv//4YJAAAz /v//tQ8AAAAAAAAEAAAAAAAAAAEAAADgDwAA//8AACkBAAAAAAAA7gcAAAAAAAAdAAAANQAAAExE QVAgUmVwbGljYXRpb24gQXJjaGl0ZWN0dXJl7AcAAP//AAA8AAAALwAAAO4HAAAAAAAALAAAAC8A AAAdAAAA4g8AAAAAAAAYAAAALwAAAAEAAgAsAAAAAAAAAAADYgAAAAAAAAAAAOwHAAD/TERBUCBS ZXBsaWNhdGlvbiBBcmNoaXRlY3R1cmUNDWRyYWZ0LWlldGYtbGR1cC1tb2RlbC0wOC50eHQNDVVw cGlsaSBTcmluaXZhc2FuDQ1TdGF0dXMNDU5vIGNvbnRlbnQgY2hhbmdlcyBpbiByZXYtMDggZnJv bSBwcmV2aW91cw1FZCBSZWVkIHJldGlyZXMgZnJvbSB0aGlzIGRvYyBlZmZvcnQNSGF2ZSByZWNl aXZlZCBvZmZlciB0byBoZWxwIGZyb206DUpvaG4gTWVycmVsbHMgKG9yaWdpbmFsIGNvLWF1dGhv cikgDUdlcmFsZCBNYXppYXJza2kgKGNvLWF1dGhvciBvZiBMRFVQIFVzYWdlIFByb2ZpbGUpIA1H bGFkIHRvIGhhdmUgdGhlbSBvbiBib2FyZCAmIGhvcGUgdG8gY2xvc2Ugc29vbg0NU3RhdHVzIGNv bnRkLg0NRG9jdW1lbnQgcmVhZHkgZnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiBhbGlnbm1lbnQg dy8gY3VycmVudCBzdGF0ZSBvZiBMRFVQIHJlcXVpcmVtZW50cyBhbmQgTVJNDVJldi0wNyByZWZl cnJlZCB0byBtYW55IGlzc3VlcyAoc29tZSBvdXRzaWRlIHRoZSBzY29wZSBvZiBMRFX/AABYAAAA MAAAAO4HAAAAAAAASAAAADAAAAAdAAAA4w8AAAAAAAA0AAAAMAAAAABkAAAA/ZUA//8CAGQAAAAA AAAAAAAAAAAAAAABAAAAZAAAAAAAAAAAAAAAAAAAAAABAQHsBwAA//8AACgAAAAxAAAA7gcAAAAA AAAYAAAAMQAAAB0AAADhDwAAAAAAAAQAAAAxAAAA/////60PAAAAAAAAAAAAAAAAAADCCwAA//8A ACcDAAATAAAAwwsAAAAAAAAIAAAAAAAAABAAYgABAAAAwQsAAAAAAAAoAAAAAAAAAP3///8AAAAA AN+ygoD4//8g/v//QAgAAND///8AAAAA/f///wEAYgC9CwAAAQAAADgAAAAAAAAAAQAAAQAAAP4A AAD+AQGyggAAAAAAAAD+AAAA/gEBAAAA/gAAAAAAAAAAAAAAP6c4AAAAAAAAAAChDwAA//8AAH8C AAAeAAAAoA8AAAAAAAAQAAAAAAAAADoAAAAdAAAABIAEgAPkYgCiDwAA//8AAE8CAAAAAAAAow8A AAAAAAAkAAAAAAAAAAUAAAAEt5IwAyxDAQCA//8AAAAAuvj//z3+//8GCAAAs////7UPAAAAAAAA BAAAAAAAAAAAAAAA4A8AAP//AAD3AQAAAAAAAO4HAAAAAAAALwAAADUAAABkcmFmdC1pZXRmLWxk dXAtbW9kZWwtMDgudHh0DQ1VcHBpbGkgU3Jpbml2YXNhbuwHAAD//wAAaAAAAC8AAADuBwAAAAAA AFgAAAAvAAAAHgAAAOIPAAAAAAAAGAAAAC8AAAABAAIAIAAAAAAAAAAAAWIAAAAAAAAAAAARAAAA 4g8AAAAAAAAYAAAALwAAAAEAAgAUAAAAAAAAAAABYgAAAAAAAAAAAOwHAAD//wAA6AAAADAAAADu BwAAAAAAANgAAAAwAAAAHQAAAOMPAAAAAAAANAAAADAAAAAAZAAAAP2VAP//AgBkAAAAAAAAAAAA AAAAAAAAAQAAAGQAAAAUAAAAAAAAAAAAAAAAAQEBAQAAAOMPAAAAAAAANAAAADAAAAAAZAAAAP2V AP//AgBkAAAAAAAAAAAAAAAAAAAAAQAAAGQAAAAUAAAAAAAAAAAAAAAAAQEBEQAAAOMPAAAAAAAA NAAAADAAAAAAZAAAAP2VAP//AgBkAAAAAAAAAAAAAAAAAAAAAQAAAGQAAAAUAAAAAAAAAAAAAAAA AQEB7AcAAP//AAAoAAAAMQAAAO4HAAAAAAAAGAAAADEAAAAvAAAA4Q8AAAAAAAAEAAAAMQAAAP// //+tDwAAAAAAAAAAAAAAAAAAiBMAAP//AAAUAAAANgAAAIkTAAAAAAAABAAAAAAAAAABAAAA7gMA AP//AACzDQAAEAAAAO8DAAAAAAAACAAAAAAAAAABAQAAAAAAgO0DAAABAAAAGAAAAAAAAADA9P// kPf//0ALAABwCAAAAQEAAAGABIDwAwAA//8AAKAEAAAlAAAA8QMAAAAAAAAEAAAAAAAAAAEBAADt AwAAAQAAABgAAAAAAAAAkPf//8D0//9wCAAAQAsAAAEBAAAB6GIA2Q8AAP//AABIAAAAAAAAANoP AAAAAAAACAAAAAAAAAABAAAAAQEBAboPAAD//wAAAAAAAC4AAAC6DwAA//8AAAAAAAAvAAAAug8A AP//AAAAAAAAMAAAAPQDAAD//wAANAAAAHgAAADvBwAAAAAAACQAAAB4AAAACAAAAP///wAAAAAA gICAAAAAAAAAzJkAMzPMAMzM/wCysrIAwAsAAP//AACAAAAAHAAAAMELAAAAAAAAKAAAAAAAAAD9 ////AAAAAAAAAACQ9///wPT//3AIAABACwAAAAAAAAznYgAAAAAAvQsAAAEAAAA4AAAAAAAAAAEA AAEAAAD+AAAA/gABsoIAAAAAAAAAAAAAAAUBAQAAAP4AAAAAAAAAAAAACD+nOAAAAAAAAAAAuAsA AP//AAAoAwAAFAAAAMILAAD//wAA7AAAABMAAADDCwAAAAAAAAgAAAAAAAAAEwBiAAAAAADBCwAA AAAAACgAAAAAAAAA/f///wAAAAAA37KCXfr//232//+jBQAA4/7//wAAAAD9////AAFiAL0LAAAB AAAAOAAAAAAAAAAAAAAAAAAA/v////4AAbKCAAAAAP////7////+AQEAAAD+AAAAAAAAAAAAAAA/ pzgAAAAAAAAAAK4PAAD//wAARAAAAB8AAACvDwAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ANYPAAD//wAAFAAAAAAAAADADwAAAAAAAAQAAAAAAAAAAQEAAMILAAD//wAAHAIAABMAAADDCwAA AAAAAAgAAAAAAAAADgBiAAEAAADBCwAAAAAAACgAAAAAAAAA/f///wAAAAAA37KC0Pn//3D///8w BgAAkAkAAAAAAAD9////AQBiAL0LAAABAAAAOAAAAAAAAAABAAABAAAA/gAAAP4BAbKCAAAAAAAA AP4AAAD+AQEAAAD+AAAAAAAAAAAAAAA/pzgAAAAAAAAAAKEPAAD//wAAdAEAAB4AAACgDwAAAAAA ABAAAAAAAAAAOgAAAB0AAAAEgASAA+RiAKIPAAD//wAARAEAAAAAAACjDwAAAAAAACQAAAAAAAAA AgAAAAS3kjADXEMBAID//wAAAAAK+v//jf////YFAABzCQAAtQ8AAAAAAAAEAAAAAAAAAAAAAADg DwAA//8AAOwAAAAAAAAA4w8AAAAAAAA0AAAAMgAAAADcAAAA/ZUA//8CAGQAAAAAAAAAAAAAAAAA AAAAAAAAZAAAAB4AAAAAAAAAAAAAAAABAQHiDwAAAAAAABgAAAAzAAAAAQACAAwAAAAAAAAAAAFi AAAAAAAAAAAA7gcAAAAAAAAAAAAANQAAAOwHAAD//wAAEAAAAC8AAADuBwAAAAAAAAAAAAAvAAAA 7AcAAP//AAAQAAAAMAAAAO4HAAAAAAAAAAAAADAAAADsBwAA//8AABAAAAAxAAAA7gcAAAAAAAAA AAAAMQAAAK0PAAAAAAAAAAAAAAAAAAD3AwAAAQAAAAwAAAAAAAAAAQAAAAwNAAAAAAAA2Q8AAP// AAA4AAAAAAAAANoPAAAAAAAACAAAAAAAAAABAAAAAQAAAboPAAD//wAAAAAAAC4AAAC6DwAA//8A AAAAAAAwAAAA9AMAAP//AAA0AAAAeAAAAO8HAAAAAAAAJAAAAHgAAAAIAAAA////AAAAAACAgIAA AAAAAADMmQAzM8wAzMz/ALKysgDACwAA//8AAIAAAAAcAAAAwQsAAAAAAAAoAAAAAAAAAP3///8A AAAAAAAAAMD0//+Q9///QAsAAHAIAAAAAAAAqOdiAAAAAAC9CwAAAQAAADgAAwAAAP//AAAfcAAA AAAAAOgDAAD//wAA928AAAAAAADpAwAABAAAACwAAAAAAAAAgBYAAOAQAADgEAAAgBYAAADpAQAB AKc4AwEAAAAAAAAEAAAABQAAAAoAAADyAwAA//8AAGoNAAAVAAAA6wcAAP//AACIAAAAEgAAANgP AAAAAAAAAgAAAAAAAAAOAOEHAAAAAAAAAAAAAAAAAADYDwAAAAAAAAIAAAAAAAAAAADhBwAAAAAA AAAAAAABAAAA2A8AAAAAAAACAAAAAAAAAA8A4QcAAAAAAAAAAAAAAgAAANgPAAAAAAAAAgAAAAAA AAAQAOEHAAAAAAAAAAAAAAMAAADIDwAA//8AAOIAAAAGAAAA0g8AAAAAAAAEAAAAKAAAAAEAAAC6 DwAA//8AACIAAAAEAAAAgWWBZ4FpgWuBbYFvgXGBc4F1gXeBeYGPgZAkKFtce6KBkroPAAD//wAA jAAAAAUAAACBQYFCgUOBRIFFgUaBR4FIgUmBSoFLgVKBU4FUgVWBWIFbgWaBaIFqgWyBboFwgXKB dIF2gXiBeoGLgfGBjIGNgY6BkYGTgp+CoYKjgqWCp4LBguGC44LlguyDQINCg0SDRoNIg2KDg4OF g4eDjoOVg5YhJSksLjo7P119oaOkpaeoqaqrrK2ur7De39YHAAD//wAAAAAAABcAAACwDwAA//8A ABACAAAYAAAA5Q8AAP//AABUAAAACQAAALMPAAAAAAAANAAAAAAAAAAAAAAAAAAAACABAAAgAQAA QAIAAEACAABgAwAAYAMAAIAEAACABAAAAwAAAEACAAAAAAAA5g8AAAAAAAAAAAAAAAAAAMsPAAAA AAAAAAAAAAAAAADhBwAAAAAAAAAAAAAAAAAA5Q8AAP//AABUAAAACQAAALMPAAAAAAAANAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAEACAAAAAAAA5g8A AAAAAAAAAAAAAAAAAMsPAAAAAAAAAAAAAAAAAADhBwAAAAAAAAAAAAABAAAA5Q8AAP//AABUAAAA CQAAALMPAAAAAAAANAAAAAAAAADYAAAAAAAAANQBAAAgAQAA0AIAAEACAADwAwAAYAMAABAFAACA BAAAAwAAAEACAAAAAAAA5g8AAAAAAAAAAAAAAAAAAMsPAAAAAAAAAAAAAAAAAADhBwAAAAAAAAAA AAACAAAA5Q8AAP//AABUAAAACQAAALMPAAAAAAAANAAAAAAAAABQAQAAAAAAAEACAACYAQAAMAMA AIgCAAA4BAAAeAMAAFgFAACABAAAAwAAAEACAAAAAAAA5g8AAAAAAAAAAAAAAAAAAMsPAAAAAAAA AAAAAAAAAADhBwAAAAAAAAAAAAADAAAA1QcAAP//AAB0AQAAGQAAALYPAAD//wAATAAAAAkAAAC3 DwAAAAAAADwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJABAAAAAAAAAAAAIkFyaWFsAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAyg8AAAAAAAAAAAAAAAAAAOEHAAAAAAAAAAAAAAAAAAC2DwAA//8A AEwAAAAJAAAAtw8AAAAAAAA8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQAQAAAAAAAAAAABJUaW1l cyBOZXcgUm9tYW4ABgIAAJQGPQEmBAAAAAAAAMoPAAAAAAAAAAAAAAAAAADhBwAAAAAAAAAAAAAB AAAAtg8AAP//AABMAAAACQAAALcPAAAAAAAAPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAEAAAAA AAAAAAAAQXJpYWwgVW5pY29kZSBNUwACAACUBj0BJgQAAAAAAADKDwAAAAAAAAAAAAAAAAAA4QcA AAAAAAAAAAAAAgAAANUHAAD//wAAAAAAABoAAADvBwAAAAAAAAQAAAAkAAAAAAAAAAQEAAD//wAA 0gUAACoAAAAFBAAAAAAAAAoAAAAAAAAAAQEBAAAAAAAAANQPAAAAAAAA2AEAAAAAAAABAAAAxP3/ /xMA978fALKCAQACACwAAAAAAAAAAAMAAAAAAAAAAAAAAQACACwAAAAAAAAAAAMAAAAAAAAAAAAA AQACACwAAAAAAAAAAAMAAAAAAAAAAAAAAQACACwAAAAAAAAAAANiAAAAAAAAAAAAAQACACwAAAAA AAAAAAP3vwAAAAAAAAAA//8CAAAAAAAAAAAAAP78vwAAAAAAAAAAAAAAAAD9lQD//wIAZAAAAAAA AAAAAAAAAAAAAAEAAABkAAAAAAAAAAAAAAAAAAAAAAEBAQB0AAAA/ZUA//8CAGQAAAAAAAAAAAAA AAEAAAABAAAAZAAAAAAAAAAAAAAAAAAAAAABAQEAqAAAAP2VAP//AgBkAAAAAAAAAAAAAAACAAAA AQAAAGQAAAAAAAAAAAAAAAAAAAAAAQEBAAAAAAD9lQD//wIAZAAAAAAAAAAAAAAAAwAAAAEAAABk AAAAAAAAAAAAAAAAAAAAAAEBAQDoAAAA/ZUA//8CAGQAAAAAAAAAAAAAAAQAAAABAAAAZAAAAAAA AAAAAAAAAAAAAAABAQEAAAAAAP4AAP//AgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA1A8AAAAAAADYAQAAAAAAAAIAAADE/f//AwD3vx8AsoIBAAIAIAAAAAAAAAAAAQAA AAAAAAAAAAABAAIAHAAAAAAAAAAAAQAAAAAAAAAAAAABAAIAGAAAAAAAAAAAAQAAAAAAAAAAAAAB AAIAFAAAAAAAAAAAAWIAAAAAAAAAAAABAAIAFAAAAAAAAAAAAfe/AAAAAAAAAAD//wIAAAAAAAAA AAAA/vy/AAAAAAAAAAABAAAAAP2VAP//AgBkAAAAAAAAAAAAAAAAAAAAAAAAAGQAAAAUAAAAAAAA AAAAAAAAAQEBAXQAAAD9lgD//wIAZAAAAAAAAAAAAAAAAQAAAAAAAABkAAAAFAAAAAAAAAAAAAAA AAEBAQGoAAAA/ZUA//8CAGQAAAAAAAAAAAAAAAIAAAAAAAAAZAAAABQAAAAAAAAAAAAAAAABAQEB AAAAAP2WAP//AgBkAAAAAAAAAAAAAAADAAAAAAAAAGQAAAAUAAAAAAAAAAAAAAAAAQEBAegAAAD9 uwD//wIAZAAAAAAAAAAAAAAABAAAAAAAAABkAAAAFAAAAAAAAAAAAAAAAAEBAQAAAAAA/gAA//8C AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADUDwAAAAAAANgBAAAAAAAA AAAAAMT9//8DAPe/HwCyggEAAgAMAAAAAAAAAAABAAAAAAAAAAAAAAEAAgAMAAAAAAAAAAABAAAA AAAAAAAAAAEAAgAMAAAAAAAAAAABAAAAAAAAAAAAAAEAAgAMAAAAAAAAAAABYgAAAAAAAAAAAAEA AgAMAAAAAAAAAAAB978AAAAAAAAAAP//AgAAAAAAAAAAAAD+/L8AAAAAAAAAAAAAAAAA/ZUA//8C AGQAAAAAAAAAAAAAAAAAAAAAAAAAZAAAAB4AAAAAAAAAAAAAAAABAQEAdAAAAP2VAP//AgBkAAAA AAAAAAAAAAABAAAAAAAAAGQAAAAeAAAAAAAAAAAAAAAAAQEBAKgAAAD9lQD//wIAZAAAAAAAAAAA AAAAAgAAAAAAAABkAAAAHgAAAAAAAAAAAAAAAAEBAQAAAAAA/ZUA//8CAGQAAAAAAAAAAAAAAAMA AAAAAAAAZAAAAB4AAAAAAAAAAAAAAAABAQEA6AAAAP2VAP//AgBkAAAAAAAAAAAAAAAEAAAAAAAA AGQAAAAeAAAAAAAAAAAAAAAAAQEBAAAAAAD+AAD//wIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAMQLAAD//wAAFgIAABYAAADFCwAAAAAAAAIAAAAAAAAAAADBCwAAAAAA ACgAAAAAAAAA/f///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD9////AQAAAL0LAAABAAAA OAAAAAAAAAAAAAAAAAAAAf////4AAbKCAAAAAAAAAAQAAAAAAQEAAAD+AAAAAAAAAAAAAAA/pzgA AAAAAAAAAKEPAAD//wAAdAEAAB4AAACgDwAAAAAAABAAAAAAAAAAOgAAAB0AAAAAAAABE/z//qIP AAD//wAARAEAAAAAAACjDwAAAAAAACQAAAAAAAAABAAAAAAAAAATAPZ/AID//wAAAAAAAAAAAAAA AAAAAAAAAAAAtQ8AAAAAAAAEAAAAAAAAAAAAAADgDwAA//8AAOwAAAAAAAAA4w8AAAAAAAA0AAAA MgAAAAAAAAAA/ZUA//8CAGQAAAAAAAAAAAAAAAAAAAAAAAAAZAAAAAAAAAAAAAAAAAAAAAABAQHi DwAAAAAAABgAAAAzAAAAAQACABgAAAAAAAAAAAH//wAAAAAAAAAA7gcAAAAAAAAAAAAANQAAAOwH AAD//wAAEAAAAC8AAADuBwAAAAAAAAAAAAAvAAAA7AcAAP//AAAQAAAAMAAAAO4HAAAAAAAAAAAA ADAAAADsBwAA//8AABAAAAAxAAAA7gcAAAAAAAAAAAAAMQAAAK0PAAAAAAAAAAAAAAAAAADQBwAA //8AAGw1AAAKAAAA0QcAAAAAAAAEAAAAAAAAAAQAAADuAwAA//8AAPwLAAAQAAAA7wMAAAAAAAAI AAAAAAAAAAABAAAAAACA7QMAAAEAAAAYAAAAAAAAAMD0//+Q9///QAsAAHAIAAABAQAAAYAEgPAD AAD//wAAoAQAACUAAADxAwAAAAAAAAQAAAAAAAAAAAEAAO0DAAABAAAAGAAAAAAAAACQ9///wPT/ /3AIAABACwAAAQEAAAHoYgDZDwAA//8AAEgAAAAAAAAA2g8AAAAAAAAIAAAAAAAAAAEAAAABAQEB ug8AAP//AAAAAAAALgAAALoPAAD//wAAAAAAAC8AAAC6DwAA//8AAAAAAAAwAAAA9AMAAP//AAA0 AAAAeAAAAO8HAAAAAAAAJAAAAHgAAAAIAAAA////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKy sgDACwAA//8AAIAAAAAcAAAAwQsAAAAAAAAoAAAAAAAAAP3///8AAAAAAAAAAJD3///A9P//cAgA AEALAAAAAAAADOdiAAAAAAC9CwAAAQAAADgAAAAAAAAAAQAAAQAAAP4AAAD+AAGyggAAAAAAAAAA AAAABQEBAAAA/gAAAAAAAAAAAAAIP6c4AAAAAAAAAAC4CwAA//8AACgDAAAUAAAAwgsAAP//AADs AAAAEwAAAMMLAAAAAAAACAAAAAAAAAATAGIAAAAAAMELAAAAAAAAKAAAAAAAAAD9////AAAAAADf soJd+v//bfb//6MFAADj/v//AAAAAP3///8AAWIAvQsAAAEAAAA4AAAAAAAAAAAAAAAAAAD+//// /gABsoIAAAAA/////v////4BAQAAAP4AAAAAAAAAAAAAAD+nOAAAAAAAAAAArg8AAP//AABEAAAA HwAAAK8PAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1g8AAP//AAAUAAAAAAAAAMAPAAAA AAAABAAAAAAAAAAAAQAAwgsAAP//AAAcAgAAEwAAAMMLAAAAAAAACAAAAAAAAAAOAGIAAQAAAMEL AAAAAAAAKAAAAAAAAAD9////AAAAAADfsoLQ+f//cP///zAGAACQCQAAAAAAAP3///8BAGIAvQsA AAEAAAA4AAAAAAAAAAEAAAEAAAD+AAAA/gEBsoIAAAAAAAAA/gAAAP4BAQAAAP4AAAAAAAAAAAAA AD+nOAAAAAAAAAAAoQ8AAP//AAB0AQAAHgAAAKAPAAAAAAAAEAAAAAAAAAA6AAAAHQAAAASABIAD 5GIAog8AAP//AABEAQAAAAAAAKMPAAAAAAAAJAAAAAAAAAACAAAABLeSMAM0QwEAgP//AAAAAAr6 //+N////9gUAAHMJAAC1DwAAAAAAAAQAAAAAAAAAAAAAAOAPAAAAAAAAAQAAAQAAAP4AAAD+AAGy ggAAAAAAAAAAAAAABQEBAAAA/gAAAAAAAAAAAAAIP6c4AAAAAAAAAAC4CwAA//8AAFcHAAAUAAAA wgsAAP//AABCAgAAEwAAAMMLAAAAAAAACAAAAAAAAAAMAGIAAAAAAMELAAAAAAAAKAAAAAAAAAD9 ////AAAAAADfsoKQ+v//IPj//+AEAABw+f//AAAAAP3///8BAGIAvQsAAAEAAAA4AAAAAAAAAAEA AAEAAAD+AAAA/gEBsoIAAAAAAAAA/gAAAP4BAQAAAP4AAAAAAAAAAAAAAD+nOAAAAAAAAAAAoQ8A AP//AACaAQAAHgAAAKAPAAAAAAAAEAAAAAAAAAA6AAAAHQAAAASABIAT5GIAog8AAP//AABqAQAA AAAAAKMPAAAAAAAAJAAAAAAAAAAAAAAABLeSMBNMQwEAgP//AAAAAMr6//89+P//pgQAAFP5//+1 DwAAAAAAAAQAAAAAAAAAAQAAAOAPAAD//wAAEgEAAAAAAADuBwAAAAAAAAYAAAA1AAAAU3RhdHVz 7AcAAP//AAA8AAAALwAAAO4HAAAAAAAALAAAAC8AAAAGAAAA4g8AAAAAAAAYAAAALwAAAAEAAgAk AAAAAAAAAAADYgAAAAAAAAAAAOwHAAD//wAAWAAAADAAAADuBwAAAAAAAEgAAAAwAAAABgAAAOMP AAAAAAAANAAAADAAAAAAZAAAAP2VAP//AgBkAAAAAAAAAAAAAAAAAAAAAQAAAGQAAAAAAAAAAAAA AAAAAAAAAQEB7AcAAP//AAAoAAAAMQAAAO4HAAAAAAAAGAAAADEAAAAGAAAA4Q8AAAAAAAAEAAAA MQAAAP////+tDwAAAAAAAAAAAAAAAAAAwgsAAP//AAD1BAAAEwAAAMMLAAAAAAAACAAAAAAAAAAN AGIAAQAAAMELAAAAAAAAKAAAAAAAAAD9////AAAAAADfsoJA9v//MPr//2AJAABABQAAAAAAAP3/ //8BAGIAvQsAAAEAAAA4AAAAAAAAAAEAAAEAAAD+AAAA/gEBsoIAAAAAAAAA/gAAAP4BAQAAAP4A AAAAAAAAAAAAAD+nOAAAAAAAAAAAoQ8AAP//AABNBAAAHgAAAKAPAAAAAAAAEAAAAAAAAAA6AAAA HQAAAASABIAD5GIAog8AAP//AAAdBAAAAAAAAKMPAAAAAAAAJAAAAAAAAAABAAAABLeSMAMwQwEA gP//AAAAAHr2//9N+v//JgkAACMFAAC1DwAAAAAAAAQAAAAAAAAAAgAAAOAPAAD//wAAxQMAAAAA AADuBwAAAAAAAPkAAAA1AAAATm8gY29udGVudCBjaGFuZ2VzIGluIHJldi0wOCBmcm9tIHByZXZp b3VzDUVkIFJlZWQgcmV0aXJlcyBmcm9tIHRoaXMgZG9jIGVmZm9ydA1IYXZlIHJlY2VpdmVkIG9m ZmVyIHRvIGhlbHAgZnJvbToNSm9obiBNZXJyZWxscyAob3JpZ2luYWwgY28tYXV0aG9yKSANR2Vy YWxkIE1hemlhcnNraSAoY28tYXV0aG9yIG9mIExEVVAgVXNhZ2UgUHJvZmlsZSkgDUdsYWQgdG8g aGF2ZSB0aGVtIG9uIGJvYXJkICYgaG9wZSB0byBjbG9zZSBzb29u7AcAAP//AACUAAAALwAAAO4H AAAAAAAAhAAAAC8AAAByAAAA4g8AAAAAAAAYAAAALwAAAAEAAgAgAAAAAAAAAAABYgAAAAAAAAAA ACQAAADiDwAAAAAAABgAAAAvAAAAAQACABwAAAAAAAAAAAFiAAAAAAAAAAAAYwAAAOIPAAAAAAAA GAAAAC8AAAACAAIAHAAAAAAAAAAAAWIAAAAAAAAAAADsBwAA//8AAMABAAAwAAAA7gcAAAAAAACw AQAAMAAAACsAAADjDwAAAAAAADQAAAAwAAAAAWQAAAD9lQD//wIAZAAAAAAAAAAAAAAAAAAAAAAA AABkAAAAFAAAAAAAAAAAAAAAAAEBASUAAADjDwAAAAAAADQAAAAwAAAAAWQAAAD9lQD//wIAZAAA AAAAAAAAAAAAAAAAAAAAAABkAAAAFAAAAAAAAAAAAAAAAAEBASIAAADjDwAAAAAAADQAAAAwAAAA AWQAAAD9lQD//wIAZAAAAAAAAAAAAAAAAAAAAAAAAABkAAAAFAAAAAAAAAAAAAAAAAEBASQAAADj DwAAAAAAADQAAAAwAAAAAWQAAAD9lgD//wIAZAAAAAAAAAAAAAAAAQAAAAAAAABkAAAAFAAAAAAA AAAAAAAAAAEBATQAAADjDwAAAAAAADQAAAAwAAAAAWQAAAD9lgD//wIAZAAAAAAAAAAAAAAAAQAA AAAAAABkAAAAFAAAAAAAAAAAAAAAAAEBAS8AAADjDwAAAAAAADQAAAAwAAAAAWQAAAD9lgD//wIA ZAAAAAAAAAAAAAAAAQAAAAAAAABkAAAAFAAAAAAAAAAAAAAAAAEBAewHAAD//wAAKAAAADEAAADu BwAAAAAAABgAAAAxAAAA+QAAAOEPAAAAAAAABAAAADEAAAD/////rQ8AAAAAAAAAAAAAAAAAAIgT AAD//wAAFAAAADYAAACJEwAAAAAAAAQAAAAAAAAAAQAAAO4DAAD//wAARw0AABAAAADvAwAAAAAA AAgAAAAAAAAABgEAAAAAAIDtAwAAAQAAABgAAAAAAAAAwPT//5D3//9ACwAAcAgAAAEBAAABgASA 8AMAAP//AACgBAAAJQAAAPEDAAAAAAAABAAAAAAAAAAGAQAA7QMAAAEAAAAYAAAAAAAAAJD3///A 9P//cAgAAEALAAABAQAAAehiANkPAAD//wAASAAAAAAAAADaDwAAAAAAAAgAAAAAAAAAAQAAAAEB AQG6DwAA//8AAAAAAAAuAAAAug8AAP//AAAAAAAALwAAALoPAAD//wAAAAAAADAAAAD0AwAA//8A ADQAAAB4AAAA7wcAAAAAAAAkAAAAeAAAAAgAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8A srKyAMALAAD//wAAgAAAABwAAADBCwAAAAAAACgAAAAAAAAA/f///wAAAAAAAAAAkPf//8D0//9w CAAAQAsAAAAAAAAM52IAAAAAAL0LAAABAAAAOAAAAAAAAAABAAABAAAA/gAAAP4AAbKCAAAAAAAA AAAAAAAFAQEAAAD+AAAAAAAAAAAAAAg/pzgAAAAAAAAAALgLAAD//wAAKAMAABQAAADCCwAA//8A AOwAAAATAAAAwwsAAAAAAAAIAAAAAAAAABMAYgAAAAAAwQsAAAAAAAAoAAAAAAAAAP3///8AAAAA AN+ygl36//9t9v//owUAAOP+//8AAAAA/f///wABYgC9CwAAAQAAADgAAAAAAAAAAAAAAAAAAP7/ ///+AAGyggAAAAD////+/////gEBAAAA/gAAAAAAAAAAAAAAP6c4AAAAAAAAAACuDwAA//8AAEQA AAAfAAAArw8AAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADWDwAA//8AABQAAAAAAAAAwA8A AAAAAAAEAAAAAAAAAAYBAADCCwAA//8AABwCAAATAAAAwwsAAAAAAAAIAAAAAAAAAA4AYgABAAAA wQsAAAAAAAAoAAAAAAAAAP3///8AAAAAAN+ygtD5//9w////MAYAAJAJAAAAAAAA/f///wEAYgC9 CwAAAQAAADgAAAAAAAAAAQAAAQAAAP4AAAD+AQGyggAAAAAAAAD+AAAA/gEBAAAA/gAAAAAAAAAA AAAAP6c4AAAAAAAAAAChDwAA//8AAHQBAAAeAAAAoA8AAAAAAAAQAAAAAAAAADoAAAAdAAAABIAE gAPkYgCiDwAA//8AAEQBAAAAAAAAow8AAAAAAAAkAAAAAAAAAAIAAAAEt5IwAzg9AQCA//8AAAAA Cvr//43////2BQAAcwkAALUPAAAAAAAABAAAAAAAAAAAAAAA4A8AAP//AADsAAAAAAAAAOMPAAAA AAAANAAAADIAAAAA3AAAAP2VAP//AgBkAAAAAAAAAAAAAAAAAAAAAAAAAGQAAAAeAAAAAAAAAAAA AAAAAQEB4g8AAAAAAAAYAAAAMwAAAAEAAgAMAAAAAAAAAAABYgAAAAAAAAAAAO4HAAAAAAAAAAAA ADUAAADsBwAA//8AABAAAAAvAAAA7gcAAAAAAAAAAAAALwAAAOwHAAD//wAAEAAAADAAAADuBwAA AAAAAAAAAAAwAAAA7AcAAP//AAAQAAAAMQAAAO4HAAAAAAAAAAAAADEAAACtDwAAAAAAAAAAAAAA AAAA9wMAAAEAAAAMAAAAAAAAAAEAAAAMDQAAAAAAANkPAAD//wAAOAAAAAAAAADaDwAAAAAAAAgA AAAAAAAAAQAAAAEAAAG6DwAA//8AAAAAAAAuAAAAug8AAP//AAAAAAAAMAAAAPQDAAD//wAANAAA AHgAAADvBwAAAAAAACQAAAB4AAAACAAAAP///wAAAAAAgICAAAAAAAAAzJkAMzPMAMzM/wCysrIA wAsAAP//AACAAAAAHAAAAMELAAAAAAAAKAAAAAAAAAD9////AAAAAAAAAADA9P//kPf//0ALAABw CAAAAAAAAKjnYgAAAAAAvQsAAAEAAAA4AAAAAAAAAAEAAAEAAAD+AAAA/gABsoIAAAAAAAAAAAAA AAUBAQAAAP4AAAAAAAAAAAAACD+nOAAAAAAAAAAAuAsAAP//AADrBgAAFAAAAMILAAD//wAASQIA ABMAAADDCwAAAAAAAAgAAAAAAAAADABiAAAAAADBCwAAAAAAACgAAAAAAAAA/f///wAAAAAA37KC kPr//yD4///gBAAAcPn//wAAAAD9////AQBiAL0LAAABAAAAOAAAAAAAAAABAAABAAAA/gAAAP4B AbKCAAAAAAAAAP4AAAD+AQEAAAD+AAAAAAAAAAAAAAA/pzgAAAAAAAAAAKEPAAD//wAAoQEAAB4A AACgDwAAAAAAABAAAAAAAAAAOgAAAB0AAAAEgASAE+RiAKIPAAD//wAAcQEAAAAAAACjDwAAAAAA ACQAAAAAAAAAAAAAAAS3kjATWD0BAID//wAAAADK+v//Pfj//6YEAABT+f//tQ8AAAAAAAAEAAAA AAAAAAEAAADgDwAA//8AABkBAAAAAAAA7gcAAAAAAAANAAAANQAAAFN0YXR1cyBjb250ZC7sBwAA //8AADwAAAAvAAAA7gcAAAAAAAAsAAAALwAAAA0AAADiDwAAAAAAABgAAAAvAAAAAQACACQAAAAA AAAAAANiAAAAAAAAAAAA7AcAAP//AABYAAAAMAAAAO4HAAAAAAAASAAAADAAAAANAAAA4w8AAAAA AAA0AAAAMAAAAABkAAAA/ZUA//8CAGQAAAAAAAAAAAAAAAAAAAABAAAAZAAAAAAAAAAAAAAAAAAA AAABAQHsBwAA//8AACgAAAAxAAAA7gcAAAAAAAAYAAAAMQAAAA0AAADhDwAAAAAAAAQAAAAxAAAA /////60PAAAAAAAAAAAAAAAAAADCCwAA//8AAIIEAAATAAAAwwsAAAAAAAAIAAAAAAAAAA0AYgAB AAAAwQsAAAAAAAAoAAAAAAAAAP3///8AAAAAAN+ygjD3//8w+v//UAoAAEAFAAAAAAAA/f///wEA YgC9CwAAAQAAADgAAAAAAAAAAQAAAQAAAP4AAAD+AQGyggAAAAAAAAD+AAAA/gEBAAAA/gAAAAAA AAAAAAAAP6c4AAAAAAAAAAChDwAA//8AANoDAAAeAAAAoA8AAAAAAAAQAAAAAAAAADoAAAAdAAAA BIAEgAPkYgCiDwAA//8AAKoDAAAAAAAAow8AAAAAAAAkAAAAAAAAAAEAAAAEt5IwA1w9AQCA//8A AAAAavf//036//8WCgAAIwUAALUPAAAAAAAABAAAAAAAAAACAAAA4A8AAP//AABSAwAAAAAAAOMP AAAAAAAANAAAADIAAAAB3AAAAP2WAP//AgBkAAAAAAAAAAAAAAABAAAAAAAAAGQAAAAUAAAAAAAA AAAAAAAAAQEB4g8AAAAAAAAYAAAAMwAAAAIAAgAcAAAAAAAAAAABYgAAAAAAAAAAAO4HAAAAAAAA 8gAAADUAAABEb2N1bWVudCByZWFkeSBmcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIGFsaWdubWVu dCB3LyBjdXJyZW50IHN0YXRlIG9mIExEVVAgcmVxdWlyZW1lbnRzIGFuZCBNUk0NUmV2LTA3IHJl ZmVycmVkIHRvIG1hbnkgaXNzdWVzIChzb21lIG91dHNpZGUgdGhlIHNjb3BlIG9mIExEVVAgYXMg bmVlZCByZXNvbHV0aW9uIHRvIGZpbmlzaCBhcmNoaXRlY3R1cmUNRXhhbXBsZTogQUNMLCBBZG1p bmlzdHJhdGlvbiBtb2RlbCBldGMuDewHAAD//wAAlAAAAC8AAADuBwAAAAAAAIQAAAAvAAAAYQAA AOIPAAAAAAAAGAAAAC8AAAABAAIAIAAAAAAAAAAAAWIAAAAAAAAAAABpAAAA4g8AAAAAAAAYAAAA LwAAAAIAAgAgAAAAAAAAAAABYgAAAAAAAAAAACgAAADiDwAAAAAAABgAAAAvAAAAAgACABwAAAAA AAAAAAFiAAAAAAAAAAAA7AcAAP//AADoAAAAMAAAAO4HAAAAAAAA2AAAADAAAABhAAAA4w8AAAAA AAA0AAAAMAAAAAFkAAAA/ZUA//8CAGQAAABQIGFzIG5lZWQgcmVzb2x1dGlvbiB0byBmaW5pc2gg YXJjaGl0ZWN0dXJlDUV4YW1wbGU6IEFDTCwgQWRtaW5pc3RyYXRpb24gbW9kZWwgZXRjLg0NDVBs YW5zDQ1SZXZpZXcgdG8gZW5zdXJlIGNvbnNpc3RlbmN5IHdpdGggb3RoZXIgTERVUCBkb2N1bWVu dHMNRG8gbm90IHdhaXQgZm9yIGNvbnNlbnN1cyBvbiBwcmV2aW91c2x5IHJhaXNlZCBpc3N1ZXMg dGhhdCBhcmUgYWN0dWFsbHkgb3V0c2lkZSB0aGUgc2NvcGUgb2YgTERVUC4gIA1FeGFtcGxlczog QUNMLCBBZG1pbmlzdHJhdGlvbiBtb2RlbCBldGMuIA1JbnN0ZWFkIGxpbWl0IGNvbmNlcHRzIGRl ZmluZWQgYW5kIHRoZW9yeSBvZiBvcGVyYXRpb25zIG9ubHkgdG8gdGhlIGV4dGVudCBwZXJ0aW5l bnQgdG8gcHJvdG9jb2wgYW5kIGluZm8gbW9kZWwgZG9jcw1PdXRsaW5lIHRoZW9yeSBvZiBvcGVy YXRpb24gdy9vIGFzc3VtaW5nIGhvbW9nZW5lb3VzIEFDTCBhbmQgQWRtaW4gbW9kZWxzLg0NAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABkAAAAFAAAAAAAAAAAAAAA AAEBAWkAAADjDwAAAAAAADQAAAAwAAAAAWQAAAD9lQD//wIAZAAAAAAAAAAAAAAAAAAAAAAAAABk AAAAFAAAAAAAAAAAAAAAAAEBASgAAADjDwAAAAAAADQAAAAwAAAAAWQAAAD9lgD//wIAZAAAAAAA AAAAAAAAAQAAAAAAAABkAAAAFAAAAAAAAAAAAAAAAAEBAewHAAD//wAAKAAAADEAAADuBwAAAAAA ABgAAAAxAAAA8gAAAOEPAAAAAAAABAAAADEAAAD/////rQ8AAAAAAAAAAAAAAAAAAIgTAAD//wAA FAAAADYAAACJEwAAAAAAAAQAAAAAAAAAAQAAAO4DAAD//wAAIg4AABAAAADvAwAAAAAAAAgAAAAA AAAAAwEAAAAAAIDtAwAAAQAAABgAAAAAAAAAwPT//5D3//9ACwAAcAgAAAEBAAABgASA8AMAAP// AACgBAAAJQAAAPEDAAAAAAAABAAAAAAAAAADAQAA7QMAAAEAAAAYAAAAAAAAAJD3///A9P//cAgA AEALAAABAQAAAehiANkPAAD//wAASAAAAAAAAADaDwAAAAAAAAgAAAAAAAAAAQAAAAEBAQG6DwAA //8AAAAAAAAuAAAAug8AAP//AAAAAAAALwAAALoPAAD//wAAAAAAADAAAAD0AwAA//8AADQAAAB4 AAAA7wcAAAAAAAAkAAAAeAAAAAgAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAMAL AAD//wAAgAAAABwAAADBCwAAAAAAACgAAAAAAAAA/f///wAAAAAAAAAAkPf//8D0//9wCAAAQAsA AAAAAAAM52IAAAAAAL0LAAABAAAAOAAAAAAAAAABAAABAAAA/gAAAP4AAbKCAAAAAAAAAAAAAAAF AQEAAAD+AAAAAAAAAAAAAAg/pzgAAAAAAAAAALgLAAD//wAAKAMAABQAAADCCwAA//8AAOwAAAAT AAAAwwsAAAAAAAAIAAAAAAAAABMAYgAAAAAAwQsAAAAAAAAoAAAAAAAAAP3///8AAAAAAN+ygl36 //9t9v//owUAAOP+//8AAAAA/f///wABYgC9CwAAAQAAADgAAAAAAAAAAAAAAAAAAP7////+AAGy ggAAAAD////+/////gEBAAAA/gAAAAAAAAAAAAAAP6c4AAAAAAAAAACuDwAA//8AAEQAAAAfAAAA rw8AAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADWDwAA//8AABQAAAAAAAAAwA8AAAAAAAAE AAAAAAAAAAMBAADCCwAA//8AABwCAAATAAAAwwsAAAAAAAAIAAAAAAAAAA4AYgABAAAAwQsAAAAA AAAoAAAAAAAAAP3///8AAAAAAN+ygtD5//9w////MAYAAJAJAAAAAAAA/f///wEAYgC9CwAAAQAA ADgAAAAAAAAAAQAAAQAAAP4AAAD+AQGyggAAAAAAAAD+AAAA/gEBAAAA/gAAAAAAAAAAAAAAP6c4 AAAAAAAAAAChDwAA//8AAHQBAAAeAAAAoA8AAAAAAAAQAAAAAAAAADoAAAAdAAAABIAEgAPkYgCi DwAA//8AAEQBAAAAAAAAow8AAAAAAAAkAAAAAAAAAAIAAAAEt5IwA4xDAQCA//8AAAAACvr//43/ ///2BQAAcwkAALUPAAAAAAAABAAAAAAAAAAAAAAA4A8AAP//AADsAAAAAAAAAOMPAAAAAAAANAAA ADIAAAAA3AAAAP2VAP//AgBkAAAAAAAAAAAAAAAAAAAAAAAAAGQAAAAeAAAAAAAAAAAAAAAAAQEB 4g8AAAAAAAAYAAAAMwAAAAEAAgAMAAAAAAAAAAABYgAAAAAAAAAAAO4HAAAAAAAAAAAAADUAAADs BwAA//8AABAAAAAvAAAA7gcAAAAAAAAAAAAALwAAAOwHAAD//wAAEAAAADAAAADuBwAAAAAAAAAA AAAwAAAA7AcAAP//AAAQAAAAMQAAAO4HAAAAAAAAAAAAADEAAACtDwAAAAAAAAAAAAAAAAAA9wMA AAEAAAAMAAAAAAAAAAEAAAAMDQAAAAAAANkPAAD//wAAOAAAAAAAAADaDwAAAAAAAAgAAAAAAAAA AQAAAAEAAAG6DwAA//8AAAAAAAAuAAAAug8AAP//AAAAAAAAMAAAAPQDAAD//wAANAAAAHgAAADv BwAAAAAAACQAAAB4AAAACAAAAP///wAAAAAAgICAAAAAAAAAzJkAMzPMAMzM/wCysrIAwAsAAP// AACAAAAAHAAAAMELAAAAAAAAKAAAAAAAAAD9////AAAAAAAAAADA9P//kPf//0ALAABwCAAAAAAA AKjnYgAAAAAAvQsAAAEAAAA4AAAAAAAAAAEAAAEAAAD+AAAA/gABsoIAAAAAAAAAAAAAAAUBAQAA AP4AAAAAAAAAAAAACD+nOAAAAAAAAAAAuAsAAP//AADGBwAAFAAAAMILAAD//wAAQQIAABMAAADD CwAAAAAAAAgAAAAAAAAADABiAAAAAADBCwAAAAAAACgAAAAAAAAA/f///wAAAAAA37KCkPr//yD4 ///wAwAAoPn//wAAAAD9////AQBiAL0LAAABAAAAOAAAAAAAAAABAAABAAAA/gAAAP4BAbKCAAAA AAAAAP4AAAD+AQEAAAD+AAAAAAAAAAAAAAA/pzgAAAAAAAAAAKEPAAD//wAAmQEAAB4AAACgDwAA AAAAABAAAAAAAAAAOgAAAB0AAAAEgASAE+RiAKIPAAD//wAAaQEAAAAAAACjDwAAAAAAACQAAAAA AAAAAAAAAAS3kjATiEMBAID//wAAAADK+v//Pfj//7YDAACD+f//tQ8AAAAAAAAEAAAAAAAAAAEA AADgDwAA//8AABEBAAAAAAAA7gcAAAAAAAAFAAAANQAAAFBsYW5z7AcAAP//AAA8AAAALwAAAO4H AAAAAAAALAAAAC8AAAAFAAAA4g8AAAAAAAAYAAAALwAAAAEAAgAoAAAAAAAAAAADYgAAAAAAAAAA AOwHAAD//wAAWAAAADAAAADuBwAAAAAAAEgAAAAwAAAABQAAAOMPAAAAAAAANAAAADAAAAAAZAAA AP2VAP//AgBkAAAAAAAAAAAAAAAAAAAAAQAAAGQAAAAAAAAAAAAAAAAAAAAAAQEB7AcAAP//AAAo AAAAMQAAAO4HAAAAAAAAGAAAADEAAAAFAAAA4Q8AAAAAAAAEAAAAMQAAAP////+tDwAAAAAAAAAA AAAAAAAAwgsAAP//AABlBQAAEwAAAMMLAAAAAAAACAAAAAAAAAANAGIAAQAAAMELAAAAAAAAKAAA AAAAAAD9////AAAAAADfsoJw9v//APr//5AJAABQBwAAAAAAAP3///8BAGIAvQsAAAEAAAA4AAAA AAAAAAEAAAEAAAD+AAAA/gEBsoIAAAAAAAAA/gAAAP4BAQAAAP4AAAAAAAAAAAAAAD+nOAAAAAAA AAAAoQ8AAP//AAC9BAAAHgAAAKAPAAAAAAAAEAAAAAAAAAA6AAAAHQAAAASABIAD5GIAog8AAP// AACNBAAAAAAAAKMPAAAAAAAAJAAAAAAAAAABAAAABLeSMAOMQwEAgP//AAAAAKr2//8d+v//VgkA ADMHAAC1DwAAAAAAAAQAAAAAAAAAAwAAAOAPAAD//wAANQQAAAAAAADuBwAAAAAAAIUBAAA1AAAA UmV2aWV3IHRvIGVuc3VyZSBjb25zaXN0ZW5jeSB3aXRoIG90aGVyIExEVVAgZG9jdW1lbnRzDURv IG5vdCB3YWl0IGZvciBjb25zZW5zdXMgb24gcHJldmlvdXNseSByYWlzZWQgaXNzdWVzIHRoYXQg YXJlIGFjdHVhbGx5IG91dHNpZGUgdGhlIHNjb3BlIG9mIExEVVAuICANRXhhbXBsZXM6IEFDTCwg QWRtaW5pc3RyYXRpb24gbW9kZWwgZXRjLiANSW5zdGVhZCBsaW1pdCBjb25jZXB0cyBkZWZpbmVk IGFuZCB0aGVvcnkgb2Ygb3BlcmF0aW9ucyBvbmx5IHRvIHRoZSBleHRlbnQgcGVydGluZW50IHRv IHByb3RvY29sIGFuZCBpbmZvIG1vZGVsIGRvY3MNT3V0bGluZSB0aGVvcnkgb2Ygb3BlcmF0aW9u IHcvbyBhc3N1bWluZyBob21vZ2VuZW91cyBBQ0wgYW5kIEFkbWluIG1vZGVscy7sBwAA//8AAMAA AAAvAAAA7gcAAAAAAACwAAAALwAAAJwAAADiDwAAAAAAABgAAAAvAAAAAQACACAAAAAAAAAAAAFi AAAAAAAAAAAAKgAAAOIPAAAAAAAAGAAAAC8AAAABAAIAHAAAAAAAAAAAAWIAAAAAAAAAAAB1AAAA 4g8AAAAAAAAYAAAALwAAAAEAAgAgAAAAAAAAAAABYgAAAAAAAAAAAEoAAADiDwAAAAAAABgAAAAv AAAAAQACABwAAAAAAAAAAAFiAAAAAAAAAAAA7AcAAP//AAB4AQAAMAAAAO4HAAAAAAAAaAEAADAA AAA3AAAA4w8AAAAAAAA0AAAAMAAAAAFkAAAA/ZUA//8CAGQAAAAAAAAAAAAAAAAAAAAAAAAAWgAA ABQAAAAAAAAAAAAAAAABAQFlAAAA4w8AAAAAAAA0AAAAMAAAAAFkAAAA/ZUA//8CAGQAAAAAAAAA AAAAAAAAAAAAAAAAWgAAABQAAAAAAAAAAAAAAAABAQEqAAAA4w8AAAAAAAA0AAAAMAAAAAFkAAAA /ZYA//8CAGQAAAAAAAAAAAAAAAEAAAAAAAAAWgAAABQAAAAAAAAAAAAAAAABAQF1AAAA4w8AAAAA AAA0AAAAMAAAAAFkAAAA/ZUA//8CAGQAAAAAAAAAAAAAAAAAAAAAAAAAWgAAABQAAAAAAAAAAAAA AAABAQFKAAAA4w8AAAAAAAA0AAAAMAAAAAFkAAAA/ZYA//8CAGQAAAAAAAAAAAAAAAEAAAAAAAAA WgAAABQAAAAAAAAAAAAAAAABAQHsBwAA//8AACgAAAAxAAAA7gcAAAAAAAAYAAAAMQAAAIUBAADh DwAAAAAAAAQAAAAxAAAA/////60PAAAAAAAAAAAAAAAAAACIEwAA//8AABQAAAA2AAAAiRMAAAAA AAAEAAAAAAAAAAEAAADQBwAA//8AANkQAAALAAAA0QcAAAAAAAAEAAAAAAAAAAEAAAD4AwAA//8A ALUQAAAQAAAA7wMAAAAAAAAIAAAAAAAAAAAAAIAAAAAA7QMAAAEAAAAYAAAAAAAAAMD0//+Q9/// QAsAAHAIAAABAQAAATqnOO8HAAAAAAAAJAAAADcAAAAIAAAAAAD/AP///wAAAAAA//8AAP+ZAAAA //8A/wAAAJaWlgDvBwAAAAAAACQAAAA3AAAACAAAAP///wAAAAAAgICAAAAAAAAAzJkAMzPMAMzM /wCysrIA7wcAAAAAAAAkAAAANwAAAAgAAAD///8AAAAAADMzMwAAAAAA3d3dAICAgABNTU0A6urq AO8HAAAAAAAAJAAAADcAAAAIAAAA///MAAAAAABmZjMAgIAAADOZMwCAAAAAADPMAP/MZgDvBwAA AAAAACQAAAA3AAAACAAAAP///wAAAAAAgICAAAAAAAD/zGYAAAD/AMwAzADAwMAA7wcAAAAAAAAk AAAANwAAAAgAAAD///8AAAAAAICAgAAAAAAAwMDAAABm/wD/AAAAAJkAAO8HAAAAAAAAJAAAADcA AAAIAAAA////AAAAAACAgIAAAAAAADOZ/wCZ/8wAzADMALKysgD3AwAAAQAAAAwAAAAAAAAAAQAA AAECBggHAAAA2Q8AAP//AAA4AAAAAAAAANoPAAAAAAAACAAAAAAAAAABAAAAAQAAAboPAAD//wAA AAAAAC4AAAC6DwAA//8AAAAAAAAwAAAA9AMAAP//AAA0AAAAeAAAAO8HAAAAAAAAJAAAAHgAAAAI AAAA////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKysgDACwAA//8AAIAAAAAcAAAAwQsAAAAA AAAoAAAAAAAAAP3///8AAAAAAAAAAMD0//+Q9///QAsAAHAIAAAAAAAAnOdiAAAAAAC9CwAAAQAA ADgAAAAAAAAAAQAAAQAAAP4AAAD+AAGyggAAAAAAAAAA/////gEBAAAA/gAAAAAAAAAAAAAIP6c4 AAAAAAAAAAC4CwAA//8AAMENAAAUAAAAwgsAAP//AABcAgAAEwAAAMMLAAAAAAAACAAAAAAAAAAB AGIAAAAAAMELAAAAAAAAKAAAAAAAAAD9////AAAAAADfsoJw9v//EPn//5AJAADg+///AAAAAP3/ //8BAGIAvQsAAAEAAAA4AAAAAAAAAAEAAAEAAAD+AAAA/gEBsoIAAAAAAAAA/gAAAP4BAQAAAP4A AAAAAAAAAAAAAD+nOAAAAAAAAAAAoQ8AAP//AAC0AQAAHgAAAKAPAAAAAAAAEAAAAAAAAAA6AAAA HQAAAASABIAT5GIA5A8AAP//AACEAQAAAAAAAKMPAAAAAAAAJAAAAAAAAAAAAAAABLeSMBN4uAAA gP//AAAAAKr2//8t+f//VgkAAMP7//+1DwAAAAAAAAQAAAAAAAAAAQAAAOAPAAD//wAALAEAAAAA AADuBwAAAAAAACAAAAA1AAAAQ2xpY2sgdG8gZWRpdCBNYXN0ZXIgdGl0bGUgc3R5bGXsBwAA//8A ADwAAAAvAAAA7gcAAAAAAAAsAAAALwAAACAAAADiDwAAAAAAABgAAAAvAAAAAQACACwAAAAAAAAA AANiAAAAAAAAAAAA7AcAAP//AABYAAAAMAAAAO4HAAAAAAAASAAAADAAAAAgAAAA4w8AAAAAAAA0 AAAAMAAAAABkAAAA/ZUA//8CAGQAAAAAAAAAAAAAAAAAAAABAAAAZAAAAAAAAAAAAAAAAAAAAAAB AQHsBwAA//8AACgAAAAxAAAA7gcAAAAAAAAYAAAAMQAAACAAAADhDwAAAAAAAAQAAAAxAAAA//// /60PAAAAAAAAAAAAAAAAAADCCwAA//8AAF4EAAATAAAAwwsAAAAAAAAIAAAAAAAAAAIAYgABAAAA wQsAAAAAAAAoAAAAAAAAAP3///8AAAAAAN+ygnD2//9w/P//kAkAAJAGAAAAAAAA/f///wEAYgC9 CwAAAQAAADgAAAAAAAAAAQAAAQAAAP4AAAD+AQGyggAAAAAAAAD+AAAA/gEBAAAA/gAAAAAAAAAA AAAAP6c4AAAAAAAAAAChDwAA//8AALYDAAAeAAAAoA8AAAAAAAAQAAAAAAAAADoAAAAdAAAABIAE gAPkYgDkDwAA//8AAIYDAAAAAAAAow8AAAAAAAAkAAAAAAAAAAEAAAAEt5IwA6C4AACA//8AAAAA qvb//438//9WCQAAcwYAALUPAAAAAAAABAAAAAAAAAACAAAA4A8AAP//AAAuAwAAAAAAAO4HAAAA AAAAUgAAADUAAABDbGljayB0byBlZGl0IE1hc3RlciB0ZXh0IHN0eWxlcw1TZWNvbmQgbGV2ZWwN VGhpcmQgbGV2ZWwNRm91cnRoIGxldmVsDUZpZnRoIGxldmVs7AcAAP//AADsAAAALwAAAO4HAAAA AAAA3AAAAC8AAAAhAAAA4g8AAAAAAAAYAAAALwAAAAEAAgAgAAAAAAAAAAABYgAAAAAAAAAAAA0A AADiDwAAAAAAABgAAAAvAAAAAQACABwAAAAAAAAAAAFiAAAAAAAAAAAADAAAAOIPAAAAAAAAGAAA AC8AAAABAAIAGAAAAAAAAAAAAWIAAAAAAAAAAAANAAAA4g8AAAAAAAAYAAAALwAAAAEAAgAUAAAA AAAAAAABYgAAAAAAAAAAAAsAAADiDwAAAAAAABgAAAAvAAAAAQACABQAAAAAAAAAAAFiAAAAAAAA AAAA7AcAAP//AAB4AQAAMAAAAO4HAAAAAAAAaAEAADAAAAAhAAAA4w8AAAAAAAA0AAAAMAAAAAFk AAAA/ZUA//8CAGQAAAAAAAAAAAAAAAAAAAAAAAAAZAAAABQAAAAAAAAAAAAAAAABAQENAAAA4w8A AAAAAAA0AAAAMAAAAAFkAAAA/ZYA//8CAGQAAAAAAAAAAAAAAAEAAAAAAAAAZAAAABQAAAAAAAAA AAAAAAABAQEMAAAA4w8AAAAAAAA0AAAAMAAAAAFkAAAA/ZUA//8CAGQAAAAAAAAAAAAAAAIAAAAA AAAAZAAAABQAAAAAAAAAAAAAAAABAQENAAAA4w8AAAAAAAA0AAAAMAAAAAFkAAAA/ZYA//8CAGQA AAAAAAAAAAAAAAMAAAAAAAAAZAAAABQAAAAAAAAAAAAAAAABAQELAAAA4w8AAAAAAAA0AAAAMAAA AAFkAAAA/bsA//8CAGQAAAAAAAAAAAAAAAQAAAAAAAAAZAAAABQAAAAAAAAAAAAAAAABAQHsBwAA //8AACgAAAAxAAAA7gcAAAAAAAAYAAAAMQAAAFIAAADhDwAAAAAAAAQAAAAxAAAA/////60PAAAA AAAAAAAAAAAAAADCCwAA//8AAD0CAAATAAAAwwsAAAAAAAAIAAAAAAAAAAYBYgACAAAAwQsAAAAA AAAoAAAAAAAAAP3///8AAAAAAN+ygnD2///wBgAAIPv//xAIAAAAAAAA/f///wEAYgC9CwAAAQAA ADgAAAAAAAAAAQAAAQAAAP4AAAD+AQGyggAAAAAAAAD+AAAA/gEBAAAA/gAAAAAAAAAAAAAAP6c4 AAAAAAAAAAChDwAA//8AAJUBAAAeAAAAoA8AAAAAAAAQAAAAAAAAADoAAAAdAAAABIAEgAPkYgCi DwAA//8AAGUBAAAAAAAAow8AAAAAAAAkAAAAAAAAAAQAAAAEt5IwA3i4AACA//8AAAAAqvb//w0H AADm+v//8wcAALUPAAAAAAAABAAAAAAAAAAAAAAA4A8AAP//AAANAQAAAAAAAO4HAAAAAAAAAQAA ADUAAAAq7AcAAP//AAA8AAAALwAAAO4HAAAAAAAALAAAAC8AAAABAAAA4g8AAAAAAAAYAAAALwAA AAEAAgAOAAAAgAAAAAABYgAAAAAAAAAAAOwHAAD//wAAWAAAADAAAADuBwAAAAAAAEgAAAAwAAAA AQAAAOMPAAAAAAAANAAAADAAAAAAZAAAAP2VAP//AgBkAAAAAAAAAAAAAAAAAAAAAAAAAGQAAAAA AAAAAAAAAAAAAAAAAQEB7AcAAP//AAAoAAAAMQAAAO4HAAAAAAAAGAAAADEAAAABAAAA4Q8AAAAA AAAEAAAAMQAAAAEAAACtDwAAAAAAAAAAAAAAAAAAwgsAAP//AAA9AgAAEwAAAMMLAAAAAAAACAAA AAAAAAAIAmIAAwAAAMELAAAAAAAAKAAAAAAAAAD9////AAAAAADfsoJw/P//8AYAAJADAAAQCAAA AAAAAP3///8BAGIAvQsAAAEAAAA4AAAAAAAAAAEAAAEAAAD+AAAA/gEBsoIAAAAAAAAA/gAAAP4B AQAAAP4AAAAAAAAAAAAAAD+nOAAAAAAAAAAAoQ8AAP//AACVAQAAHgAAAKAPAAAAAAAAEAAAAAAA AAA6AAAAHQAAAASABIAD5GIAog8AAP//AABlAQAAAAAAAKMPAAAAAAAAJAAAAAAAAAAEAAAABLeS MAOguAAAgP//AAAAAKr8//8NBwAAVgMAAPMHAAC1DwAAAAAAAAQAAAAAAAAAAAAAAOAPAAD//wAA DQEAAAAAAADuBwAAAAAAAAEAAAA1AAAAKuwHAAD//wAAPAAAAC8AAADuBwAAAAAAACwAAAAvAAAA AQAAAOIPAAAAAAAAGAAAAC8AAAABAAIADgAAAIAAAAAAAWIAAAAAAAAAAADsBwAA//8AAFgAAAAw AAAA7gcAAAAAAABIAAAAMAAAAAEAAADjDwAAAAAAADQAAAAwAAAAAGQAAAD9lQD//wIAZAAAAAAA AAAAAAAAAAAAAAEAAABkAAAAAAAAAAAAAAAAAAAAAAEBAewHAAD//wAAKAAAADEAAADuBwAAAAAA ABgAAAAxAAAAAQAAAOEPAAAAAAAABAAAADEAAAACAAAArQ8AAAAAAAAAAAAAAAAAAMILAAD//wAA PQIAABMAAADDCwAAAAAAAAgAAAAAAAAABwJiAAQAAADBCwAAAAAAACgAAAAAAAAA/f///wAAAAAA 37KC4AQAAPAGAACQCQAAEAgAAAAAAAD9////AQBiAL0LAAABAAAAOAAAAAAAAAABAAABAAAA/gAA AP4BAbKCAAAAAAAAAP4AAAD+AQEAAAD+AAAAAAAAAAAAAAA/pzgAAAAAAAAAAKEPAAD//wAAlQEA AB4AAACgDwAAAAAAABAAAAAAAAAAOgAAAB0AAAAEgASAA+RiAKIPAAD//wAAZQEAAAAAAACjDwAA AAAAACQAAAAAAAAABAAAAAS3kjADsLgAAID//wAAAAAaBQAADQcAAFYJAADzBwAAtQ8AAAAAAAAE AAAAAAAAAAAAAADgDwAA//8AAA0BAAAAAAAA7gcAAAAAAAABAAAANQAAACrsBwAA//8AADwAAAAv AAAA7gcAAAAAAAAsAAAALwAAAAEAAADiDwAAAAAAABgAAAAvAAAAAQACAA4AAACAAAAAAAFiAAAA AAAAAAAA7AcAAP//AABYAAAAMAAAAO4HAAAAAAAASAAAADAAAAABAAAA4w8AAAAAAAA0AAAAMAAA AABkAAAA/ZUA//8CAGQAAAAAAAAAAAAAAAAAAAACAAAAZAAAAAAAAAAAAAAAAAAAAAABAQHsBwAA //8AACgAAAAxAAAA7gcAAAAAAAAYAAAAMQAAAAEAAADhDwAAAAAAAAQAAAAxAAAAAwAAAK0PAAAA AAAAAAAAAAAAAADwAwAA//8AABYQAAAnAAAA8QMAAAAAAAAEAAAAAAAAAAAAAIDtAwAAAQAAABgA AAAAAAAAkPf//8D0//9wCAAAQAsAAAEBAAABgASA2Q8AAP//AABIAAAAAAAAANoPAAAAAAAACAAA AAAAAAABAAAAAQEBAboPAAD//wAAAAAAAC4AAAC6DwAA//8AAAAAAAAvAAAAug8AAP//AAAAAAAA MAAAAPQDAAD//wAANAAAAHgAAADvBwAAAAAAACQAAAB4AAAACAAAAP///wAAAAAAgICAAAAAAAAA zJkAMzPMAMzM/wCysrIAwAsAAP//AACAAAAAHAAAAMELAAAAAAAAKAAAAAAAAAD9////AAAAAAAA AACQ9///wPT//3AIAABACwAAAAAAAJznYgAAAAAAvQsAAAEAAAA4AAAAAAAAAAEAAAEAAAD+AAAA /gABsoIAAAAAAAAAAP////4BAQAAAP4AAAAAAAAAAAAACD+nOAAAAAAAAAAAuAsAAP//AACeDgAA FAAAAMILAAD//wAAPQIAABMAAADDCwAAAAAAAAgAAAAAAAAACQJiAAAAAADBCwAAAAAAACgAAAAA AAAA/f///wAAAAAA37KCkPf//8D0///g/v//4PX//wAAAAD9////AQBiAL0LAAABAAAAOAAAAAAA AAABAAABAAAA/gAAAP4BAbKCAAAAAAAAAP4AAAD+AQEAAAD+AAAAAAAAAAAAAAA/pzgAAAAAAAAA AKEPAAD//wAAlQEAAB4AAACgDwAAAAAAABAAAAAAAAAAOgAAAB0AAAAEgASAA+RiAKIPAAD//wAA ZQEAAAAAAACjDwAAAAAAACQAAAAAAAAABAAAAAS3kjADxLgAAID//wAAAADK9///3fT//6b+///D 9f//tQ8AAAAAAAAEAAAAAAAAAAAAAADgDwAA//8AAA0BAAAAAAAA7gcAAAAAAAABAAAANQAAACrs BwAA//8AADwAAAAvAAAA7gcAAAAAAAAsAAAALwAAAAEAAADiDwAAAAAAABgAAAAvAAAAAQACAAwA AACAAAAAAAFiAAAAAAAAAAAA7AcAAP//AABYAAAAMAAAAO4HAAAAAAAASAAAADAAAAABAAAA4w8A AAAAAAA0AAAAMAAAAABkAAAA/ZUA//8CAGQAAAAAAAAAAAAAAAAAAAAAAAAAZAAAAAAAAAAAAAAA AAAAAAABAQHsBwAA//8AACgAAAAxAAAA7gcAAAAAAAAYAAAAMQAAAAEAAADhDwAAAAAAAAQAAAAx AAAAAAAAAK0PAAAAAAAAAAAAAAAAAADCCwAA//8AAD0CAAATAAAAwwsAAAAAAAAIAAAAAAAAAAYA YgABAAAAwQsAAAAAAAAoAAAAAAAAAP3///8AAAAAAN+ygiABAADA9P//cAgAAOD1//8AAAAA/f// /wEAYgC9CwAAAQAAADgAAAAAAAAAAQAAAQAAAP4AAAD+AQGyggAAAAAAAAD+AAAA/gEBAAAA/gAA AAAAAAAAAAAAP6c4AAAAAAAAAAChDwAA//8AAJUBAAAeAAAAoA8AAAAAAAAQAAAAAAAAADoAAAAd AAAABIAEgAPkYgCiDwAA//8AAGUBAAAAAAAAow8AAAAAAAAkAAAAAAAAAAQAAAAEt5IwA9C4AACA //8AAAAAWgEAAN30//82CAAAw/X//7UPAAAAAAAABAAAAAAAAAAAAAAA4A8AAP//AAANAQAAAAAA AO4HAAAAAAAAAQAAADUAAAAq7AcAAP//AAA8AAAALwAAAO4HAAAAAAAALAAAAC8AAAABAAAA4g8A AAAAAAAYAAAALwAAAAEAAgAMAAAAgAAAAAABYgAAAAAAAAAAAOwHAAD//wAAWAAAADAAAADuBwAA AAAAAEgAAAAwAAAAAQAAAOMPAAAAAAAANAAAADAAAAAAZAAAAP2VAP//AgBkAAAAAAAAAAAAAAAA AAAAAgAAAGQAAAAAAAAAAAAAAAAAAAAAAQEB7AcAAP//AAAoAAAAMQAAAO4HAAAAAAAAGAAAADEA AAABAAAA4Q8AAAAAAAAEAAAAMQAAAAEAAACtDwAAAAAAAAAAAAAAAAAAwgsAAP//AADsAAAAEwAA AMMLAAAAAAAACAAAAAAAAAAEAGIAAgAAAMELAAAAAAAAKAAAAAAAAAD9////AAAAAADfsoJd+v// bfb//6MFAADj/v//AAAAAP3///8AAWIAvQsAAAEAAAA4AAAAAAAAAAAAAAAAAAD+/////gABsoIA AAAA/////v////4BAQAAAP4AAAAAAAAAAAAAAD+nOAAAAAAAAAAArg8AAP//AABEAAAAHwAAAK8P AAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1g8AAP//AAAUAAAAAAAAAMAPAAAAAAAABAAA AAAAAAAAAACAwgsAAP//AABeBAAAEwAAAMMLAAAAAAAACAAAAAAAAAAFAmIAAwAAAMELAAAAAAAA KAAAAAAAAAD9////AAAAAADfsoLQ+f//cP///zAGAACQCQAAAAAAAP3///8BAGIAvQsAAAEAAAA4 AAAAAAAAAAEAAAEAAAD+AAAA/gEBsoIAAAAAAAAA/gAAAP4BAQAAAP4AAAAAAAAAAAAAAD+nOAAA AAAAAAAAoQ8AAP//AAC2AwAAHgAAAKAPAAAAAAAAEAAAAAAAAAA6AAAAHQAAAASABIAD5GIAog8A AP//AACGAwAAAAAAAKMPAAAAAAAAJAAAAAAAAAACAAAABLeSMAPQuAAAgP//AAAAAAr6//+N//// 9gUAAHMJAAC1DwAAAAAAAAQAAAAAAAAAAAAAAOAPAAD//wAALgMAAAAAAADuBwAAAAAAAFIAAAA1 AAAAQ2xpY2sgdG8gZWRpdCBNYXN0ZXIgdGV4dCBzdHlsZXMNU2Vjb25kIGxldmVsDVRoaXJkIGxl dmVsDUZvdXJ0aCBsZXZlbA1GaWZ0aCBsZXZlbOwHAAD//wAA7AAAAC8AAADuBwAAAAAAANwAAAAv AAAAIQAAAOIPAAAAAAAAGAAAAC8AAAABAAIADAAAAAAAAAAAAWIAAAAAAAAAAAANAAAA4g8AAAAA AAAYAAAALwAAAAEAAgAMAAAAAAAAAAABYgAAAAAAAAAAAAwAAADiDwAAAAAAABgAAAAvAAAAAQAC AAwAAAAAAAAAAAFiAAAAAAAAAAAADQAAAOIPAAAAAAAAGAAAAC8AAAABAAIADAAAAAAAAAAAAWIA AAAAAAAAAAALAAAA4g8AAAAAAAAYAAAALwAAAAEAAgAMAAAAAAAAAAABYgAAAAAAAAAAAOwHAAD/ /wAAeAEAADAAAADuBwAAAAAAAGgBAAAwAAAAIQAAAOMPAAAAAAAANAAAADAAAAAAZAAAAP2VAP// AgBkAAAAAAAAAAAAAAAAAAAAAAAAAGQAAAAeAAAAAAAAAAAAAAAAAQEBDQAAAOMPAAAAAAAANAAA ADAAAAAAZAAAAP2VAP//AgBkAAAAAAAAAAAAAAABAAAAAAAAAGQAAAAeAAAAAAAAAAAAAAAAAQEB DAAAAOMPAAAAAAAANAAAADAAAAAAZAAAAP2VAP//AgBkAAAAAAAAAAAAAAACAAAAAAAAAGQAAAAe AAAAAAAAAAAAAAAAAQEBDQAAAOMPAAAAAAAANAAAADAAAAAAZAAAAP2VAP//AgBkAAAAAAAAAAAA AAADAAAAAAAAAGQAAAAeAAAAAAAAAAAAAAAAAQEBCwAAAOMPAAAAAAAANAAAADAAAAAAZAAAAP2V AP//AgBkAAAAAAAAAAAAAAAEAAAAAAAAAGQAAAAeAAAAAAAAAAAAAAAAAQEB7AcAAP//AAAoAAAA MQAAAO4HAAAAAAAAGAAAADEAAABSAAAA4Q8AAAAAAAAEAAAAMQAAAP////+tDwAAAAAAAAAAAAAA AAAAwgsAAP//AAA9AgAAEwAAAMMLAAAAAAAACAAAAAAAAAAIAmIABAAAAMELAAAAAAAAKAAAAAAA AAD9////AAAAAADfsoKQ9///IAoAAOD+//9ACwAAAAAAAP3///8BAGIAvQsAAAEAAAA4AAAAAAAA AAEAAAEAAAD+AAAA/gEBsoIAAAAAAAAA/gAAAP4BAQAAAP4AAAAAAAAAAAAAAD+nOAAAAAAAAAAA oQ8AAP//AACVAQAAHgAAAKAPAAAAAAAAEAAAAAAAAAA6AAAAHQAAAASABIAj5GIAog8AAP//AABl AQAAAAAAAKMPAAAAAAAAJAAAAAAAAAAEAAAABLeSMCPYuAAAgP//AAAAAMr3//89CgAApv7//yML AAC1DwAAAAAAAAQAAAAAAAAAAAAAAOAPAAD//wAADQEAAAAAAADuBwAAAAAAAAEAAAA1AAAAKuwH AAD//wAAPAAAAC8AAADuBwAAAAAAACwAAAAvAAAAAQAAAOIPAAAAAAAAGAAAAC8AAAABAAIADAAA AIAAAAAAAWIAAAAAAAAAAADsBwAA//8AAFgAAAAwAAAA7gcAAAAAAABIAAAAMAAAAAEAAADjDwAA AAAAADQAAAAwAAAAAGQAAAD9lQD//wIAZAAAAAAAAAAAAAAAAAAAAAAAAABkAAAAAAAAAAAAAAAA AAAAAAEBAewHAAD//wAAKAAAADEAAADuBwAAAAAAABgAAAAxAAAAAQAAAOEPAAAAAAAABAAAADEA AAACAAAArQ8AAAAAAAAAAAAAAAAAAMILAAD//wAAPQIAABMAAADDCwAAAAAAAAgAAAAAAAAABwJi AAUAAADBCwAAAAAAACgAAAAAAAAA/f///wAAAAAA37KCIAEAACAKAABwCAAAQAsAAAAAAAD9//// AQBiAL0LAAABAAAAOAAAAAAAAAABAAABAAAA/gAAAP4BAbKCAAAAAAAAAP4AAAD+AQEAAAD+AAAA AAAAAAAAAAA/pzgAAAAAAAAAAKEPAAD//wAAlQEAAB4AAACgDwAAAAAAABAAAAAAAAAAOgAAAB0A AAAEgASAI+RiAKIPAAD//wAAZQEAAAAAAACjDwAAAAAAACQAAAAAAAAABAAAAAS3kjAj7LgAAID/ /wAAAABaAQAAPQoAADYIAAAjCwAAtQ8AAAAAAAAEAAAAAAAAAAAAAADgDwAA//8AAA0BAAAAAAAA 7gcAAAAAAAABAAAANQAAACrsBwAA//8AADwAAAAvAAAA7gcAAAAAAAAsAAAALwAAAAEAAADiDwAA AAAAABgAAAAvAAAAAQACAAwAAACAAAAAAAFiAAAAAAAAAAAA7AcAAP//AABYAAAAMAAAAO4HAAAA AAAASAAAADAAAAABAAAA4w8AAAAAAAA0AAAAMAAAAABkAAAA/ZUA//8CAGQAAAAAAAAAAAAAAAAA AAACAAAAZAAAAAAAAAAAAAAAAAAAAAABAQHsBwAA//8AACgAAAAxAAAA7gcAAAAAAAAYAAAAMQAA AAEAAADhDwAAAAAAAAQAAAAxAAAAAwAAAK0PAAAAAAAAAAAAAAAAAADJDwAA//8AAJgKAAAbAAAA 7QMAAAEAAAAYAAAAAAAAAJD3///A9P//cAgAAEALAAABAQAAAYAEgNkPAAD//wAASAAAAAAAAADa DwAAAAAAAAgAAAAAAAAAAQAAAAEBAQG6DwAA//8AAAAAAAAuAAAAug8AAP//AAAAAAAALwAAALoP AAD//wAAAAAAADAAAAD0AwAA//8AADQAAAB4AAAA7wcAAAAAAAAkAAAAeAAAAAgAAAD///8AAAAA AICAgAAAAAAAAMyZADMzzADMzP8AsrKyAMALAAD//wAAgAAAABwAAADBCwAAAAAAACgAAAAAAAAA /f///wAAAAAAAAAAkPf//8D0//9wCAAAQAsAAAAAAACc52IAAAAAAL0LAAABAAAAOAAAAAAAAAAB AAABAAAA/gAAAP4AAbKCAAAAAAAAAAD////+AQEAAAD+AAAAAAAAAAAAAAg/pzgAAAAAAAAAALgL AAD//wAANAkAABQAAADCCwAA//8AAD0CAAATAAAAwwsAAAAAAAAIAAAAAAAAAAkCYgAAAAAAwQsA AAAAAAAoAAAAAAAAAP3///8AAAAAAN+ygpD3///A9P//4P7//+D1//8AAAAA/f///wEAYgC9CwAA AQAAADgAAAAAAAAAAQAAAQAAAP4AAAD+AQGyggAAAAAAAAD+AAAA/gEBAAAA/gAAAAAAAAAAAAAA P6c4AAAAAAAAAAChDwAA//8AAJUBAAAeAAAAoA8AAAAAAAAQAAAAAAAAADoAAAAdAAAABIAEgAPk YgCiDwAA//8AAGUBAAAAAAAAow8AAAAAAAAkAAAAAAAAAAQAAAAEt5IwA/i4AACA//8AAAAAyvf/ /930//+m/v//w/X//7UPAAAAAAAABAAAAAAAAAAAAAAA4A8AAP//AAANAQAAAAAAAO4HAAAAAAAA AQAAADUAAAAq7AcAAP//AAA8AAAALwAAAO4HAAAAAAAALAAAAC8AAAABAAAA4g8AAAAAAAAYAAAA LwAAAAEAAgAMAAAAgAAAAAABYgAAAAAAAAAAAOwHAAD//wAAWAAAADAAAADuBwAAAAAAAEgAAAAw AAAAAQAAAOMPAAAAAAAANAAAADAAAAAAZAAAAP2VAP//AgBkAAAAAAAAAAAAAAAAAAAAAAAAAGQA AAAAAAAAAAAAAAAAAAAAAQEB7AcAAP//AAAoAAAAMQAAAO4HAAAAAAAAGAAAADEAAAABAAAA4Q8A AAAAAAAEAAAAMQAAAAAAAACtDwAAAAAAAAAAAAAAAAAAwgsAAP//AAA9AgAAEwAAAMMLAAAAAAAA CAAAAAAAAAAGAmIAAQAAAMELAAAAAAAAKAAAAAAAAAD9////AAAAAADfsoIgAQAAwPT//3AIAADg 9f//AAAAAP3///8BAGIAvQsAAAEAAAA4AAAAAAAAAAEAAAEAAAD+AAAA/gEBsoIAAAAAAAAA/gAA AP4BAQAAAP4AAAAAAAAAAAAAAD+nOAAAAAAAAAAAoQ8AAP//AACVAQAAHgAAAKAPAAAAAAAAEAAA AAAAAAA6AAAAHQAAAASABIAD5GIAog8AAP//AABlAQAAAAAAAKMPAAAAAAAAJAAAAAAAAAAEAAAA BLeSMAMAQwEAgP//AAAAAFoBAADd9P//NggAAMP1//+1DwAAAAAAAAQAAAAAAAAAAAAAAOAPAAD/ /wAADQEAAAAAAADuBwAAAAAAAAEAAAA1AAAAKuwHAAD//wAAPAAAAC8AAADuBwAAAAAAACwAAAAv AAAAAQAAAOIPAAAAAAAAGAAAAC8AAAABAAIADAAAAIAAAAAAAWIAAAAAAAAAAADsBwAA//8AAFgA AAAwAAAA7gcAAAAAAABIAAAAMAAAAAEAAADjDwAAAAAAADQAAAAwAAAAAGQAAAD9lQD//wIAZAAA AAAAAAAAAAAAAAAAAAIAAABkAAAAAAAAAAAAAAAAAAAAAAEBAewHAAD//wAAKAAAADEAAADuBwAA AAAAABgAAAAxAAAAAQAAAOEPAAAAAAAABAAAADEAAAABAAAArQ8AAAAAAAAAAAAAAAAAAMILAAD/ /wAAPQIAABMAAADDCwAAAAAAAAgAAAAAAAAACAJiAAIAAADBCwAAAAAAACgAAAAAAAAA/f///wAA AAAA37KCkPf//yAKAADg/v//QAsAAAAAAAD9////AQBiAL0LAAABAAAAOAAAAAAAAAABAAABAAAA /gAAAP4BAbKCAAAAAAAAAP4AAAD+AQEAAAD+AAAAAAAAAAAAAAA/pzgAAAAAAAAAAKEPAAD//wAA lQEAAB4AAACgDwAAAAAAABAAAAAAAAAAOgAAAB0AAAAEgASAI+RiAKIPAAD//wAAZQEAAAAAAACj DwAAAAAAACQAAAAAAAAABAAAAAS3kjAjDEMBAID//wAAAADK9///PQoAAKb+//8jCwAAtQ8AAAAA AAAEAAAAAAAAAAAAAADgDwAA//8AAA0BAAAAAAAA7gcAAAAAAAABAAAANQAAACrsBwAA//8AADwA AAAvAAAA7gcAAAAAAAAsAAAALwAAAAEAAADiDwAAAAAAABgAAAAvAAAAAQACAAwAAACAAAAAAAFi AAAAAAAAAAAA7AcAAP//AABYAAAAMAAAAO4HAAAAAAAASAAAADAAAAABAAAA4w8AAAAAAAA0AAAA MAAAAABkAAAA/ZUA//8CAGQAAAAAAAAAAAAAAAAAAAAAAAAAZAAAAAAAAAAAAAAAAAAAAAABAQHs BwAA//8AACgAAAAxAAAA7gcAAAAAAAAYAAAAMQAAAAEAAADhDwAAAAAAAAQAAAAxAAAAAgAAAK0P AAAAAAAAAAAAAAAAAADCCwAA//8AAD0CAAATAAAAwwsAAAAAAAAIAAAAAAAAAAcCYgADAAAAwQsA AAAAAAAoAAAAAAAAAP3///8AAAAAAN+ygiABAAAgCgAAcAgAAEALAAAAAAAA/f///wEAYgC9CwAA AQAAADgAAAAAAAAAAQAAAQAAAP4AAAD+AQGyggAAAAAAAAD+AAAA/gEBAAAA/gAAAAAAAAAAAAAA P6c4AAAAAAAAAAChDwAA//8AAJUBAAAeAAAAoA8AAAAAAAAQAAAAAAAAADoAAAAdAAAABIAEgCPk YgCiDwAA//8AAGUBAAAAAAAAow8AAAAAAAAkAAAAAAAAAAQAAAAEt5IwIxRDAQCA//8AAAAAWgEA AD0KAAA2CAAAIwsAALUPAAAAAAAABAAAAAAAAAAAAAAA4A8AAP//AAANAQAAAAAAAO4HAAAAAAAA AQAAADUAAAAq7AcAAP//AAA8AAAALwAAAO4HAAAAAAAALAAAAC8AAAABAAAA4g8AAAAAAAAYAAAA LwAAAAEAAgAMAAAAgAAAAAABYgAAAAAAAAAAAOwHAAD//wAAWAAAADAAAADuBwAAAAAAAEgAAAAw AAAAAQAAAOMPAAAAAAAANAAAADAAAAAAZAAAAP2VAP//AgBkAAAAAAAAAAAAAAAAAAAAAgAAAGQA AAAAAAAAAAAAAAAAAAAAAQEB7AcAAP//AAAoAAAAMQAAAO4HAAAAAAAAGAAAADEAAAABAAAA4Q8A AAAAAAAEAAAAMQAAAAMAAACtDwAAAAAAAAAAAAAAAAAA0AcAAP//AAC6AAAADAAAANEHAAAAAAAA BAAAAAAAAAACAAAA+gMAAP//AACWAAAAtAAAAP4DAAABAAAAAgAAAAAAAAAAAeoHAAD//wAAMAAA AAAAAAD7AwAAAAAAAAgAAAAAAAAAAAAAAAAAAAD7AwAAAAAAAAgAAAAAAAAAAQAAAAAAAAD9AwAA AQAAADQAAAAAAAAAPgAAAGQAAAA+AAAAZAAAAAEAAAABAAAAAQAAAAEAAAAAAAAAAAAAAMX4///J +f//AQAAAAIEAAD//wAAJAAAAGQAAADjBwAA//8AABQAAABlAAAA6QcAAAAAAAAEAAAALAAAAAEA AADqAwAAAAAAAAAAAAAAAAAACgAAAAAAAAAIAAAAAAAAAAEAAAADAQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAiBAAA AAAAAAAAAAAAAAAAAQAAAAEAAAABAAAAFAAAAFBvd2VyUG9pbnQgRG9jdW1lbnQAAQAAAAAAAAAA AAsAAABDaHJpcyBBcHBsZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABNaWNyb3NvZnQgKFIpIFBvd2VyUG9pbnQgKFIpIFdpbmRvd3MgIAAHAQAA8AMAAF/A keMBAAAAAAAAAAAAAAAA/v8AAAQKAgAAAAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQq5EIACsn s9kwAAAAsAgAAAsAAAABAAAAYAAAAAIAAABoAAAABAAAAJAAAAAIAAAArAAAAAkAAAC8AAAAEgAA AMgAAAAKAAAA6AAAAAwAAAD0AAAADQAAAAABAAAPAAAADAEAABEAAAAUAQAAAgAAAOQEAAAeAAAA HgAAAExEQVAgUmVwbGljYXRpb24gQXJjaGl0ZWN0dXJlAHRhHgAAABIAAABVcHBpbGkgU3Jpbml2 YXNhbgByYx4AAAAHAAAAVXBwaWxpAFMeAAAAAwAAADE0AGkeAAAAFQAAAE1pY3Jvc29mdCBQb3dl clBvaW50AGl0ZUAAAACAW4PvEAAAAEAAAAAQac94us/BAUAAAACg/SiuYezCAQMAAABDAHUAcgBy AGUAbgB0ACAAVQBzAGUAcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA GgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABEAAAAP AAAAAAAAAEgAZQBhAGQAZQByAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAOAAIB/////wQAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAEgAAADkAAAAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8A bgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgD///////////////8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATAAAA4AgAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUA bQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAP////////////// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADcAAAAMAgAAAAAAAKAAAABHAAAA lAcAAP////8DAAAACACJEGcMAAABAAkAAAPCAwAABgAzAAAAAAARAAAAJgYPABgA/////wAAEAAA AAAAAAAAAMADAADQAgAACQAAACYGDwAIAP////8CAAAAFwAAACYGDwAjAP////8EABsAVE5QUBQA 1AC4ADIAAAD//08AFAAAAE0AaQAgAAoAAAAmBg8ACgBUTlBQAAACAPQDCQAAACYGDwAIAP////8D AAAADwAAACYGDwAUAFROUFAEAAwAAQAAAAEAAAAAAAAABQAAAAsCAAAAAAUAAAAMAtACwAMEAAAA BAENAAcAAAD8AgAA////AAAABAAAAC0BAAAJAAAA+gIFAAAAAAD///8AIgAEAAAALQEBAAQAAAAt AQAACQAAAB0GIQDwANACwAMAAAAABAAAAC0BAAAEAAAALQEAAAkAAAD6AgAAAAAAAAAAAAAiAAQA AAAtAQIAEAAAACYGDwAWAP////8AAEcAAACPAgAAEQEAAMECAAAIAAAAJgYPAAYA/////wEADQAA APsCAAAAAAAAAAAAAAAAAAEAAAAAAAAEAAAALQEDAAUAAAAJAgAAAAIFAAAAFAIAAAAABAAAAAIB AgAQAAAAJgYPABYA/////wAARwEAAI8CAAB5AgAAwQIAAAgAAAAmBg8ABgD/////AQAFAAAACQIA AAACBQAAABQCAAAAAAQAAAACAQIABwAAAPwCAQAAAAAAAAAEAAAALQEEAAQAAAAtAQEABwAAABsE IQGBA6gAUAAEAAAALQEAAAQAAAAtAQIABQAAAAkCAAAAAgUAAAAUAgAAAAAVAAAA+wLF/wAAAAAA AJABAAAAAABAABJUaW1lcyBOZXcgUm9tYW4AAAAEAAAALQEFAAQAAADwAQMABQAAAAkCAAAAAgUA AAAUAgAAAAAEAAAALgEYAAQAAAACAQEAMwAAADIK+QBzAB0AAABMREFQIFJlcGxpY2F0aW9uIEFy Y2hpdGVjdHVyZQAiACsAKgAhAA8AJwAaAB8ADwAQABoAGgARABAAHQAeAA8AKgAUABoAHgAQABAA GgAaABAAHgAUABoABAAAAC4BAQAEAAAAAgECAAQAAAACAQIABAAAAC0BBAAEAAAALQEBAAcAAAAb BGEBQQMYAaAABAAAAC0BAAAEAAAALQECAAUAAAAJAgAAAAIFAAAAFAIAAAAAFQAAAPsC1f8AAAAA AACQAQAAAAAAQAASVGltZXMgTmV3IFJvbWFuAAAABAAAAC0BAwAEAAAA8AEFAAUAAAAJAgAAAAIF AAAAFAIAAAAABAAAAC4BGAAEAAAAAgEBAA8AAAAyCkYBAwEFAAAAZHJhZnQAFQAOABQADQAMAAQA AAAuAQEABAAAAAIBAgAFAAAACQIAAAACBQAAABQCAAAAAAQAAAAuARgABAAAAAIBAQAJAAAAMgpG AVMBAQAAAC0ADgAEAAAALgEBAAQAAAACAQIABQAAAAkCAAAAAgUAAAAUAgAAAAAEAAAALgEYAAQA AAACAQEADQAAADIKRgFhAQQAAABpZXRmDAASAA0ADgAEAAAALgEBAAQAAAACAQIABQAAAAkCAAAA AgUAAAAUAgAAAAAEAAAALgEYAAQAAAACAQEACQAAADIKRgGaAQEAAAAtAA4ABAAAAC4BAQAEAAAA AgECAAUAAAAJAgAAAAIFAAAAFAIAAAAABAAAAC4BGAAEAAAAAgEBAA0AAAAyCkYBqAEEAAAAbGR1 cAwAFQAVABYABAAAAC4BAQAEAAAAAgECAAUAAAAJAgAAAAIFAAAAFAIAAAAABAAAAC4BGAAEAAAA AgEBAAkAAAAyCkYB9AEBAAAALQAPAAQAAAAuAQEABAAAAAIBAgAFAAAACQIAAAACBQAAABQCAAAA AAQAAAAuARgABAAAAAIBAQAPAAAAMgpGAQMCBQAAAG1vZGVsACAAFQAWABIADAAEAAAALgEBAAQA AAACAQIABQAAAAkCAAAAAgUAAAAUAgAAAAAEAAAALgEYAAQAAAACAQEACQAAADIKRgFsAgEAAAAt AA4ABAAAAC4BAQAEAAAAAgECAAUAAAAJAgAAAAIFAAAAFAIAAAAABAAAAC4BGAAEAAAAAgEBABAA AAAyCkYBegIGAAAAMDgudHh0FgAWAAsADAAVAAwABAAAAC4BAQAEAAAAAgECABUAAAD7AuX/AAAA AAAAkAEAAAAAAEAAElRpbWVzIE5ldyBSb21hbgAAAAQAAAAtAQUABAAAAPABAwAFAAAACQIAAAAC BQAAABQCAAAAAAQAAAAuARgABAAAAAIBAQAhAAAAMgquAZMBEQAAAFVwcGlsaSBTcmluaXZhc2Fu ABMADgAOAAcACAAHAAYADwAJAAcADgAHAAwADAAKAAwADgAEAAAALgEBAAQAAAACAQIABAAAAAIB AgAEAAAALQEBAAQAAAAtAQQAEAAAAPsCEAAHAAAAAAC8AgAAAAABAgIiU3lzdGVtAAAEAAAALQED AAQAAADwAQUADwAAACYGDwAUAFROUFAEAAwAAAAAAAAAAAAAAAAACQAAACYGDwAIAP////8BAAAA AwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAoCAAAAAAAAAAAAAAAA AAAAAAABAAAAAtXN1ZwuGxCTlwgAKyz5rjAAAADcAQAADQAAAAEAAABwAAAAAwAAAHgAAAAPAAAA kAAAAAQAAACsAAAABgAAALQAAAAHAAAAvAAAAAgAAADEAAAACQAAAMwAAAAKAAAA1AAAAAsAAADc AAAAEAAAAOQAAAANAAAA7AAAAAwAAAB5AQAAAgAAAOQEAAAeAAAADwAAAE9uLXNjcmVlbiBTaG93 AFAeAAAAEwAAAE9yYWNsZSBDb3Jwb3JhdGlvbgB0AwAAAAAAAAADAAAAFQAAAAMAAAAEAAAAAwAA AAQAAAADAAAAAAAAAAMAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAAHAAAAEAAAAFRpbWVzIE5l dyBSb21hbgARAAAAQXJpYWwgVW5pY29kZSBNUwAPAAAARGVmYXVsdCBEZXNpZ24AHgAAAExEQVAg UmVwbGljYXRpb24gQXJjaGl0ZWN0dXJlAAcAAABTdGF0dXMADgAAAFN0YXR1cyBjb250ZC4ABgAA AFBsYW5zAAwQAAAGAAAAHgAAAAsAAABGb250cyBVc2VkAAMAAAACAAAAHgAAABAAAABEZXNpZ24g VGVtcGxhdGUAAwAAAAEAAAAeAAAADQAAAFNsaWRlIFRpdGxlcwADAAAABAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABSAG8AbwB0ACAARQBu AHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAP// ////////AQAAAHCue+o7+80RqQMAqgBRDqMAAAAAAAAAAAAAAAAgv/8Zm+3CAQUAAACAEQAAAAAA AFAAbwB3AGUAcgBQAG8AaQBuAHQAIABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAoAAIBAgAAAAMAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAACwAAAC9wAAAAAAAAVABlAHgAdABfAEMAbwBuAHQAZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgEFAAAABgAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA5AMAAAAAAABQAGUAcgBzAGkAcwB0AGUAbgB0AFMAdABvAHIA YQBnAGUAIABEAGkAcgBlAGMAdABvAHIAeQAAAAAAAAAAAAAAOAACAQcAAAD//////////wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAA+AAAAAAAAAP///////////////wQA AAAGAAAAHgAAAAcAAAAIAAAACQAAAAoAAAAUAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAA ABMAAAADAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAAdAAAAHwAAAD4AAAAgAAAA IQAAACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsAAAAsAAAALQAAAC4AAAAv AAAAMAAAADEAAAAyAAAAMwAAADQAAAA1AAAANgAAADcAAAA4AAAAOQAAADoAAAA7AAAAPAAAAD0A AAD+////QAAAAP////9BAAAAQgAAAEoAAAD//////////0kAAAD9/////v////7////+////SwAA AEgAAAD///////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////AQAAAAIAAAADAAAABAAA AAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAA/v////7////+//// /v///xQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAh AAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwAAAAtAAAALgAAAC8A AAAwAAAAMQAAADIAAAAzAAAANAAAADUAAAA2AAAA/v///zgAAAA5AAAAOgAAADsAAAA8AAAAPQAA AD4AAAA/AAAAQAAAAEEAAABCAAAAQwAAAEQAAABFAAAA/v////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////8CAAAABAEAAAMAAAAMAQAA BAAAAEABAAAFAAAAfAEAAAQAAAACAAAAFAAAAF8AQQBkAEgAbwBjAFIAZQB2AGkAZQB3AEMAeQBj AGwAZQBJAEQAAAADAAAADgAAAF8ARQBtAGEAaQBsAFMAdQBiAGoAZQBjAHQAAAAEAAAADQAAAF8A QQB1AHQAaABvAHIARQBtAGEAaQBsAAAAAAAFAAAAGAAAAF8AQQB1AHQAaABvAHIARQBtAGEAaQBs AEQAaQBzAHAAbABhAHkATgBhAG0AZQAAAAIAAACwBAAAEwAAAAkEAAADAAAAXDQe0h8AAAAWAAAA TABEAFUAUAAgAFcARwAgAFAAcgBlAHMAZQBuAHQAYQB0AGkAbwBuAHMAAAAfAAAAGgAAAGMAYQBw AHAAbABlAEAAZABzAGkALQBjAG8AbgBzAHUAbAB0AGkAbgBnAC4AbgBlAHQAAAAfAAAADAAAAEMA aAByAGkAcwAgAEEAcABwAGwAZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEMAdQByAHIAZQBuAHQAIABV AHMAZQByAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIA//////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEQAAAA8AAAAAAAAASABl AGEAZABlAHIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAA4AAgH/////BAAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAS AAAAOQAAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAKAACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAABMAAADgCAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkA SQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIA////////////////AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANwAAALwDAAAAAAAAMgpGAWwCAQAAAC0ADgAEAAAA LgEBAAQAAAACAQIABQAAAAkCAAAAAgUAAAAUAgAAAAAEAAAALgEYAAQAAAACAQEAEAAAADIKRgF6 AgYAAAAwOC50eHQWABYACwAMABUADAAEAAAALgEBAAQAAAACAQIAFQAAAPsC5f8AAAAAAACQAQAA AAAAQAASVGltZXMgTmV3IFJvbWFuAAAABAAAAC0BBQAEAAAA8AEDAAUAAAAJAgAAAAIFAAAAFAIA AAAABAAAAC4BGAAEAAAAAgEBACEAAAAyCq4BkwERAAAAVXBwaWxpIFNyaW5pdmFzYW4AEwAOAA4A BwAIAAcABgAPAAkABwAOAAcADAAMAAoADAAOAAQAAAAuAQEABAAAAAIBAgAEAAAAAgECAAQAAAAt AQEABAAAAC0BBAAQAAAA+wIQAAcAAAAAALwCAAAAAAECAiJTeXN0ZW0AAAQAAAAtAQMABAAAAPAB BQAPAAAAJgYPABQAVE5QUAQADAAAAAAAAAAAAAAAAAAJAAAAJgYPAAgA/////wEAAAADAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAECgIAAAAAAAAAAAAAAAAAAAAAAAIA AAAC1c3VnC4bEJOXCAArLPmuRAAAAAXVzdWcLhsQk5cIACss+a4gAgAA3AEAAA0AAAABAAAAcAAA AAMAAAB4AAAADwAAAJAAAAAEAAAArAAAAAYAAAC0AAAABwAAALwAAAAIAAAAxAAAAAkAAADMAAAA CgAAANQAAAALAAAA3AAAABAAAADkAAAADQAAAOwAAAAMAAAAeQEAAAIAAADkBAAAHgAAAA8AAABP bi1zY3JlZW4gU2hvdwBQHgAAABMAAABPcmFjbGUgQ29ycG9yYXRpb24AdAMAAAAAAAAAAwAAABUA AAADAAAABAAAAAMAAAAEAAAAAwAAAAAAAAADAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAABwAA ABAAAABUaW1lcyBOZXcgUm9tYW4AEQAAAEFyaWFsIFVuaWNvZGUgTVMADwAAAERlZmF1bHQgRGVz aWduAB4AAABMREFQIFJlcGxpY2F0aW9uIEFyY2hpdGVjdHVyZQAHAAAAU3RhdHVzAA4AAABTdGF0 dXMgY29udGQuAAYAAABQbGFucwAMEAAABgAAAB4AAAALAAAARm9udHMgVXNlZAADAAAAAgAAAB4A AAAQAAAARGVzaWduIFRlbXBsYXRlAAMAAAABAAAAHgAAAA0AAABTbGlkZSBUaXRsZXMAAwAAAAQA AAAAAACcAQAABwAAAAAAAABAAAAAAQAAAPQAAAAAAACA/AAAAA== ------=_NextPart_000_000A_01C2ED87.7141C9E0-- From owner-ietf-ldup@mail.imc.org Thu Mar 20 06:58:31 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15080 for ; Thu, 20 Mar 2003 06:58:25 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2KBoQV13480 for ietf-ldup-bks; Thu, 20 Mar 2003 03:50:26 -0800 (PST) Received: from rly-ip03.mx.aol.com (rly-ip03.mx.aol.com [64.12.138.7]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2KBoCg13438 for ; Thu, 20 Mar 2003 03:50:12 -0800 (PST) Received: from logs-ta.proxy.aol.com (logs-ta.proxy.aol.com [152.163.205.5]) by rly-ip03.mx.aol.com (v89.10) with ESMTP id RELAYIN10-0320064708; Thu, 20 Mar 2003 06:47:08 -0500 Received: from D7ST2111 (AC905955.ipt.aol.com [172.144.89.85]) by logs-ta.proxy.aol.com (8.12.8/8.12.8) with ESMTP id h2KBkXTr183616; Thu, 20 Mar 2003 06:46:46 -0500 (EST) Reply-To: From: "Chris Apple" To: Cc: "John Strassner" Subject: WG Charter Proposal v2 Date: Thu, 20 Mar 2003 06:46:18 -0500 Organization: DSI-Consulting, Inc. Message-ID: <000501c2eed6$5c6a5640$555990ac@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Apparently-From: MTBtpguy@aol.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h2KBoQg13476 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Changes in this version: Incorporated comments made during the WG meeting session. Incorporated comments from mailing list. Mostly, these changes related to changing the working group description text to incorporate established consensus on a way to conclude our work. Associated changes to deliverables were also made. To-Be-Resolved: Keep multi-master and single-master replication profiles as deliverables? Or remove them. Mandatory (?) Replica Management document title is now somewhat misleading. Perhaps we should change it to *Recommended* Replica Management? Both of these issues need to be discussed on the mailing list. Any other comments on the WG charter are welcome also. I'm setting deadline for the WG to conclude discussion on revising the charter. Please post all comments to the WG mailing list or send directly to John Strassner and myself no later than: 1700 ET on Monday, March 7, 2003 I will post a final revision reflecting WG consensus to the list on March 8, 2003. After incorporating final comments (to be sure I didn't reflect anything incorrectly), this version will be submitted to the Applications Area Directors for consideration on March 15, 2003. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com ----------------------------------------------------------- LDAP Duplication/Replication/Update Protocols (ldup) Chair(s): Chris Apple John Strassner Applications Area Director(s): Ned Freed Ted Hardie Applications Area Advisor: Ted Hardie Mailing Lists: General Discussion: ietf-ldup@imc.org To Subscribe: ietf-ldup-request@imc.org In Body: subscribe Archive: http://www.imc.org/ietf-ldup/ Description of Working Group: As LDAPv3 becomes more widely deployed, replication of data across servers running different implementations becomes an important part of providing a distributed directory service. However, the LDAPv3 community, to date, has focused on standardizing the client-server access protocol. This group was originally chartered to standardize master-slave and multi-master LDAPv3 replication as defined below: o Multi-Master Replication - A replication model where entries can be written and updated on any of several replica copies, without requiring communication with other masters before the write or update is performed. o Master-Slave, or Single-Master Replication - A replication model that assumes only one server, the master, allows write access to the replicated data. Note that Master-Slave replication can be considered a proper subset of multi-master replication. The WG's approach was to first develop a set of requirements for LDAPv3 directory replication and write an applicability statement defining scenarios on which replication requirements are based. An engineering team was formed consisting of different vendors and the co-chairs in order to harmonize the existing approaches into a single standard approach. All of these have been accomplished during the pre-working group stage. It should be noted, however, that replication using heterogeneous servers is dependent on resolving access control issues, which were the domain of other working groups. Because the responsible WG failed to achieve consensus on a standard access control model for LDAPv3, the LDUP WG formed a design team to explore the issue of how to address the lack of such a model in the context of LDAPv3 replication. This design team made recommendations to the working group. The working group considered these recommendations and consensus was established on addressing these recommendations in the context of revising other working group deliverables rather than adding new deliverables specific to access control for replication. Largely because of the lack of a standard access control model for LDAPv3, the working group also established consensus on pursuing an experimental or informational publication path for a majority of working group documents formerly intended to become proposed standards. The new replication architecture supports all forms of replication mentioned above. Seven areas of working group focus have been identified through LDUP Engineering Team discussions, each leading to one or more documents to be published: o LDAPv3 Replication Architecture This documents a general-purpose LDAPv3 replication architecture, defines key components of this architecture, describes how these key components functionally behave, and describes how these components interact with each other when in various modes of operation o LDAPv3 Replication Information Model Defines the schema and semantics of information used to operate, administer, maintain, and provision replication between LDAPv3 servers. Specifically, this document will contain common schema specifications intended to facilitate interoperable implementations with respect to: + replication agreements + consistency models + replication topologies + managing deleted objects and their states + administration and management o LDAPv3 Replication Information Transport Protocol LDAPv3 extended operation and control specifications required to allow LDAPv3 to be used as the transport protocol for information being replicated o LDAPv3 Mandatory Replica Management Specifications required to allow administration, maintenance, and provisioning of replicas and replication agreements. These specifications may take the form of definitions for LDAPv3 extended operations, controls, and/or new schema elements. o LDAPv3 Update Reconciliation Procedures Procedures for detection and resolution of conflicts between the state of multiple replicas that contain information from the same unit of replication. o LDAPv3 Profiles Including the LDAPv3 Replication Architecture, Information Model, Protocol Extensions, and Update Reconciliation Procedures for: + LDAPv3 Replication General Usage + LDAPv3 Single-Master Directory Replication + LDAPv3 Multi-Master Directory Replication o LDAPv3 Client Update A protocol that enables an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content. The work being done in the LDUP WG should be coordinated to the closest extent possible with similar work being done in the ITU. This is necessary both because LDAP depends on X.500 and because it makes sense from an operational perspective. Goals and Milestones: Done Submit I-D on LDAPv3 Directory Replication Requirements. Done Submit I-D on LDAPv3 Replication Information Model Done Submit I-D on LDAPv3 Update Reconciliation Procedures. Done Revise I-D on LDAPv3 Directory Replication Requirements. Done Revise I-D on LDAPv3 Replication Architecture. Done Revise I-D on LDAPv3 Replication Information Model. Done Submit I-D on LDAPv3 Replication Information Transport Protocol. Done Revise I-D on LDAPv3 Replication Architecture. Done LDAPv3 Directory Replication Requirements I-D goes to WG Last Call as Informational. Done Submit I-D on LDAPv3 Mandatory Replica Management. Done Submit I-D on LDAPv3 Replication General Usage Profile. Done LDAPv3 Client Update Protocol I-D goes to WG Last Call as Proposed Standard. Done Revise LDAPv3 Client Update Protocol I-D. APR 03 Revise LDAPv3 Replication Information Model I-D. APR 03 Revise LDAPv3 Client Update Protocol I-D. MAY 03 Revise LDAPv3 Update Reconciliation Procedures I-D. MAY 03 Revise LDAPv3 Replication Architecture I-D. MAY 03 Revise LDAPv3 Replication Information Transport Protocol I-D. MAY 03 Revise LDAPv3 Mandatory Replica Management I-D. MAY 03 LDAPv3 Client Update Protocol I-D goes to WG Last Call as Proposed Standard. JUN 03 Revise LDAPv3 Replication General Usage Profile I-D. JUN 03 Submit I-D on LDAPv3 Single-Master Directory Replication Profile. JUN 03 Submit I-D on LDAPv3 Multi-Master Directory Replication Profile. JUN 03 LDAPv3 Replication Information Model I-D goes to WG Last Call as Informational. JUN 03 LDAPv3 Replication Architecture I-D goes to WG Last Call as Informational. JUL 03 Revise LDAPv3 Single-Master Directory Replication Profile I-D. JUL 03 Revise LDAPv3 Multi-Master Directory Replication Profile I-D. JUL 03 Revise LDAPv3 Update Reconciliation Procedures I-D. JUL 03 Revise LDAPv3 Replication Information Transport Protocol I-D. JUL 03 Revise LDAPv3 Mandatory Replica Management I-D. JUL 03 Evaluate Deliverables Status AUG 03 LDAPv3 Update Reconciliation Procedures I-D goes to WG Last Call as Experimental. AUG 03 LDAPv3 Replication Information Transport Protocol I-D goes to WG Last Call as Experimental. AUG 03 LDAPv3 Mandatory Replica Management I-D goes to WG Last Call as Experimental. SEP 03 LDAPv3 Replication General Usage Profile I-D goes to WG Last Call as Informational. SEP 03 LDAPv3 Single-Master Directory Replication Profile I-D goes to WG Last Call as Informational. SEP 03 LDAPv3 Multi-Master Directory Replication Profile I-D goes to WG Last Call as Informational. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com From owner-ietf-ldup@mail.imc.org Thu Mar 20 17:26:17 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10328 for ; Thu, 20 Mar 2003 17:26:16 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2KMFZr18753 for ietf-ldup-bks; Thu, 20 Mar 2003 14:15:35 -0800 (PST) Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2KMFVg18746 for ; Thu, 20 Mar 2003 14:15:32 -0800 (PST) Received: from D7ST2111 (wl-130-95.wireless.ietf56.ietf.org [130.129.130.95]) by dns.caledonia.net; Thu, 20 Mar 2003 15:14:04 -0700 Reply-To: From: "Chris Apple" To: , Cc: "'John Strassner'" Subject: RE: WG Charter Proposal v2 Date: Thu, 20 Mar 2003 17:14:17 -0500 Organization: DSI-Consulting, Inc. Message-ID: <001f01c2ef2e$16cfb3c0$5f828182@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-reply-to: <000501c2eed6$5c6a5640$555990ac@D7ST2111> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h2KMFZg18750 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Thanks to Tim Hahn for bringing to my attention that I meant to use April 7, 8, and 15 for the dates below rather than the same days in March. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] On Behalf Of Chris Apple Sent: Thursday, March 20, 2003 6:46 AM To: ietf-ldup@imc.org Cc: John Strassner Subject: WG Charter Proposal v2 Changes in this version: Incorporated comments made during the WG meeting session. Incorporated comments from mailing list. Mostly, these changes related to changing the working group description text to incorporate established consensus on a way to conclude our work. Associated changes to deliverables were also made. To-Be-Resolved: Keep multi-master and single-master replication profiles as deliverables? Or remove them. Mandatory (?) Replica Management document title is now somewhat misleading. Perhaps we should change it to *Recommended* Replica Management? Both of these issues need to be discussed on the mailing list. Any other comments on the WG charter are welcome also. I'm setting deadline for the WG to conclude discussion on revising the charter. Please post all comments to the WG mailing list or send directly to John Strassner and myself no later than: 1700 ET on Monday, March 7, 2003 I will post a final revision reflecting WG consensus to the list on March 8, 2003. After incorporating final comments (to be sure I didn't reflect anything incorrectly), this version will be submitted to the Applications Area Directors for consideration on March 15, 2003. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com ----------------------------------------------------------- LDAP Duplication/Replication/Update Protocols (ldup) Chair(s): Chris Apple John Strassner Applications Area Director(s): Ned Freed Ted Hardie Applications Area Advisor: Ted Hardie Mailing Lists: General Discussion: ietf-ldup@imc.org To Subscribe: ietf-ldup-request@imc.org In Body: subscribe Archive: http://www.imc.org/ietf-ldup/ Description of Working Group: As LDAPv3 becomes more widely deployed, replication of data across servers running different implementations becomes an important part of providing a distributed directory service. However, the LDAPv3 community, to date, has focused on standardizing the client-server access protocol. This group was originally chartered to standardize master-slave and multi-master LDAPv3 replication as defined below: o Multi-Master Replication - A replication model where entries can be written and updated on any of several replica copies, without requiring communication with other masters before the write or update is performed. o Master-Slave, or Single-Master Replication - A replication model that assumes only one server, the master, allows write access to the replicated data. Note that Master-Slave replication can be considered a proper subset of multi-master replication. The WG's approach was to first develop a set of requirements for LDAPv3 directory replication and write an applicability statement defining scenarios on which replication requirements are based. An engineering team was formed consisting of different vendors and the co-chairs in order to harmonize the existing approaches into a single standard approach. All of these have been accomplished during the pre-working group stage. It should be noted, however, that replication using heterogeneous servers is dependent on resolving access control issues, which were the domain of other working groups. Because the responsible WG failed to achieve consensus on a standard access control model for LDAPv3, the LDUP WG formed a design team to explore the issue of how to address the lack of such a model in the context of LDAPv3 replication. This design team made recommendations to the working group. The working group considered these recommendations and consensus was established on addressing these recommendations in the context of revising other working group deliverables rather than adding new deliverables specific to access control for replication. Largely because of the lack of a standard access control model for LDAPv3, the working group also established consensus on pursuing an experimental or informational publication path for a majority of working group documents formerly intended to become proposed standards. The new replication architecture supports all forms of replication mentioned above. Seven areas of working group focus have been identified through LDUP Engineering Team discussions, each leading to one or more documents to be published: o LDAPv3 Replication Architecture This documents a general-purpose LDAPv3 replication architecture, defines key components of this architecture, describes how these key components functionally behave, and describes how these components interact with each other when in various modes of operation o LDAPv3 Replication Information Model Defines the schema and semantics of information used to operate, administer, maintain, and provision replication between LDAPv3 servers. Specifically, this document will contain common schema specifications intended to facilitate interoperable implementations with respect to: + replication agreements + consistency models + replication topologies + managing deleted objects and their states + administration and management o LDAPv3 Replication Information Transport Protocol LDAPv3 extended operation and control specifications required to allow LDAPv3 to be used as the transport protocol for information being replicated o LDAPv3 Mandatory Replica Management Specifications required to allow administration, maintenance, and provisioning of replicas and replication agreements. These specifications may take the form of definitions for LDAPv3 extended operations, controls, and/or new schema elements. o LDAPv3 Update Reconciliation Procedures Procedures for detection and resolution of conflicts between the state of multiple replicas that contain information from the same unit of replication. o LDAPv3 Profiles Including the LDAPv3 Replication Architecture, Information Model, Protocol Extensions, and Update Reconciliation Procedures for: + LDAPv3 Replication General Usage + LDAPv3 Single-Master Directory Replication + LDAPv3 Multi-Master Directory Replication o LDAPv3 Client Update A protocol that enables an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content. The work being done in the LDUP WG should be coordinated to the closest extent possible with similar work being done in the ITU. This is necessary both because LDAP depends on X.500 and because it makes sense from an operational perspective. Goals and Milestones: Done Submit I-D on LDAPv3 Directory Replication Requirements. Done Submit I-D on LDAPv3 Replication Information Model Done Submit I-D on LDAPv3 Update Reconciliation Procedures. Done Revise I-D on LDAPv3 Directory Replication Requirements. Done Revise I-D on LDAPv3 Replication Architecture. Done Revise I-D on LDAPv3 Replication Information Model. Done Submit I-D on LDAPv3 Replication Information Transport Protocol. Done Revise I-D on LDAPv3 Replication Architecture. Done LDAPv3 Directory Replication Requirements I-D goes to WG Last Call as Informational. Done Submit I-D on LDAPv3 Mandatory Replica Management. Done Submit I-D on LDAPv3 Replication General Usage Profile. Done LDAPv3 Client Update Protocol I-D goes to WG Last Call as Proposed Standard. Done Revise LDAPv3 Client Update Protocol I-D. APR 03 Revise LDAPv3 Replication Information Model I-D. APR 03 Revise LDAPv3 Client Update Protocol I-D. MAY 03 Revise LDAPv3 Update Reconciliation Procedures I-D. MAY 03 Revise LDAPv3 Replication Architecture I-D. MAY 03 Revise LDAPv3 Replication Information Transport Protocol I-D. MAY 03 Revise LDAPv3 Mandatory Replica Management I-D. MAY 03 LDAPv3 Client Update Protocol I-D goes to WG Last Call as Proposed Standard. JUN 03 Revise LDAPv3 Replication General Usage Profile I-D. JUN 03 Submit I-D on LDAPv3 Single-Master Directory Replication Profile. JUN 03 Submit I-D on LDAPv3 Multi-Master Directory Replication Profile. JUN 03 LDAPv3 Replication Information Model I-D goes to WG Last Call as Informational. JUN 03 LDAPv3 Replication Architecture I-D goes to WG Last Call as Informational. JUL 03 Revise LDAPv3 Single-Master Directory Replication Profile I-D. JUL 03 Revise LDAPv3 Multi-Master Directory Replication Profile I-D. JUL 03 Revise LDAPv3 Update Reconciliation Procedures I-D. JUL 03 Revise LDAPv3 Replication Information Transport Protocol I-D. JUL 03 Revise LDAPv3 Mandatory Replica Management I-D. JUL 03 Evaluate Deliverables Status AUG 03 LDAPv3 Update Reconciliation Procedures I-D goes to WG Last Call as Experimental. AUG 03 LDAPv3 Replication Information Transport Protocol I-D goes to WG Last Call as Experimental. AUG 03 LDAPv3 Mandatory Replica Management I-D goes to WG Last Call as Experimental. SEP 03 LDAPv3 Replication General Usage Profile I-D goes to WG Last Call as Informational. SEP 03 LDAPv3 Single-Master Directory Replication Profile I-D goes to WG Last Call as Informational. SEP 03 LDAPv3 Multi-Master Directory Replication Profile I-D goes to WG Last Call as Informational. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com From owner-ietf-ldup@mail.imc.org Fri Mar 21 16:31:52 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28121 for ; Fri, 21 Mar 2003 16:31:51 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2LLRAm15177 for ietf-ldup-bks; Fri, 21 Mar 2003 13:27:10 -0800 (PST) Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2LLR9g15173 for ; Fri, 21 Mar 2003 13:27:09 -0800 (PST) Received: from dredd.mcom.com (dredd.nscp.aoltw.net [10.169.8.48]) by netscape.com (8.10.0/8.10.0) with ESMTP id h2LLR3R18386 for ; Fri, 21 Mar 2003 13:27:03 -0800 (PST) Received: from netscape.com ([10.169.192.131]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HC4BJV00.8ZJ for ; Fri, 21 Mar 2003 13:26:19 -0800 Message-ID: <3E7B8343.6010608@netscape.com> Date: Fri, 21 Mar 2003 14:25:23 -0700 From: richm@netscape.com (Rich Megginson) Organization: Netscape - Directory Server User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ldup@imc.org Subject: LCUP meeting summary and Draft report to LDUP WG Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090606020105040900090503" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090606020105040900090503 Content-Type: multipart/alternative; boundary="------------020309080103070504080202" --------------020309080103070504080202 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit On the afternoon of 3/18/03, Kurt and Rich, along with several other members of the LDAP and X.500 community, met to discuss the applicability of LCUP (http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-04.txt) versus the applicability of LDAP Content Sync (http://www.ietf.org/internet-drafts/draft-zeilenga-ldup-sync-01.txt). We discussed the 3 main points of contention: 1) Both protocols are concerned with synchronization of directory information. LCUP operates generally within the user information model. LDAP Content Sync operates generally within the system information model. Example: Let's say you have a container ou=People which holds user entries. Furthermore, there is a scheme by which the attribute facsimileTelephoneNumber is generated in all user entries - it is a virtual or collective attribute. The definition of this attribute is in a subentry of ou=People. With LCUP, the user wants to sync with the user entries, and wants to include the facsimileTelephoneNumber as part of that data. The user issues an LCUP search with a base of ou=People and a scope of one, and some arbitrary filter that returns one or more user entries, and the facsimileTelephoneNumber attribute in the attribute list. The user receives that data, including the facsimileTelephoneNumber. With LDAP Content Sync, the user wants to sync with the user entries, and wants to include the facsimileTelephoneNumber as part of that data. The user issues an LDAP Content Sync search with a base of ou=People and a scope of one, and some arbitrary filter that returns one or more user entries, and the facsimileTelephoneNumber attribute in the attribute list. The user also includes the LDAP SubEntry control in the search so that LDAP SubEntries are returned, specifically the subentry holding the virtual or collective attribute definition. The user receives the data for user entries but the facsimileTelephoneNumber attribute is NOT present in those entries. The user also receives the collective attribute definition and must derive the facsimileTelephoneNumber for user entries. Consequences: With LCUP, a change to the collective attribute definition causes every entry with that attribute to be reported as modified, which would cause either a large number of entries to be returned to the client, either as modified entries or via a full resync. With LDAP Content Sync, a change to the collective attribute definition causes only that 1 entry to be returned as changed (and all of the other entries in scope to be returned as unchanged). If you wanted to do the same thing as LDAP Content Sync with LCUP in this case, you would have to issue 2 separate searches: one search for the collective attribute definition including the facsimileTelephoneNumber, and one search for the user entries WITHOUT the facsimileTelephoneNumber attribute. With LCUP, the client needs no special knowledge of the physical information model. With LDAP Content Sync, the client MUST know about the physical information model. There is no way the client can use the "view" of the user information model. One proposed solution was to just include a bit in the LCUP protocol that would tell the server if the client wanted the user view or the physical view, but we decided that a change such as that would make the protocol too complex. . 2) LCUP assumes the server stores historical change information, either in a state based system or a log based system, about changes to entries, attributes, and values. LDAP Content Sync does not make this assumption, or at least assumes that the absolute minimum state information will be present, such as a modifyTimestamp/createTimestamp or an entryCSN. LDAP Content Sync works by sending the full requested entry if modified, and sending the DN or UUID of the entry for unchanged entries. The client is responsible for deleting entries from its local store that are not returned - this is implicit deletion - entries not returned as modified or present are assumed to have been deleted or otherwise removed from the search result set. A consequence of this is that, if you have N entries in your search result set, making a modification to 1 value of 1 entry causes N messages to be sent. With LCUP, just the 1 entry would be sent, because the historical data allows the optimization. One proposed solution was to include a bit in the LCUP protocol which would allow the server to calculate if it would be more efficient to send updates+deletes or updates+present entries, and tell the client what to expect. But we thought this would make client implementation too hard. Another proposed solution was to add a bit to LDAP Content Sync to allow updates+deletes in addition to our current updates+presents approach (allowing an implementation with histories to optimize the traffic). 3) In LCUP, changes to meta data, and subtree rename/delete operations, may cause a large number of messages to be sent or force the client to resync. LCUP assumes that these operations are very infrequent and so not very expensive. LDAP Content Sync gets around this issue because it always sends a message for every entry in the scope. This can be an advantage in a situation where a large number of entries have been deleted or removed from the search scope (e.g. access control change). In this case, only a few entries have to be returned as modified or present. Of course, in this case, an LCUP server can conclude that it would be prohibitively expensive to send all of these deletions, and simply force the client to resync. This also one case where a single change to user information will cause a large number of messages to be sent (during persist mode). In LCUP, a single modrdn to a non-leaf entry may result in multiple messages (one for the entry, one for each of its children) being generated. In LDAP Sync, a single modrdn generates a single update (the impact of the modrdn upon children of the entry is managed by the client). The conclusion is that some applications need LCUP and some need LDAP Content Sync, and it would make either protocol too complex to try to change it to meet the needs of the other. The LCUP authors and the LDAP Content Sync authors each will add a detailed applicability statement to the respective documents to allow implementors to better understand the assumptions and for what kinds of applications each mechanism is best suited for. --------------020309080103070504080202 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <title>
On the afternoon of 3/18/03, Kurt and Rich, along with several other members of the LDAP and X.500 community, met to discuss the applicability of LCUP (http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-04.txt) versus the applicability of LDAP Content Sync (http://www.ietf.org/internet-drafts/draft-zeilenga-ldup-sync-01.txt).  We discussed the 3 main points of contention:

1) Both protocols are concerned with synchronization of directory information. LCUP operates generally within the user information model. LDAP Content Sync operates generally within the system information model.

Example:  Let's say you have a container ou=People which holds user entries.  Furthermore, there is a scheme by which the attribute facsimileTelephoneNumber is generated in all user entries - it is a virtual or collective attribute.  The definition of this attribute is in a subentry of ou=People.

With LCUP, the user wants to sync with the user entries, and wants to include the facsimileTelephoneNumber as part of that data.  The user issues an LCUP search with a base of ou=People and a scope of one, and some arbitrary filter that returns one or more user entries, and the facsimileTelephoneNumber attribute in the attribute list.  The user receives that data, including the facsimileTelephoneNumber.

With LDAP Content Sync, the user wants to sync with the user entries, and wants to include the facsimileTelephoneNumber as part of that data.  The user issues an LDAP Content Sync search with a base of ou=People and a scope of one, and some arbitrary filter that returns one or more user entries, and the facsimileTelephoneNumber attribute in the attribute list.  The user also includes the LDAP SubEntry control in the search so that LDAP SubEntries are returned, specifically the subentry holding the virtual or collective attribute definition.  The user receives the data for user entries but the facsimileTelephoneNumber attribute is NOT present in those entries.  The user also receives the collective attribute definition and must derive the facsimileTelephoneNumber for user entries.

Consequences:
With LCUP, a change to the collective attribute definition causes every entry with that attribute to be reported as modified, which would cause either a large number of entries to be returned to the client, either as modified entries or via a full resync.  With LDAP Content Sync, a change to the collective attribute definition causes only that 1 entry to be returned as changed (and all of the other entries in scope to be returned as unchanged).

If you wanted to do the same thing as LDAP Content Sync with LCUP in this case, you would have to issue 2 separate searches: one search for the collective attribute definition including the facsimileTelephoneNumber, and one search for the user entries WITHOUT the facsimileTelephoneNumber attribute.

With LCUP, the client needs no special knowledge of the physical information model.  With LDAP Content Sync, the client MUST know about the physical information model.  There is no way the client can use the "view" of the user information model.
One proposed solution was to just include a bit in the LCUP protocol that would tell the server if the client wanted the user view or the physical view, but we decided that a change such as that would make the protocol too complex.
.
2) LCUP assumes the server stores historical change information, either in a state based system or a log based system, about changes to entries, attributes, and values.  LDAP Content Sync does not make this assumption, or at least assumes that the absolute minimum state information will be present, such as a modifyTimestamp/createTimestamp or an entryCSN.

LDAP Content Sync works by sending the full requested entry if modified, and sending the DN or UUID of the entry for unchanged entries.  The client is responsible for deleting entries from its local store that are not returned - this is implicit deletion - entries not returned as modified or present are assumed to have been deleted or otherwise removed from the search result set.  A consequence of this is that, if you have N entries in your search result set, making a modification to 1 value of 1 entry causes N messages to be sent.

With LCUP, just the 1 entry would be sent, because the historical data allows the optimization.

One proposed solution was to include a bit in the LCUP protocol which would allow the server to calculate if it would be more efficient to send updates+deletes or updates+present entries, and tell the client what to expect.  But we thought this would make client implementation too hard.

Another proposed solution was to add a bit to LDAP Content Sync to allow updates+deletes in addition to our current updates+presents approach (allowing an implementation with histories to optimize the traffic).

3) In LCUP, changes to meta data, and subtree rename/delete operations, may cause a large number of messages to be sent or force the client to resync.  LCUP assumes that these operations are very infrequent and so not very expensive.  LDAP Content Sync gets around this issue because it always sends a message for every entry in the scope.  This can be an advantage in a situation where a large number of entries have been deleted or removed from the search scope (e.g. access control change).  In this case, only a few entries have to be returned as modified or present.  Of course, in this case, an LCUP server can conclude that it would be prohibitively expensive to send all of these deletions, and simply force the client to resync.  This also one case where a single change to user information will cause a large number of messages to be sent (during persist mode). In LCUP, a single modrdn to a non-leaf entry may result in multiple messages (one for the entry, one for each of its children) being generated. In LDAP Sync, a single modrdn generates a single update (the impact of the modrdn upon children of the entry is managed by the client).

  The conclusion is that some applications need LCUP and some need LDAP Content 
Sync, and it would make either protocol too complex to try to change it to 
meet the needs of the other.  The LCUP authors and the LDAP Content Sync authors
each will add a detailed applicability statement to the respective      
 documents to allow implementors to better understand the assumptions and
for what kinds of applications each       mechanism is best suited for.

  

   



--------------020309080103070504080202--

--------------ms090606020105040900090503
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK6TCC
A4MwggLsoAMCAQICAmXjMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJVUzELMAkGA1UE
CBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5l
IEluYzEZMBcGA1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2Vy
dGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAyMTEyNjE4MTQwOFoXDTAzMDUyNTE4MTQwOFowfTEL
MAkGA1UEBhMCVVMxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEVMBMGCgmSJomT8ixk
AQETBXJpY2htMSEwHwYJKoZIhvcNAQkBFhJyaWNobUBuZXRzY2FwZS5jb20xFzAVBgNVBAMT
DlJpY2ggTWVnZ2luc29uMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCjtycvO35sPdLF
Stqay5K2LMKyD7e51X7uhDLV+/3Hlg76kaZ54H/KBj32h7PCn3+QZZFOLdHN3aEBFm+xepBb
0XQ69ikarFc5z5ize/BgTJlNbo8go0PUPlHM40Q+Lwiq8psjaGZST7G+gE9NeObvJ4AGg3+l
xnFOXzz331HNuQIDAQABo4H6MIH3MA4GA1UdDwEB/wQEAwIFIDAdBgNVHSUEFjAUBggrBgEF
BQcDAgYIKwYBBQUHAwQwQwYJYIZIAYb4QgENBDYWNElzc3VlZCBieSBOZXRzY2FwZSBDZXJ0
aWZpY2F0ZSBNYW5hZ2VtZW50IFN5c3RlbSA0LjUwHQYDVR0RBBYwFIEScmljaG1AbmV0c2Nh
cGUuY29tMB8GA1UdIwQYMBaAFCnbsi2Dfn+LI7vCzGa5Oegp8wKGMEEGCCsGAQUFBwEBBDUw
MzAxBggrBgEFBQcwAYYlaHR0cDovL2NlcnRpZmljYXRlcy5uZXRzY2FwZS5jb20vb2NzcDAN
BgkqhkiG9w0BAQUFAAOBgQCwXDFoep/l+//YCFgo2LSyTsPmP1cjsqCZ7gVG1HAequjZm0KK
zBI55bWiEaK9Vd7InSHZdF/hj8ACZsfrWA8y1xSo8AuKBVkTp1Hh76zmQQitAGP1DxN85Sgm
86kBzcZbqMNW5aNkW5K4Izpb+6N0EhwGx6Uv5AXlEGtUkQroijCCA4QwggLtoAMCAQICAmXk
MA0GCSqGSIb3DQEBBAUAMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAUBgNVBAcT
DU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcGA1UECxMQ
QU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUgQXV0aG9y
aXR5MB4XDTAyMTEyNjE4MTQwOFoXDTAzMDUyNTE4MTQwOFowfTELMAkGA1UEBhMCVVMxGzAZ
BgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEVMBMGCgmSJomT8ixkAQETBXJpY2htMSEwHwYJ
KoZIhvcNAQkBFhJyaWNobUBuZXRzY2FwZS5jb20xFzAVBgNVBAMTDlJpY2ggTWVnZ2luc29u
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDFUh7DaFJ6LKg4po0qdNFKLPsbudM37rcQ
AUU3YnD02FBbiRm1Jk/0duPoenqDZ/TZ9wexCkeK79DH4cw8VZhPqGoXFSsXv3OhTfgKNir6
VEVLJsHVhkm6bbiVOIn/nuYcC7brb/+wUiL0fJB07kFzuflsgek+0pJ2tcvXcwmiOQIDAQAB
o4H7MIH4MA8GA1UdDwEB/wQFAwMHgAAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME
MEMGCWCGSAGG+EIBDQQ2FjRJc3N1ZWQgYnkgTmV0c2NhcGUgQ2VydGlmaWNhdGUgTWFuYWdl
bWVudCBTeXN0ZW0gNC41MB0GA1UdEQQWMBSBEnJpY2htQG5ldHNjYXBlLmNvbTAfBgNVHSME
GDAWgBQp27Itg35/iyO7wsxmuTnoKfMChjBBBggrBgEFBQcBAQQ1MDMwMQYIKwYBBQUHMAGG
JWh0dHA6Ly9jZXJ0aWZpY2F0ZXMubmV0c2NhcGUuY29tL29jc3AwDQYJKoZIhvcNAQEEBQAD
gYEAqAyCrRh04NLX4Away7B39CLi0RcCBk+2vQHhXjfDe8+rK0dBOJI712YZNpyodrVnVmjN
5prJVyq/j+nTT8HWst7hp4aSHebefoSGzz6ZhAxzpgzOuSvchYytj1PE39pSaVMp1X7za/Ki
FpmEXDSQqND5mLjVpSUCA1LA9X2wmgswggPWMIIDP6ADAgECAgQCAAHmMA0GCSqGSIb3DQEB
BQUAMEUxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9HVEUgQ29ycG9yYXRpb24xHDAaBgNVBAMT
E0dURSBDeWJlclRydXN0IFJvb3QwHhcNMDEwNjAxMTI0NzAwWhcNMDQwNjAxMjM1OTAwWjCB
kzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRsw
GQYDVQQKExJBbWVyaWNhIE9ubGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMx
JzAlBgNVBAMTHkludHJhbmV0IENlcnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEA4u9fLHZDiUsaX7Pl+Kpviy+BTWf/vUoPYy7E3IX2nixJJiD/ABfk
iIhp3v2DV+CjERkRqtbcvO+z0hUuVMZufL/ZucNG0wkFhOVTXEjthIWaDjs9Fgdc8LN5q5oQ
pbzBpNF4TAblZEH8BSVjJuvvDMduVKGMzlRXth+S2rISS40CAwEAAaOCAYIwggF+ME0GA1Ud
HwRGMEQwQqBAoD6GPGh0dHA6Ly93d3cxLnVzLWhvc3RpbmcuYmFsdGltb3JlLmNvbS9jZ2kt
YmluL0NSTC9HVEVSb290LmNnaTAdBgNVHQ4EFgQUKduyLYN+f4sju8LMZrk56CnzAoYwZgYD
VR0gBF8wXTBGBgoqhkiG+GMBAgEFMDgwNgYIKwYBBQUHAgEWKmh0dHA6Ly93d3cuYmFsdGlt
b3JlLmNvbS9DUFMvT21uaVJvb3QuaHRtbDATBgMqAwQwDDAKBggrBgEFBQcCATBYBgNVHSME
UTBPoUmkRzBFMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPR1RFIENvcnBvcmF0aW9uMRwwGgYD
VQQDExNHVEUgQ3liZXJUcnVzdCBSb290ggIBozArBgNVHRAEJDAigA8yMDAxMDYwMTEyNDcz
MFqBDzIwMDMwOTAxMjM1OTAwWjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TBAgwBgEB/wIBATAN
BgkqhkiG9w0BAQUFAAOBgQBKYg7Z+kZ3BApsDd3+0iI5mRAKrogthj1XhOYSJDdp+1le4hGw
+Z+kV4aKaR8GY9F97jM2SRAgDx+XFywnbD1sOQR74kXohxtUtmBBbR2uBfOd+To0muN7a0xx
+OuoK4OwNZBMGWhx7fBjIl7CW+wgerWwUXPpB+6BZ3Z5U/eV1DGCAqYwggKiAgEBMIGaMIGT
MQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxGzAZ
BgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcGA1UECxMQQU9MIFRlY2hub2xvZ2llczEn
MCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AgJl5DAJBgUrDgMCGgUA
oIIBYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMjEy
MTI1MjNaMCMGCSqGSIb3DQEJBDEWBBQeaa3FNZOT4/ohJGh0Fb+U/y56XDBSBgkqhkiG9w0B
CQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr
DgMCBzANBggqhkiG9w0DAgIBKDCBrQYLKoZIhvcNAQkQAgsxgZ2ggZowgZMxCzAJBgNVBAYT
AlVTMQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1l
cmljYSBPbmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5J
bnRyYW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCAmXjMA0GCSqGSIb3DQEBAQUABIGAP5DA
iLTHG5tTYTW5TReC7YvG6LFLthZte1zvypXmHvIRCEuo0AB+2RJIbtVRd7jmhlxtCnEm9Ap6
xd7v+LHyuO9ZRSSiz22tVMSTNLqHg60kRAJNZSgvkCMZPxm8m3GA6kdi98KNwKWttKisLkcb
IE1qi8sUskz5zd8Xmqg5hBUAAAAAAAA=
--------------ms090606020105040900090503--



From owner-ietf-ldup@mail.imc.org  Thu Mar 27 14:03:23 2003
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13062
	for ; Thu, 27 Mar 2003 14:03:23 -0500 (EST)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.6) id h2RIvsk04224
	for ietf-ldup-bks; Thu, 27 Mar 2003 10:57:54 -0800 (PST)
Received: from pretender.boolean.net (router.boolean.net [198.144.206.49])
	by above.proper.com (8.11.6/8.11.6) with ESMTP id h2RIvlg04217
	for ; Thu, 27 Mar 2003 10:57:47 -0800 (PST)
Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1])
	by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h2RIuaBT096890;
	Thu, 27 Mar 2003 18:57:01 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.2.0.9.0.20030326173336.01a37ed0@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Thu, 27 Mar 2003 10:54:24 -0800
To: capple@dsi-consulting.net
From: "Kurt D. Zeilenga" 
Subject: milestones (Revised WG Charter Proposal)
Cc: ietf-ldup@imc.org
In-Reply-To: <3E772A4B.8040205@netscape.com>
References: <001201c2ed44$df5b8030$322c390a@D7ST2111>
 <001201c2ed44$df5b8030$322c390a@D7ST2111>
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 this point, "revising" and "WG last call" milestones seem
quite pointless and meaningless to me (because they can be
declared "Done" without actually making any forward progress).

We need "we think we're done" milestones.  I strongly suggest
that for each I-D we include a milestone of the form:

DATE	Progress FOO I-D to the IESG for consideration as a
	BAR RFC

where DATE is the date which this WG commits to completing
its work on the I-D (excepting post-IESG-progression work),
FOO is the name of the I-D, and BAR is indicative of the
track which the I-D is to be considered for.

Kurt



From owner-ietf-ldup@mail.imc.org  Thu Mar 27 17:22:09 2003
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22178
	for ; Thu, 27 Mar 2003 17:22:09 -0500 (EST)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.6) id h2RME2216632
	for ietf-ldup-bks; Thu, 27 Mar 2003 14:14:02 -0800 (PST)
Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49])
	by above.proper.com (8.11.6/8.11.6) with ESMTP id h2RME0g16628
	for ; Thu, 27 Mar 2003 14:14:00 -0800 (PST)
Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1])
	by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h2RMDfBT098101;
	Thu, 27 Mar 2003 22:13:44 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.2.0.9.0.20030327134718.028bab00@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Thu, 27 Mar 2003 14:11:41 -0800
To: 
From: "Kurt D. Zeilenga" 
Subject: Re: WG Charter Proposal v2
Cc: , "John Strassner" 
In-Reply-To: <000501c2eed6$5c6a5640$555990ac@D7ST2111>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


In reading the proposed WG description, I found a discussion
of this WG "was originally chartered" to deliver but I couldn't
any statement as what the WG "is chartered" to delivered,
nor could I find any statement of what work is considered
beyond the scope of the WG.

I note as well that this charter doesn't detail all the new
work discussed in "Proposal 1" which WG consensus was declared
for.

http://www.imc.org/ietf-ldup/mail-archive/msg01630.html (Proposals 1 & 2)
http://www.imc.org/ietf-ldup/mail-archive/msg01655.html (Consensus declaration)

There seems to be major discontinuities between this
charter proposal and "Proposal 1". 

Kurt


At 03:46 AM 3/20/2003, Chris Apple wrote:

>Description of Working Group:
>
>As LDAPv3 becomes more widely deployed, replication of data
>across servers running different implementations becomes an
>important part of providing a distributed directory service.
>However, the LDAPv3 community, to date, has focused on
>standardizing the client-server access protocol. This group
>was originally chartered to standardize master-slave and
>multi-master LDAPv3 replication as defined below:
>
>o Multi-Master Replication - A replication model where
>  entries can be written and updated on any of several
>  replica copies, without requiring communication with
>  other masters before the write or update is performed. 
>
>o Master-Slave, or Single-Master Replication - A replication
>  model that assumes only one server, the master, allows
>  write access to the replicated data. Note that
>  Master-Slave replication can be considered a proper
>  subset of multi-master replication. 
>
>The WG's approach was to first develop a set of requirements
>for LDAPv3 directory replication and write an applicability
>statement defining scenarios on which replication requirements
>are based. An engineering team was formed consisting of different
>vendors and the co-chairs in order to harmonize the existing
>approaches into a single standard approach. All of these have
>been accomplished during the pre-working group stage. It should
>be noted, however, that replication using heterogeneous servers
>is dependent on resolving access control issues, which were
>the domain of other working groups. Because the responsible
>WG failed to achieve consensus on a standard access control
>model for LDAPv3, the LDUP WG formed a design team to explore
>the issue of how to address the lack of such a model
>in the context of LDAPv3 replication. This design team made
>recommendations to the working group. The working group
>considered these recommendations and consensus was
>established on addressing these recommendations in
>the context of revising other working group deliverables
>rather than adding new deliverables specific to access
>control for replication. Largely because of the lack of
>a standard access control model for LDAPv3, the working
>group also established consensus on pursuing an experimental
>or informational publication path for a majority of working
>group documents formerly intended to become proposed standards.
>
>The new replication architecture supports all forms of
>replication mentioned above. Seven areas of working group
>focus have been identified through LDUP Engineering Team
>discussions, each leading to one or more documents to be
>published: 
>
>o LDAPv3 Replication Architecture 
>
>   This documents a general-purpose LDAPv3 replication
>   architecture, defines key components of this architecture,
>   describes how these key components functionally behave,
>   and describes how these components interact with each
>   other when in various modes of operation 
>
>o LDAPv3 Replication Information Model 
>
>   Defines the schema and semantics of information used to
>   operate, administer, maintain, and provision replication
>   between LDAPv3 servers. Specifically, this document will
>   contain common schema specifications intended to
>   facilitate interoperable implementations with respect to: 
>
>      + replication agreements 
>
>      + consistency models 
>
>      + replication topologies 
>
>      + managing deleted objects and their states 
>
>      + administration and management 
>
>o LDAPv3 Replication Information Transport Protocol 
>
>   LDAPv3 extended operation and control specifications
>   required to allow LDAPv3 to be used as the transport
>   protocol for information being replicated 
>
>o LDAPv3 Mandatory Replica Management 
>
>   Specifications required to allow administration,
>   maintenance, and provisioning of replicas and
>   replication agreements. These specifications may
>   take the form of definitions for LDAPv3 extended
>   operations, controls, and/or new schema elements. 
>
>o LDAPv3 Update Reconciliation Procedures 
>
>   Procedures for detection and resolution of conflicts
>   between the state of multiple replicas that contain
>   information from the same unit of replication. 
>
>o LDAPv3 Profiles 
>
>   Including the LDAPv3 Replication Architecture,
>   Information Model, Protocol Extensions, and Update
>   Reconciliation Procedures for: 
>
>        + LDAPv3 Replication General Usage
>
>        + LDAPv3 Single-Master Directory Replication 
>
>      + LDAPv3 Multi-Master Directory Replication 
>
>o LDAPv3 Client Update 
>
>   A protocol that enables an LDAP client to
>   synchronize with the content of a directory
>   information tree (DIT) stored by an LDAP server
>   and to be notified about the changes to that
>   content. 
>
>The work being done in the LDUP WG should be coordinated
>to the closest extent possible with similar work being done
>in the ITU. This is necessary both because LDAP depends
>on X.500 and because it makes sense from an operational
>perspective. 
>
>Goals and Milestones:
>
>Done    Submit I-D on LDAPv3 Directory Replication Requirements.  
>Done    Submit I-D on LDAPv3 Replication Information Model  
>Done    Submit I-D on LDAPv3 Update Reconciliation Procedures.  
>Done    Revise I-D on LDAPv3 Directory Replication Requirements.  
>Done    Revise I-D on LDAPv3 Replication Architecture.  
>Done    Revise I-D on LDAPv3 Replication Information Model.  
>Done    Submit I-D on LDAPv3 Replication Information Transport Protocol.  
>Done    Revise I-D on LDAPv3 Replication Architecture.  
>Done    LDAPv3 Directory Replication Requirements I-D goes to WG Last Call
>as Informational.  
>Done    Submit I-D on LDAPv3 Mandatory Replica Management.
>Done      Submit I-D on LDAPv3 Replication General Usage Profile.
>Done      LDAPv3 Client Update Protocol I-D goes to WG Last Call as Proposed
>Standard.
>Done    Revise LDAPv3 Client Update Protocol I-D.
>
>APR 03  Revise LDAPv3 Replication Information Model I-D.
>APR 03  Revise LDAPv3 Client Update Protocol I-D.
>
>MAY 03  Revise LDAPv3 Update Reconciliation Procedures I-D.
>MAY 03  Revise LDAPv3 Replication Architecture I-D.
>MAY 03  Revise LDAPv3 Replication Information Transport Protocol I-D.
>MAY 03  Revise LDAPv3 Mandatory Replica Management I-D.
>MAY 03  LDAPv3 Client Update Protocol I-D goes to WG Last Call as Proposed
>Standard.  
>
>JUN 03  Revise LDAPv3 Replication General Usage Profile I-D.
>JUN 03  Submit I-D on LDAPv3 Single-Master Directory Replication Profile.
>JUN 03  Submit I-D on LDAPv3 Multi-Master Directory Replication Profile.
>JUN 03  LDAPv3 Replication Information Model I-D goes to WG Last Call as
>Informational.
>JUN 03  LDAPv3 Replication Architecture I-D goes to WG Last Call as
>Informational.
>
>JUL 03  Revise LDAPv3 Single-Master Directory Replication Profile I-D.
>JUL 03  Revise LDAPv3 Multi-Master Directory Replication Profile I-D.
>JUL 03  Revise LDAPv3 Update Reconciliation Procedures I-D.
>JUL 03  Revise LDAPv3 Replication Information Transport Protocol I-D.
>JUL 03  Revise LDAPv3 Mandatory Replica Management I-D.
>JUL 03  Evaluate Deliverables Status
>
>AUG 03  LDAPv3 Update Reconciliation Procedures I-D goes to WG Last Call as
>Experimental.
>AUG 03  LDAPv3 Replication Information Transport Protocol I-D goes to WG
>Last Call as Experimental.
>AUG 03  LDAPv3 Mandatory Replica Management I-D goes to WG Last Call as
>Experimental.
>
>SEP 03  LDAPv3 Replication General Usage Profile I-D goes to WG Last Call as
>Informational.
>SEP 03  LDAPv3 Single-Master Directory Replication Profile I-D goes to WG
>Last Call as Informational.
>SEP 03  LDAPv3 Multi-Master Directory Replication Profile I-D goes to WG
>Last Call as Informational.
>
>Chris Apple - Principal Architect
>
>DSI Consulting, Inc.
>
>mailto:capple@dsi-consulting.net
>
>http://www.dsi-consulting.com



From owner-ietf-ldup@mail.imc.org  Mon Mar 31 13:51:45 2003
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18911
	for ; Mon, 31 Mar 2003 13:51:44 -0500 (EST)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VIeVJM002226
	for ; Mon, 31 Mar 2003 10:40:31 -0800 (PST)
Received: (from majordomo@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h2VIeVar002225
	for ietf-ldup-bks; Mon, 31 Mar 2003 10:40:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-ldup@mail.imc.org using -f
Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238])
	by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VIeNJM002216
	for ; Mon, 31 Mar 2003 10:40:26 -0800 (PST)
Received: from D7ST2111
	(pool-141-150-235-85.delv.east.verizon.net [141.150.235.85])
	by dns.caledonia.net; Mon, 31 Mar 2003 11:39:51 -0700
Reply-To: 
From: "Chris Apple" 
To: 
Subject: RE: WG Charter Proposal v2
Date: Mon, 31 Mar 2003 13:39:08 -0500
Organization: DSI-Consulting, Inc.
Message-ID: <00b501c2f7b4$ddd987f0$0300a8c0@D7ST2111>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
In-Reply-To: <5.2.0.9.0.20030327134718.028bab00@127.0.0.1>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h2VIeUJM002221
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 
Content-Transfer-Encoding: 8bit


Comments embedded below.

Chris.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] 
Sent: Thursday, March 27, 2003 5:12 PM
To: capple@dsi-consulting.net
Cc: ietf-ldup@imc.org; John Strassner
Subject: Re: WG Charter Proposal v2


In reading the proposed WG description, I found a discussion
of this WG "was originally chartered" to deliver but I couldn't
any statement as what the WG "is chartered" to delivered,

CWA> There is language there which treats this topic as implicit.
     I have included some additional text below to make the connection
     between the original WG direction and the new WG direction more
     explicit. This additional text is incorporated into the WG
     description as included by you in the posting to which I am
     replying now.

nor could I find any statement of what work is considered
beyond the scope of the WG.

CWA> If you have suggestions for how to phrase what work is
     out of scope for LDUP in a sentence or two, I'm certainly
     open to considering its inclusion. Otherwise, without a
     "second" from a few other WG members, I will have to treat
     this comment as an isolated one and one that doesn't
     represent consensus.

I note as well that this charter doesn't detail all the new
work discussed in "Proposal 1" which WG consensus was declared
for.

http://www.imc.org/ietf-ldup/mail-archive/msg01630.html (Proposals 1 & 2)
http://www.imc.org/ietf-ldup/mail-archive/msg01655.html (Consensus
declaration)

There seems to be major discontinuities between this
charter proposal and "Proposal 1".


CWA> I do not agree with the observation you have made
     above.

     First, proposal 1 does not require new work.
     Proposal 1 keeps existing, planned work and changes
     the originally intended publication track from
     standards to a combination of experimental and
     informational documents.

     Second, proposal 1 does mention that X.500 BAC
     will be referenced; this also doesn't qualify
     as new work as it was the intention of the LDUP WG
     to reference ACM work produced by another WG. Because
     this other WG didn't produce such a standard,
     proposal 1 simply changes the reference source to
     a document that does exist. This does not constitute
     new work.

     Third, while the details of the recommendations made
     by the design team are not reflected verbatim in the
     revised WG description, there are no discontinuities
     between what we intend to do as a WG (as reflected
     in mailing list and WG meeting discussions), proposal 1,
     or the revised WG description. The only significant
     distinguishing factor between these expressions of
     our intent is the level of specificity observable in
     each.

     The only aspect of proposal 1 which is not explicitly
     reflected in some way in the revised WG charter
     description is that we plan to reference X.500 BAC
     and in which documents this reference will be made.
     I believe that including this level of specificity in
     a WG description for a charter would be a mistake because
     there are several documents in which we could reference
     X.500 BAC. Evaluating each requires that the WG consider
     a contextual reference in an actual document. And there
     is more than one way of referencing X.500 BAC (directly
     or indirectly - as in an I-D that explains how to use it
     in the context of LDAPv3). We do not know which ways will
     be appropriate without evaluating them and therefore this
     should not be specified in a WG charter.

     Now, I would think it perfectly reasonable of you to propose
     alternate language to include or to replace existing language
     if you believe such language clarifies the charter. Please
     post any such contributions with specific language additions
     and replacements on or before the deadline for comments.

     The WG Charter Revision review period will continue per
     the original posting on this thread and as corrected
     in the follow up posting I made to the original.

     

Kurt  


At 03:46 AM 3/20/2003, Chris Apple wrote:

>Description of Working Group:
>
>As LDAPv3 becomes more widely deployed, replication of data
>across servers running different implementations becomes an
>important part of providing a distributed directory service.
>However, the LDAPv3 community, to date, has focused on
>standardizing the client-server access protocol. This group
>was originally chartered to standardize master-slave and
>multi-master LDAPv3 replication as defined below:
>
>o Multi-Master Replication - A replication model where
>  entries can be written and updated on any of several
>  replica copies, without requiring communication with
>  other masters before the write or update is performed. 
>
>o Master-Slave, or Single-Master Replication - A replication
>  model that assumes only one server, the master, allows
>  write access to the replicated data. Note that
>  Master-Slave replication can be considered a proper
>  subset of multi-master replication. 
>




Recently, the WG established consensus on a change of
direction to pursue publication of a standards track
protocol for LDAPv3 client synchronization, an experimental
LDAPv3 replication protocol, and supporting informational
documents. Thus the new work program is largely the same
as the original work program with one notable exception,
the LDAPv3 replication protocol is intended to be an
experimental rather than a standards track protocol.

>The WG's approach was to first develop a set of requirements
>for LDAPv3 directory replication and write an applicability
>statement defining scenarios on which replication requirements
>are based. An engineering team was formed consisting of different
>vendors and the co-chairs in order to harmonize the existing
>approaches into a single standard approach. All of these have
>been accomplished during the pre-working group stage. It should
>be noted, however, that replication using heterogeneous servers
>is dependent on resolving access control issues, which were
>the domain of other working groups. Because the responsible
>WG failed to achieve consensus on a standard access control
>model for LDAPv3, the LDUP WG formed a design team to explore
>the issue of how to address the lack of such a model
>in the context of LDAPv3 replication. This design team made
>recommendations to the working group. The working group
>considered these recommendations and consensus was
>established on addressing these recommendations in
>the context of revising other working group deliverables
>rather than adding new deliverables specific to access
>control for replication. Largely because of the lack of
>a standard access control model for LDAPv3, the working
>group also established consensus on pursuing an experimental
>or informational publication path for a majority of working
>group documents formerly intended to become proposed standards.
>
>The new replication architecture supports all forms of
>replication mentioned above. Seven areas of working group
>focus have been identified through LDUP Engineering Team
>discussions, each leading to one or more documents to be
>published: 
>
>o LDAPv3 Replication Architecture 
>
>   This documents a general-purpose LDAPv3 replication
>   architecture, defines key components of this architecture,
>   describes how these key components functionally behave,
>   and describes how these components interact with each
>   other when in various modes of operation 
>
>o LDAPv3 Replication Information Model 
>
>   Defines the schema and semantics of information used to
>   operate, administer, maintain, and provision replication
>   between LDAPv3 servers. Specifically, this document will
>   contain common schema specifications intended to
>   facilitate interoperable implementations with respect to: 
>
>      + replication agreements 
>
>      + consistency models 
>
>      + replication topologies 
>
>      + managing deleted objects and their states 
>
>      + administration and management 
>
>o LDAPv3 Replication Information Transport Protocol 
>
>   LDAPv3 extended operation and control specifications
>   required to allow LDAPv3 to be used as the transport
>   protocol for information being replicated 
>
>o LDAPv3 Mandatory Replica Management 
>
>   Specifications required to allow administration,
>   maintenance, and provisioning of replicas and
>   replication agreements. These specifications may
>   take the form of definitions for LDAPv3 extended
>   operations, controls, and/or new schema elements. 
>
>o LDAPv3 Update Reconciliation Procedures 
>
>   Procedures for detection and resolution of conflicts
>   between the state of multiple replicas that contain
>   information from the same unit of replication. 
>
>o LDAPv3 Profiles 
>
>   Including the LDAPv3 Replication Architecture,
>   Information Model, Protocol Extensions, and Update
>   Reconciliation Procedures for: 
>
>        + LDAPv3 Replication General Usage
>
>        + LDAPv3 Single-Master Directory Replication 
>
>      + LDAPv3 Multi-Master Directory Replication 
>
>o LDAPv3 Client Update 
>
>   A protocol that enables an LDAP client to
>   synchronize with the content of a directory
>   information tree (DIT) stored by an LDAP server
>   and to be notified about the changes to that
>   content. 
>
>The work being done in the LDUP WG should be coordinated
>to the closest extent possible with similar work being done
>in the ITU. This is necessary both because LDAP depends
>on X.500 and because it makes sense from an operational
>perspective. 
>
>Goals and Milestones:
>
>Done    Submit I-D on LDAPv3 Directory Replication Requirements.  
>Done    Submit I-D on LDAPv3 Replication Information Model  
>Done    Submit I-D on LDAPv3 Update Reconciliation Procedures.  
>Done    Revise I-D on LDAPv3 Directory Replication Requirements.  
>Done    Revise I-D on LDAPv3 Replication Architecture.  
>Done    Revise I-D on LDAPv3 Replication Information Model.  
>Done    Submit I-D on LDAPv3 Replication Information Transport Protocol.  
>Done    Revise I-D on LDAPv3 Replication Architecture.  
>Done    LDAPv3 Directory Replication Requirements I-D goes to WG Last Call
>as Informational.  
>Done    Submit I-D on LDAPv3 Mandatory Replica Management.
>Done      Submit I-D on LDAPv3 Replication General Usage Profile.
>Done      LDAPv3 Client Update Protocol I-D goes to WG Last Call as
Proposed
>Standard.
>Done    Revise LDAPv3 Client Update Protocol I-D.
>
>APR 03  Revise LDAPv3 Replication Information Model I-D.
>APR 03  Revise LDAPv3 Client Update Protocol I-D.
>
>MAY 03  Revise LDAPv3 Update Reconciliation Procedures I-D.
>MAY 03  Revise LDAPv3 Replication Architecture I-D.
>MAY 03  Revise LDAPv3 Replication Information Transport Protocol I-D.
>MAY 03  Revise LDAPv3 Mandatory Replica Management I-D.
>MAY 03  LDAPv3 Client Update Protocol I-D goes to WG Last Call as Proposed
>Standard.  
>
>JUN 03  Revise LDAPv3 Replication General Usage Profile I-D.
>JUN 03  Submit I-D on LDAPv3 Single-Master Directory Replication Profile.
>JUN 03  Submit I-D on LDAPv3 Multi-Master Directory Replication Profile.
>JUN 03  LDAPv3 Replication Information Model I-D goes to WG Last Call as
>Informational.
>JUN 03  LDAPv3 Replication Architecture I-D goes to WG Last Call as
>Informational.
>
>JUL 03  Revise LDAPv3 Single-Master Directory Replication Profile I-D.
>JUL 03  Revise LDAPv3 Multi-Master Directory Replication Profile I-D.
>JUL 03  Revise LDAPv3 Update Reconciliation Procedures I-D.
>JUL 03  Revise LDAPv3 Replication Information Transport Protocol I-D.
>JUL 03  Revise LDAPv3 Mandatory Replica Management I-D.
>JUL 03  Evaluate Deliverables Status
>
>AUG 03  LDAPv3 Update Reconciliation Procedures I-D goes to WG Last Call as
>Experimental.
>AUG 03  LDAPv3 Replication Information Transport Protocol I-D goes to WG
>Last Call as Experimental.
>AUG 03  LDAPv3 Mandatory Replica Management I-D goes to WG Last Call as
>Experimental.
>
>SEP 03  LDAPv3 Replication General Usage Profile I-D goes to WG Last Call
as
>Informational.
>SEP 03  LDAPv3 Single-Master Directory Replication Profile I-D goes to WG
>Last Call as Informational.
>SEP 03  LDAPv3 Multi-Master Directory Replication Profile I-D goes to WG
>Last Call as Informational.
>
>Chris Apple - Principal Architect
>
>DSI Consulting, Inc.
>
>mailto:capple@dsi-consulting.net
>
>http://www.dsi-consulting.com





From owner-ietf-ldup@mail.imc.org  Mon Mar 31 20:07:42 2003
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05388
	for ; Mon, 31 Mar 2003 20:07:41 -0500 (EST)
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.9/8.11.6) with ESMTP id h310qhJM023057
	for ; Mon, 31 Mar 2003 16:52:43 -0800 (PST)
Received: (from majordomo@localhost)
	by above.proper.com (8.12.9/8.12.9/Submit) id h310qhxX023056
	for ietf-ldup-bks; Mon, 31 Mar 2003 16:52:43 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-ldup@mail.imc.org using -f
Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49])
	by above.proper.com (8.12.9/8.11.6) with ESMTP id h310qfJM023052
	for ; Mon, 31 Mar 2003 16:52:42 -0800 (PST)
Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1])
	by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h310qgBT032588;
	Tue, 1 Apr 2003 00:52:42 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.2.0.9.0.20030331162717.02117ad0@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 31 Mar 2003 16:50:14 -0800
To: 
From: "Kurt D. Zeilenga" 
Subject: RE: WG Charter Proposal v2
Cc: 
In-Reply-To: <00b501c2f7b4$ddd987f0$0300a8c0@D7ST2111>
References: <5.2.0.9.0.20030327134718.028bab00@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 


Chris, at IETF#56, you made some comments regarding problems this group had in
the past with referencing individual I-D and how you, as chair, would require
that all of the individual I-Ds which this WG depended upon would be brought
into the WG and treated as WG I-Ds.  Can you clarify what your intended to say
at IETF#56 with regard to WG handling of these individual I-Ds?  Thanks, Kurt