Internet Draft Ed Reed Document: draft-ietf-ldup-infomod-03.txt Reed-Matthews, Inc Expires: January 2002 T. Hahn IBM July 2001 LDUP Replication Information Model 1. 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 January, 2002. 2. 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 (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. Reed Standards Track - Expires January 2002 [Page 1] LDUP Information Model 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. Reed Standards Track - Expires January 2002 [Page 2] LDUP Information Model 3. 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.................................11 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......................................14 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...........................................17 8.2.20. attrs1...................................................18 8.2.21. secondsToWait2...........................................18 8.2.22. attrs2...................................................18 8.2.23. scheduleTimePeriod.......................................19 8.2.24. scheduleMonthOfYearMask..................................19 8.2.25. scheduleDayOfMonthMask...................................19 8.2.26. scheduleDayOfWeekMask....................................19 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 Reed Standards Track - Expires January 2002 [Page 3] LDUP Information Model 8.3.3. replicaAgreementSubentry.................................22 8.3.4. replicaEventSchedule.....................................23 8.3.5. replicaTimeSchedule......................................24 9. Semantics of the information model............................25 10. Object Identifier Assignments...............................28 11. Security Considerations.....................................29 12. Copyright Notice............................................30 13. Acknowledgements............................................31 14. AuthorsÆ Addresses..........................................31 Reed Standards Track - Expires January 2002 [Page 4] LDUP Information Model 4. Recent document changes Changes in this version ¡ 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 Changes made to previous revisions ¡ 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 eleminated 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. ¡ 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 histeresis buckets, and cron-like thing. Then, the replica has a single Reed Standards Track - Expires January 2002 [Page 5] LDUP Information Model 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 ¡ Followup 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 Reed Standards Track - Expires January 2002 [Page 6] LDUP Information Model 5. Introduction 5.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. 5.2. Terms and Definitions Definitions are provided in [LDUP Requirements], and may be reproduced here for the convenience of the reader. 6. 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. 7. 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. Reed Standards Track - Expires January 2002 [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 (ie, 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. 8. Schema 8.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]. Reed Standards Track - Expires January 2002 [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. 8.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 whitespace 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 whitespace, 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 Reed Standards Track - Expires January 2002 [Page 9] LDUP Information Model occurred. Note that in actual transfer, the ReplicaID MAY be represented by a number (see the specification of the replicaLookupTable, above). 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. 8.2. Attribute Definitions 8.2.1. supportedReplicationProtocols ( 2.16.840.1.113719.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]. 8.2.2. replicaContextRoots ( 2.16.840.1.113719.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 replicaContextRootss 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 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. Reed Standards Track - Expires January 2002 [Page 10] LDUP Information Model 8.2.3. replicaSubentries ( 2.16.840.1.113719.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. 8.2.4. attributeExclusionFilter ( 2.16.840.1.113719.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. A non-empty attributeExclusionFilter attribute on a replicationAgreement subEntry describes which additional attributes are to be excluded from the updates to be sent from the supplier replica to the consumer replica. 8.2.5. attributeInclusionFilter ( 2.16.840.1.113719.142.4.2 NAME 'attributeInclusionFilter' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) Reed Standards Track - Expires January 2002 [Page 11] LDUP Information Model 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 attributeIncludionFilter and attributeExclusionFilter attributes on their replica subEntry. 8.2.6. replicaURI ( 2.16.840.1.113719.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. 8.2.7. replicationStatus (2.16.840.1.113719.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 replicationAgreement. 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 Reed Standards Track - Expires January 2002 [Page 12] LDUP Information Model 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. 8.2.8. replicaType (2.16.840.1.113719.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). 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 Reed Standards Track - Expires January 2002 [Page 13] LDUP Information Model 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. 8.2.9. updateVector ( 2.16.840.1.113719.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. 8.2.10. replicaSecondaryURI ( 2.16.840.1.113719.142.4.x NAME æreplicaSecondaryURIÆ 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 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. 8.2.11. lostAndFoundEntryDN ( 2.16.840.1.113719.142.4.x NAME ælostAndFoundEntryDNÆ Reed Standards Track - Expires January 2002 [Page 14] LDUP Information Model 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. 8.2.12. replicaOnline ( 2.16.840.1.113719.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. 8.2.13. replicaDN ( 2.16.840.1.113719.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 contrained by the replicaAgreementSubentry. 8.2.14. replicationMechanismOID ( 2.16.840.1.113719.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 Reed Standards Track - Expires January 2002 [Page 15] LDUP Information Model must be a value that is within the set of attribute values for the supportedReplicationProtocols attribute in the root DSE entry. 8.2.15. replicationCredentialsDN ( 2.16.840.1.113719.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. 8.2.16. replicationScheduleDN ( 2.16.840.1.113719.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. 8.2.17. updateVectorTrigger ( 2.16.840.1.113719.142.4.x NAME æupdateVectorTriggerÆ 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 replicaÆs 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 Reed Standards Track - Expires January 2002 [Page 16] LDUP Information Model 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. 8.2.18. secondsToWaitDefault (2.16.840.1.113719.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. 8.2.19. secondsToWait1 (2.16.840.1.113719.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.' Reed Standards Track - Expires January 2002 [Page 17] LDUP Information Model 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. 8.2.20. attrs1 ( 2.16.840.1.113719.142.4.x NAME æattrs1Æ 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 relication session will be initiated. 8.2.21. secondsToWait2 (2.16.840.1.113719.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. 8.2.22. attrs2 ( 2.16.840.1.113719.142.4.x NAME æattrs2Æ 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, Reed Standards Track - Expires January 2002 [Page 18] LDUP Information Model 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 relication session will be initiated. 8.2.23. scheduleTimePeriod ( 2.16.840.1.113719.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. 8.2.24. scheduleMonthOfYearMask ( 2.16.840.1.113719.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. 8.2.25. scheduleDayOfMonthMask ( 2.16.840.1.113719.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 these references for details on the format and interpretation of this attribute. 8.2.26. scheduleDayOfWeekMask ( 2.16.840.1.113719.142.4.x NAME æscheduleDayOfWeekMaskÆ SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 SINGLE-VALUE Reed Standards Track - Expires January 2002 [Page 19] LDUP Information Model 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. 8.2.27. scheduleTimeOfDayMask ( 2.16.840.1.113719.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. 8.2.28. scheduleLocalOrUtcTime ( 2.16.840.1.113719.142.4.x NAME æscheduleTimeOfDayMaskÆ 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. 8.3. Class Definitions 8.3.1. ReplicationContext ( 2.16.840.1.113719.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 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. Reed Standards Track - Expires January 2002 [Page 20] LDUP Information Model The attribute accessControlPolicyOID has been removed from here, and should be published as an ldapSubEntry 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 objectClasses attribute serves the same purpose. 8.3.2. replicaSubentry ( 2.16.840.1.113719.142.6.3.2 NAME 'replicaSubentry-2' SUP ldapSubEntry AUXILIARY MUST ( cn $ replicaURI $ replicaType $ lostAndFoundEntryDN $ replicaOnline ) MAY ( attributeExclusionFilter $ attributeInclusionFilter $ replicaSecondaryURI $ description $ updateVector ) ) Entries of type replicaSubentry MAY be named by their cn attribute. As an AUXILIARY class, the replicaSubentry MAY share a structural subentry with other AUXILIARY classes. 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 (ie, 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. 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. Reed Standards Track - Expires January 2002 [Page 21] LDUP Information Model 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. 8.3.3. replicaAgreementSubentry ( 2.16.840.1.113719.142.6.4.2 NAME 'replicaAgreementSubentry-2' SUP ldapSubEntry AUXILIARY MUST ( cn ) MAY ( attributeExclusionFilter $ description $ replicaDN $ replicationMechanismOID $ replicationStatus $ replicationCredentialsDN $ replicationScheduleDN ) ) Entries of type replicaAgreementSubentry MAY be named by their cn attribute. As an AUXILIARY class, a replicaAgreementSubentry MAY be applied to a STRUCTURAL subentry, along with other AUXILIARY classes. A replicaAgreementSubentry MAY NOT decorate the same subentry as the replicaSubentry to which it is subordinate. Name subordination is used to associate a replicaAgreementSubentry with the replicaSubentry representing the supplier of changes for all subordinate replicaAgreements. 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: 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. Reed Standards Track - Expires January 2002 [Page 22] LDUP Information Model 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. 8.3.4. replicaEventSchedule ( 2.16.840.1.113719.142.6.x.1 NAME 'replicaEventSchedule' SUP ldapSubEntry AUXILIARY 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. Reed Standards Track - Expires January 2002 [Page 23] LDUP Information Model 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 replicated before its associated seconds-to-wait time period had expired. 8.3.5. replicaTimeSchedule ( 2.16.840.1.113719.142.6.x.1 NAME 'replicaTimeSchedule' SUP ldapSubEntry AUXILIARY MUST ( cn ) MAY ( description $ scheduleTimePeriod $ scheduleMonthOfYearMask $ scheduleDayOfMonthMask $ scheduleDayOfWeekMask $ scheduleTimeOfDayMask $ scheduleLocalOrUtcTime ) ) Reed Standards Track - Expires January 2002 [Page 24] LDUP Information Model 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. 9. 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. 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: ldapSubentry objectclass: replicaSubentry-2 cn: replica1 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: ldapSubentry objectclass: replicaSubentry-2 cn: replica2 Reed Standards Track - Expires January 2002 [Page 25] LDUP Information Model 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: ldapSubentry objectclass: replicaSubentry-2 cn: replica3 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 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: ldapSubentry objectclass: replicaAgreementSubentry-2 cn: agreement1->2 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: ldapSubentry objectclass: replicaAgreementSubentry-2 cn: agreement1->3 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: ldapSubentry objectclass: replicaEventSchedule cn: schedule1 description: schedule that initiates replication one minute after any update (including to the updateVector) is made Reed Standards Track - Expires January 2002 [Page 26] LDUP Information Model to the replica. secondsToWaitDefault: 60 updateVectorTrigger: TRUE dn: cn=agreement2->1, cn=replica2, ou=accounting, o=your company objectclass: ldapSubentry objectclass: replicaAgreementSubentry-2 cn: agreement2->1 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: ldapSubentry objectclass: replicaAgreementSubentry-2 cn: agreement2->3 description: Replica agreement constraining replication sessions from replica 2 to replica 3. replicationScheduleDN: cn=schedule2, cn=replica2, ou=accounting, o=your company dn: cn=schedule2, cn=replica2, ou=accounting, o=your company objectclass: ldapSubentry objectclass: replicaEventSchedule cn: schedule2 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: ldapSubentry objectclass: replicaAgreementSubentry-2 cn: agreement3->1 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: ldapSubentry objectclass: replicaAgreementSubentry-2 cn: agreement3->2 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: ldapSubentry objectclass: replicaEventSchedule cn: schedule3 Reed Standards Track - Expires January 2002 [Page 27] LDUP Information Model 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 ôcontrainsö 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 offer schema that would support the creation of these complex policies. 10. 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) ldup(142) } The OID assignments defined in this document are: Attributes: AttributeExclusionFilter ID ::= 2.16.840.1.113719.142.4.1 AttributeInclusionFilter ID ::= 2.16.840.1.113719.142.4.2 replicationStatus ID ::= 2.16.840.1.113719.142.4.3 replicaType ID ::= 2.16.840.1.113719.142.4.4 updateVector ID ::= 2.16.840.1.113719.142.4.6 replicaURI ID ::= 2.16.840.1.113719.142.4.x replicaSecondaryURI ID ::= 2.16.840.1.113719.142.4.x lostAndFoundEntryDN ID ::= 2.16.840.1.113719.142.4.x replicaOnline ID ::= 2.16.840.1.113719.142.4.x replicaDN ID ::= 2.16.840.1.113719.142.4.x replicationMechanismOID ID ::= 2.16.840.1.113719.142.4.x replicationCredentialsDN ID ::= 2.16.840.1.113719.142.4.x replicationScheduleDN ID ::= 2.16.840.1.113719.142.4.x updateVectorTrigger ID ::= 2.16.840.1.113719.142.4.x secondsToWaitDefault ID ::= 2.16.840.1.113719.142.4.x secondsToWait1 ID ::= 2.16.840.1.113719.142.4.x attrs1 ID ::= 2.16.840.1.113719.142.4.x secondsToWait2 ID ::= 2.16.840.1.113719.142.4.x attrs2 ID ::= 2.16.840.1.113719.142.4.x scheduleTimePeriod ID ::= 2.16.840.1.113719.142.4.x Reed Standards Track - Expires January 2002 [Page 28] LDUP Information Model scheduleMonthOfYearMask ID ::= 2.16.840.1.113719.142.4.x scheduleDayOfMonthMask ID ::= 2.16.840.1.113719.142.4.x scheduleDayOfWeekMask ID ::= 2.16.840.1.113719.142.4.x scheduleTimeOfDayMask ID ::= 2.16.840.1.113719.142.4.x scheduleLocalOrUtcTime ID ::= 2.16.840.1.113719.142.4.x supportedReplicationProtocols ID ::= 2.16.840.1.113719.142.4.x replicaContextRoots ID ::= 2.16.840.1.113719.142.4.x replicaSubentries ID ::= 2.16.840.1.113719.142.4.x Object Classes: nameContext ID ::= 2.16.840.1.113719.142.6.2.1 - OBSOLETE replicaSubentry ID ::= 2.16.840.1.113719.142.6.3.1 - OBSOLETE replicaAgreementSubentry ID ::= 2.16.840.1.113719.142.6.4.1 û OBSOLETE replicationContext ID ::= 2.16.840.1.113719.142.6.2.2 replicaSubEntry-2 ID ::= 2.16.840.1.113719.142.6.3.2 replicaAgreementSubEntry-2 ID ::= 2.16.840.1.113719.142.6.4.2 replicaEventSchedule ID ::= 2.16.840.1.113719.142.6.x.1 replicaTimeSchedule ID ::= 2.16.840.1.113719.142.6.x.1 Note: Object Class OIDs have version numbers, Attribute OIDs donÆt. 11. 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 Reed Standards Track - Expires January 2002 [Page 29] LDUP Information Model [LDAP Subentry] û E. Reed, ôLDAP Subentry Schemaö, Internet draft, draft-ietf-ldup-subentry-08.txt [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 12. Copyright Notice Copyright (C) The Internet Society (1999). 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 implmentation 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. Reed Standards Track - Expires January 2002 [Page 30] 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." 13. Acknowledgements The use of subEntry object class to store Replica and Replication Agreement information is due primarily to the lucid explanation by Mark Wahl, Innosoft, of how they could be used and extended. 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 implementors 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. 14. AuthorsÆ Addresses Edward E. Reed Reed-Matthews, Inc. 1064 East 140 North Lindon, UT 84042 USA E-mail: eer@oncalldba.com Tim Hahn IBM Bldg 256-2, Dept. C8NG 1701 North St. Endicott, NY 13760 USA E-mail: hahnt@us.ibm.com LDUP Mailing List: ietf-ldup@idc.org Reed Standards Track - Expires January 2002 [Page 31]