One document matched: draft-ietf-ldup-infomod-06.txt
Differences from draft-ietf-ldup-infomod-05.txt
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 <four digit year, e.g. 1998>
mm = dd <two digit month of the year, e.g. 06>
dd = dd <two digit day of month, e.g. 17>
hh = dd <two digit hour of the day, inclusive range (00..23)>
mi = dd <two digit minute of the hour, inclusive range (00..59)>
ss = dd <two digit seconds of the minute, inclusive range (00..59)>
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]
| PAFTECH AB 2003-2026 | 2026-04-24 02:51:56 |