submission: draft-ietf-ldup-infomod-08.txt
Ryan Moats <[email protected]> Wed, 22 Oct 2003 08:21:00 -0500
| Newsgroups | gmane.ietf.ldup |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--------------050608070409010502060409
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
To the I-D editor:
Attached is draft-ietf-ldup-infomod-08.txt for the repository.
To LDUP:
Attached is draft-ietf-ldup-infomod-08.txt, ready for last call. As
such, we've extracted the
document changes section and place it here for reference.
John and Chris, please schedule a last call when you can.
Ryan Moats (for the authors)
===================Recent document changes
Changes in this version (-08)
- Explicitly change replicaAgreement to not be a subentry.
- Explicitly allow multiple replicaSubentries per replicaContext
- Added replicaDN to examples.
- Remove discussion of "Primary" replica.
- Clarify information that must be present in all replicas
(replicaSubentries) and what replicaAgreements and associated
information must be present in a
replica.
Changes made to previous versions
- 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
- 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.- 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.
--------------050608070409010502060409
Content-Type: text/plain;
name="draft-ietf-ldup-infomod-08.txt"
Content-Disposition: inline;
filename="draft-ietf-ldup-infomod-08.txt"
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id h9MDLmI7039992
=20
Internet Draft Richard Huber=20
Document: draft-ietf-ldup-infomod-08.txt AT&T Laboratories=20
Expires: April 30 2004 John McMeeking=20
Intended Category: Experimental IBM=20
Ryan Moats=20
Lemur Networks=20
October 2003=20
=20
LDUP Replication Information Model=20
draft-ietf-ldup-infomod-08.txt=20
=20
=20
1. Status of this Memo=20
=20
This document is an Internet-Draft and is in full conformance=20
with all provisions of Section 10 of RFC2026.=20
=20
=20
Internet-Drafts are working documents of the Internet Engineering=20
Task Force (IETF), its areas, and its working groups. Note that =
=20
other groups may also distribute working documents as Internet-
Drafts.=20
=20
Internet-Drafts are draft documents valid for a maximum of six=20
months and may be updated, replaced, or obsoleted by other=20
documents at any time. It is inappropriate to use Internet-Drafts=20
as reference material or to cite them other than as "work in=20
progress."=20
=20
The list of current Internet-Drafts can be accessed at=20
http://www.ietf.org/ietf/1id-abstracts.txt=20
=20
The list of Internet-Draft Shadow Directories can be accessed at=20
http://www.ietf.org/shadow.html.=20
=20
This Internet-Draft expires March, 2002.=20
=20
=20
2. Abstract=20
=20
[LDUP Model] describes the architectural approach to replication of=20
LDAP directory contents. This document describes the information=20
model and schema elements which support LDAP Replication Services=20
which conform to [LDUP Model].=20
=20
Directory schema are extended to provide object classes,=20
subentries, and attributes to describe areas of the namespace which=20
are under common administrative authority, units of replication=20
(i.e., subtrees, or partitions of the namespace, which are=20
replicated), servers which hold replicas of various types for the=20
various partitions of the namespace, which namespaces are held on=20
given servers, and the progress of various namespace management and=20
replication operations. Among other things, this knowledge of=20
=20
Huber, et al Expires April 2004 [Page 1] =0C
LDUP Information Model =20
where directory content is located will provide the basis for=20
dynamic generation of LDAP referrals for clients who can follow=20
them.=20
=20
The controlling framework by which the relationships, types, and=20
health of replicas of the directory content will be defined so=20
that, as much as possible, directory content is itself used to=20
monitor and control the environment.=20
=20
Security information, including access control policy identifiers=20
and information will be treated as directory content by the=20
replication protocols when specified by the LDAPEXT group. Note=20
that [RFC2820] specifies that access control information must be=20
stored as LDAP attributes. Access control information will be=20
replicated properly under any access control scheme that satisfies=20
this requirement.=20
=20
The information model will describe required and optional house-
keeping duties for compliant systems to implement, such as garbage=20
collection of deleted objects, reconciliation of moved and renamed=20
objects, update sequencing and transaction bracketing of changes,=20
etc.=20
=20
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in=20
this document are to be interpreted as described in RFC 2119=20
[RFC2119]. The sections below reiterate these definitions and=20
include some additional ones.=20
=20
Huber, et al Expires April 2004 [Page 2] =0C
LDUP Information Model =20
=20
3. Table of Contents=20
=20
=20
1. Status of this Memo...........................................1=20
2. Abstract......................................................1=20
3. Table of Contents.............................................3=20
4. Introduction..................................................5=20
4.1. Scope......................................................5=20
4.2. Terms and Definitions......................................5=20
5. Data design...................................................5=20
6. Directory Knowledge...........................................5=20
7. Schema........................................................6=20
7.1. Data Structure Definitions.................................6=20
7.1.1. LdapChangeSequenceNumber.................................7=20
7.2. Attribute Definitions......................................8=20
7.2.1. supportedReplicationProtocols............................8=20
7.2.2. attributeExclusionFilter.................................8=20
7.2.3. attributeInclusionFilter.................................9=20
7.2.4. replicaURI...............................................9=20
7.2.5. replicationStatus.......................................10=20
7.2.6. replicaType.............................................10=20
7.2.7. updateVector............................................11=20
7.2.8. replicaSecondaryURI.....................................11=20
7.2.9. lostAndFoundEntryDN.....................................12=20
7.2.10. replicaOnline...........................................12=20
7.2.11. replicaDN...............................................12=20
7.2.12. replicationMechanismOID.................................12=20
7.2.13. replicationCredentialsDN................................13=20
7.2.14. replicationScheduleDN...................................13=20
7.2.15. updateVectorTrigger.....................................13=20
7.2.16. secondsToWaitDefault....................................14=20
7.2.17. secondsToWait1..........................................14=20
7.2.18. attrReplicationGroup1...................................15=20
7.2.19. secondsToWait2..........................................15=20
7.2.20. attrReplicationGroup2...................................16=20
7.2.21. scheduleTimePeriod......................................16=20
7.2.22. scheduleMonthOfYearMask.................................16=20
7.2.23. scheduleDayOfMonthMask..................................16=20
7.2.24. scheduleDayOfWeekMask...................................17=20
7.2.25. scheduleTimeOfDayMask...................................17=20
7.2.26. scheduleLocalOrUtcTime..................................17=20
7.3. Class Definitions.........................................17=20
7.3.1. ReplicationContext......................................17=20
7.3.2. replicaSubentry.........................................18=20
7.3.3. replicaAgreement........................................19=20
7.3.4. replicaEventSchedule....................................20=20
7.3.5. replicaTimeSchedule.....................................22=20
=20
Huber, et al Expires April 2004 [Page 3] =0C
LDUP Information Model =20
8. Semantics of the information model...........................22=20
9. Object Identifier Assignments................................25=20
10. Security Considerations....................................27=20
11. Copyright Notice...........................................28=20
12. Acknowledgements...........................................29=20
13. Authors' Addresses.........................................29=20
=20
=20
Huber, et al Expires April 2004 [Page 4] =0C
LDUP Information Model =20
=20
4. Introduction=20
=20
4.1. Scope=20
=20
This document describes schema for information used to control=20
replication.=20
=20
Management and status schema elements are defined.=20
=20
Semantic interpretation of schema elements, including any special=20
handling expectations, are provided here.=20
=20
4.2. Terms and Definitions=20
=20
Definitions are provided in [RFC3384].=20
=20
5. Data design=20
=20
As described in [LDUP Model], knowledge of replicated portions of=20
the directory information tree (DIT) is stored in the directory=20
itself.=20
=20
An auxiliary class is defined to designate containers, or nodes, in=20
the DIT which are the root-most, or base, of replication contexts. =20
Directory subentries [LDAP Subentry] are used to hold information=20
about replicas.=20
=20
In defining the replication agreement data model, describing the=20
constraints under which replication between two replicas will=20
occur, this document describes only the least set of information=20
necessary to ensure interoperability between implementations. The=20
current document defines data elements sufficient to describe most=20
common replication needs. The specification of complex replication=20
agreements and constraints is better served by usage of the=20
emerging "policy model" [Policy schema]. =20
=20
6. Directory Knowledge=20
=20
Information about what replicas exist, what they contain, their=20
types, where they are stored, and how they may be contacted=20
inevitably provides the basis for distributed directory knowledge. =20
As namespaces from stand-alone servers are inter-connected with one=20
another, this replica information can and will be used by name=20
resolution operations to locate servers holding copies of specific=20
objects, and to optimize distributed searches which span multiple=20
Naming Contexts.=20
=20
However, the focus of this document is NOT to fully enable such=20
distributed directory uses. Instead, we are focused on how=20
portions of the namespace (Directory Information Tree - DIT) may be=20
replicated, and how those replicas are configured and related to=20
one another via Replication Agreements.=20
=20
=20
Huber, et al Expires April 2004 [Page 5] =0C
LDUP Information Model =20
As such, the following high-level description (from [LDUP Model])=20
of the information model envisioned is provided as a reference for=20
the reader before presenting the detailed specifications. =20
=20
Generally, the DSE Naming Context attribute of an LDAPv3 server=20
names the Naming Contexts for which there are replicas on that=20
server.=20
=20
The Replication Context Auxiliary Class (replicationContext) is=20
added to container objects which may have separately defined=20
replication policy.=20
=20
Immediately subordinate to a Replication Context object are the=20
Replica Subentry containers which identify where the identified=20
replica resides (i.e., its LDAP Access Point), its type=20
(Updateable, ReadOnly), if it is sparse, the LDAP search filter=20
which defines what object classes it holds, and if it is=20
fractional, the attributes it does or does not hold.=20
=20
Immediately subordinate in the namespace to a Replica Subentry are=20
Replication Agreement leaf entries which each identify another=20
Replica, the scheduling policy for replication operations=20
(including times when replication is to be performed, when it is=20
not to be performed, or the policies governing event-driven=20
replication initiation). These Replication Agreements are used to=20
specify constraints on when the replica will supply what changes to=20
the "pointed to" other replica, as either the replication initiator=20
or responder.=20
=20
Replication Agreements are not defined to cover the following=20
advanced policy characteristics:=20
=20
- when a replica would allow consumers to request a replication=20
session=20
- when a replica would allow suppliers to start a replication=20
session=20
- when a replica would request a replication session from a=20
supplier.=20
=20
These advanced policy specifications imply the specification of=20
complex replication agreements and constraints. This is better=20
served by usage of the emerging "policy model" [Policy schema]. =20
Interoperable policies for replication agreements is left as a=20
follow-on work effort.=20
=20
=20
7. Schema=20
=20
7.1. Data Structure Definitions=20
=20
For the purposes of defining the encoding rules for attribute=20
structures, the BNF definitions in section 4.1 of [RFC2252] will be=20
used. They are based on the BNF styles of [RFC822].=20
=20
=20
Huber, et al Expires April 2004 [Page 6] =0C
LDUP Information Model =20
To avoid requiring new syntax support to be added unnecessarily to=20
existing LDAPv3 directory service implementations (and the=20
accompanying matching rules, etc. they would entail), a string=20
encoding is defined for ldapChangeSequenceNumber which can use=20
CaseIgnoreString matching rules for ordering and equality.=20
=20
7.1.1. LdapChangeSequenceNumber=20
=20
( 1.3.6.1.4.1.1466.115.121.1.TBD=20
DESC 'LDAP Change Sequence Number' )=20
=20
Values in this syntax are encoded according to the following BNF. =20
Note there MUST NOT be any white space separators, unless they are=20
in replicaID, which must be encoded according to the instructions=20
below.=20
=20
This encoding is specified so that the CaseIgnoreString equality=20
and ordering rules will work correctly when replicaNumber is used.=20
When replicaID is used, CaseIgnoreString comparison rules will not=20
work unless each replicaID is exactly the same length with no=20
padded white spaces (because CaseIgnoreString suppresses duplicate=20
adjacent white space when it compares two strings).=20
=20
LDAPChangeSequenceNumber =3D GeneralizedZTime "#" \=20
S1 "#" replicaID "#" S2=20
=20
GeneralizedZTime =3D yyyy | mm | dd | hh | mi | ss | "Z"=20
=20
yyyy =3D dddd <four digit year, e.g. 1998>=20
=20
mm =3D dd <two digit month of the year, e.g. 06>=20
=20
dd =3D dd <two digit day of month, e.g. 17>=20
=20
hh =3D dd <two digit hour of the day, inclusive range (00..23)>=20
=20
mi =3D dd <two digit minute of the hour, inclusive range (00..59)>=20
=20
ss =3D dd <two digit seconds of the minute, inclusive range (00..59)>=
=20
=20
replicaID =3D dstring =20
=20
S1, S2 =3D numericstring=20
=20
The GeneralizedTime is used as described (cf. [X680] section 39.3=20
case b) without separators or white space, and representing a=20
coordinated universal time (i.e., Greenwich Mean Time, or GMT). =20
All times referenced by this syntax MUST be normalized to GMT - no=20
local times, nor time zone offsets are permitted. To simplify=20
comparisons of two CSNs, the "Z" MUST be the UTF-8 capital-Z=20
character.=20
=20
The ReplicaID represents the specific Replica of this Naming=20
Context where the event associated with this=20
=20
Huber, et al Expires April 2004 [Page 7] =0C
LDUP Information Model =20
LDAPChangeSequenceNumber occurred. Note that in actual transfer,=20
the replicaID MAY be represented by a number which is associated=20
with the entryUUID of the replicaSubEntry associated with the=20
replica (see the specification of the replicaIDTable in [LDUP=20
Update Protocol]). When associated with an item of information=20
within a replica, the replicaID should be traceable to the=20
entryUUID of the replicaSubEntry associated with the replica on=20
which the modification was made. This allows for compressed=20
internal storage of change sequence numbers while still ensuring=20
that change sequence numbers will be universally unique regardless=20
of the replication context from which they were first produced.=20
=20
S1 and S2 are sequence numbers which are used to order two events=20
with the same Generalized Time and replicaID. In order to use=20
string matching rules for equality and ordering with values with=20
this encoding, the length of each field must be consistent. Thus,=20
all instances of S1 MUST be represented with the same number of=20
digits, using leading zeros as necessary. The same with S2 and=20
replicaID.=20
=20
7.2. Attribute Definitions=20
=20
7.2.1. supportedReplicationProtocols=20
=20
( 2.16.840.1.113719.1.142.4.x NAME 'supportedReplicationProtocols'=20
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26=20
EQUALITY caseIgnoreMatch=20
DESC 'set of OIDs which represent the (set of) protocols=20
supported by this server' )=20
=20
This attribute is added to the root DSE entry of servers which=20
support replication as defined by [LDUP Model].=20
=20
=20
=20
=20
7.2.2. attributeExclusionFilter=20
=20
( 2.16.840.1.113719.1.142.4.1 NAME 'attributeExclusionFilter'=20
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40=20
SINGLE-VALUE=20
=20
USAGE dSAOperation )=20
=20
The attributeExclusionFilter is intended to contain a list of=20
attributes in the form of an AttributeDescriptionList as described=20
in section 4.5.1 Search Request of [RFC2251] with the following=20
interpretation: an empty attributeExclusionFilter means that no=20
attributes are excluded; the special values "*" and "1.1" mean that=20
ALL attributes are excluded.=20
=20
A non-empty attributeExclusionFilter attribute on a replica=20
subentry describes the attributes NOT PRESENT on entries held by=20
that replica. Replicas MUST NOT accept changes for attributes=20
=20
Huber, et al Expires April 2004 [Page 8] =0C
LDUP Information Model =20
they're not permitted to hold, per the attributeInclusionFilter and=20
attributeExclusionFilter attributes on their replica subentry.=20
=20
A non-empty attributeExclusionFilter attribute on a replication=20
agreement subentry describes which additional attributes are to be=20
excluded from the updates to be sent from the supplier replica to=20
the consumer replica.=20
=20
7.2.3. attributeInclusionFilter=20
=20
( 2.16.840.1.113719.1.142.4.2 NAME 'attributeInclusionFilter'=20
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40=20
SINGLE-VALUE=20
=20
USAGE dSAOperation )=20
=20
The attributeInclusionFilter is intended to contain a list of=20
attributes in the form of an AttributeDescriptionList as described=20
in section 4.5.1 Search Request of [RFC2251] with the following=20
interpretation: an empty attributeInclusionFilter means that all=20
attributes are included; the special value "*" means that ALL=20
attributes are included; the special value "1.1" is meaningless and=20
is ignored in this usage.=20
=20
A non-empty attributeInclusionFilter attribute on a replica=20
subentry describes the attributes that may be PRESENT on entries=20
held by that replica. Replicas MUST NOT accept changes for=20
attributes they're not permitted to hold, per the=20
attributeInclusionFilter and attributeExclusionFilter attributes on=20
their replica subentry.=20
=20
It is an error to specify both an attributeExclusionFilter and an=20
attributInclusionFilter in the same replicaSubentry. =20
=20
7.2.4. replicaURI=20
=20
( 2.16.840.1.113719.1.142.4.x NAME 'replicaURI'=20
DESC 'LDAP URLs which indicate how to connect to this replica'=20
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20
EQUALITY caseExactMatch=20
USAGE dSAOperation )=20
=20
The replicaURI attribute is a multi-valued attribute used to list=20
the set of LDAP URLs that should be used to contact the replica for=20
replication sessions. If all URLs in the replicaURL attribute are=20
not contactable, the replicaSecondaryURL attribute values should be=20
used to establish a replication session with the replica.=20
=20
The replicaURI MUST be an LDAP URL as specified in RFC 2255. The=20
replicaURI SHOULD specify only the host name (or IP address) of the=20
destination replica and possibly a port number. Filters, base DN,=20
and other LDAP URL components MUST be ignored if they are supplied. =20
=20
=20
Huber, et al Expires April 2004 [Page 9] =0C
LDUP Information Model =20
7.2.5. replicationStatus=20
=20
(2.16.840.1.113719.1.142.4.3 NAME 'replicationStatus'=20
DESC 'human readable status of last replication attempt'=20
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20
SINGLE-VALUE=20
NO-USER-MODIFICATION=20
USAGE dSAOperation )=20
=20
The replicationStatus attribute MAY be used to hold a human=20
readable message describing the most recent replication session=20
attempt for a replication agreement.=20
=20
For example, such a messages might include =20
=20
1) 9980805162203Z # Success #=20
=20
2) 19980805162322Z # Failure # Server too busy, try again=20
=20
3) 19980805170215Z # Failure # Unable to connect to DSA=20
=20
4) 19980806002301Z # Failure # Authentication failed=20
=20
5) 19980806003201Z # Failure # lost connection, reset by peer=20
=20
It is suggested, but not required, that the time of a replication=20
attempt (completion, if successful or failure, if not), the result=20
of the attempt, and any additional information about a failure be=20
included in the string message.=20
=20
It is suggested, but not required, that the messages be stored with=20
language tags (English, French, German, Japanese, Chinese, per=20
[RFC2596]) particularly if multiple translations of the error=20
messages are available to the DSA implementers.=20
=20
Sequences of status entries SHOULD be written to log files or other=20
persistent storage, or in multi-valued replication history=20
attributes, but are not specified here.=20
=20
7.2.6. replicaType=20
=20
(2.16.840.1.113719.1.142.4.4 NAME 'replicaType'=20
DESC 'Enum: 0-reserved, 1-reserved, 2-Updateable,=20
3-ReadOnly, all others reserved'=20
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27=20
EQUALITY integerMatch=20
SINGLE-VALUE=20
=20
USAGE dSAOperation )=20
=20
ReplicaType is a simple enumeration, used to identify what kind of=20
replica is being described in a Replica object entry.=20
=20
=20
Huber, et al Expires April 2004 [Page 10] =0C
LDUP Information Model =20
A ReadOnly replica only accepts LDAP Search operations (to Read=20
entries, list containers, and search for entries). Because no=20
updates ever originate from ReadOnly replicas, they never have=20
changes to send to another replica. However, a ReadOnly replica=20
may be designated a supplier DSA in a replica agreement, if it is=20
simply passing along information it receives from Updateable=20
replicas about entries and their changes.=20
=20
ReadOnly replicas may be partial replicas.=20
=20
An Updateable replica may accept both LDAP Search operations (to=20
read, list, or search entries), as well as modification operations=20
(to add, modify, or delete entries). =20
=20
The consequences of having partial updateable replicas are not=20
fully understood. LDAP DSAs MAY require updateable replicas to be=20
complete replicas.=20
=20
=20
=20
The way in which replicas change their type, as from ReadOnly to=20
Updateable, is discussed in [LDUP MRM].=20
=20
Section 5.1 "Replica Type" of [LDUP MODEL] details the permissible=20
combinations of replica types and sparse/fractional replicas.=20
=20
7.2.7. updateVector=20
=20
( 2.16.840.1.113719.1.142.4.6 NAME 'updateVector'=20
SYNTAX 1.3.6.1.4.1.1466.115.121.1.TBD=20
EQUALITY caseIgnoreMatch=20
ORDERING caseIgnoreOrderingMatch=20
NO-USER-MODIFICATION=20
USAGE dSAOperation )=20
=20
The attribute updateVector is a multi-valued attribute which=20
contains information for a replica describing the latest changes=20
received by the replica from other replicas.=20
=20
There may be only one ldapChangeSequenceNumber entry from each=20
replica in the updateVector. That is to say, there is a unique=20
value constraint on the ReplicaID component of entries in the list.=20
=20
7.2.8. replicaSecondaryURI=20
=20
( 2.16.840.1.113719.1.142.4.x NAME 'replicaSecondaryURI'=20
DESC 'LDAP URLs which indicate how to connect to this replica'=20
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20
EQUALITY caseExactMatch=20
USAGE dSAOperation )=20
=20
The replicaSecondaryURI attribute is a multi-valued attribute used=20
to list the set of LDAP URLs that should be used to contact the=20
=20
Huber, et al Expires April 2004 [Page 11] =0C
LDUP Information Model =20
replica for replication sessions if all LDAP URLs in the replicaURL=20
attribute are not contactable. =20
=20
7.2.9. lostAndFoundEntryDN=20
=20
( 2.16.840.1.113719.1.142.4.x NAME 'lostAndFoundEntryDN'=20
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12=20
EQUALITY distinguishedNameMatch=20
SINGLE-VALUE=20
DESC 'name of the entry under which orphaned entries will=20
be moved during replication update processing by this=20
replica.' )=20
=20
This attribute indicates the location under which the replica will=20
move orphaned entries that are encountered while performing=20
replication updates. The attribute is single-valued and is=20
specific to each replica.=20
=20
7.2.10. replicaOnline=20
=20
( 2.16.840.1.113719.1.142.4.x NAME 'replicaOnline'=20
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7=20
EQUALITY booleanMatch=20
SINGLE-VALUE=20
DESC 'indicates whether or not the replica will=20
will initiate and/or respond to replication=20
session start requests.' )=20
=20
This attribute indicates whether the replica is ready and willing=20
to participate in replication sessions with other replicas that are=20
defined as holding the replication context.=20
=20
7.2.11. replicaDN=20
=20
( 2.16.840.1.113719.1.142.4.x NAME 'replicaDN'=20
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12=20
EQUALITY distinguishedNameMatch=20
SINGLE-VALUE=20
DESC 'name of the consumer replicaSubentry entry that the=20
replicaAgreement links to.' )=20
=20
This attribute is used to link a replicaAgreement entry (associated=20
with a supplier of replication update information) to the consumer=20
replica that will be contacted by replication sessions constrained=20
by the replicaAgreement.=20
=20
7.2.12. replicationMechanismOID=20
=20
( 2.16.840.1.113719.1.142.4.x NAME 'replicationMechanismOID'=20
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26=20
EQUALITY caseIgnoreMatch=20
SINGLE-VALUE=20
DESC 'the OID which represents the specific =20
replication protocol used for replication=20
=20
Huber, et al Expires April 2004 [Page 12] =0C
LDUP Information Model =20
sessions between the identified supplier and=20
consumer replicas.' )=20
=20
This attribute identifies the specific replication protocol used=20
for replication sessions between the supplier and consumer replicas=20
associated by the replicaAgreement entry. This attribute must be a=20
value that is within the set of attribute values for the=20
supportedReplicationProtocols attribute in the root DSE entry.=20
=20
7.2.13. replicationCredentialsDN=20
=20
( 2.16.840.1.113719.1.142.4.x NAME 'replicationCredentialsDN'=20
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12=20
EQUALITY distinguishedNameMatch=20
SINGLE-VALUE=20
DESC 'name of a separate entry in the directory tree which=20
contains the credentials information used in identifying=20
the supplier replica to the consumer replica when=20
initiating a replication session.' )=20
=20
This attribute is used to establish a separate entry in the=20
directory tree that will hold the credentials information that is=20
used to establish the supplier's identity at the consumer when=20
starting a replication session. By placing credentials information=20
in a separate entry, "pointed to" with this attribute, credentials=20
information can be placed in a portion of the directory tree that=20
is not replicated across multiple replicas. It can also be=20
=93shared=94 by several replication contexts.=20
=20
7.2.14. replicationScheduleDN=20
=20
( 2.16.840.1.113719.1.142.4.x NAME 'replicationScheduleDN'=20
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12=20
EQUALITY distinguishedNameMatch=20
SINGLE-VALUE=20
DESC 'name of an entry which contains the specific=20
information used to establish when replication=20
sessions will be initiated by this replica=20
supplier.' )=20
=20
This attribute is used to "point to" either a replicaEventSchedule=20
or replicaTimeSchedule entry which describes when replication=20
sessions should be initiated by a replica supplier. If not=20
specified, a default schedule is assumed. See the section=20
describing the replicaAgreement for more details.=20
=20
7.2.15. updateVectorTrigger=20
=20
( 2.16.840.1.113719.1.142.4.x NAME 'updateVectorTrigger'=20
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7=20
EQUALITY booleanMatch=20
SINGLE-VALUE=20
DESC 'indicates whether or not updates made to the=20
replicas updateVector should be treated as=20
=20
Huber, et al Expires April 2004 [Page 13] =0C
LDUP Information Model =20
updates that cause the secondsToWaitDefault=20
attribute value to be used in determining=20
when to initiate a replication session.' )=20
=20
This attribute is used to indicate whether or not changes to the=20
replica's updateVector should be included as updates that cause the=20
secondsToWaitDefault attribute value to be used when determining=20
when to initiate replication sessions.=20
=20
If updateVectorTrigger is set to FALSE, then secondsToWaitDefault=20
will not be used when the replica's updateVector is updated. This=20
implies that some other update will need to be performed to the=20
replica before the updated updateVector will be sent via a=20
replication session.=20
=20
If upateVectorTrigger is set to TRUE, then updates to the=20
updateVector will be used in determining when replication sessions=20
should be initiated.=20
=20
Note that setting secondsToWaitDefault to 0 coupled with=20
updateVectorTrigger to TRUE would cause replication sessions to=20
continually "chase themselves", potentially clogging networks with=20
an infinite loop of replication sessions. This combination SHOULD=20
be prevented in implementations.=20
=20
If not specified, the value for updateVectorTrigger is assumed to=20
be FALSE.=20
=20
7.2.16. secondsToWaitDefault=20
=20
(2.16.840.1.113719.1.142.4.x NAME 'secondsToWaitDefault'=20
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27=20
EQUALITY integerMatch=20
SINGLE-VALUE=20
DESC 'The number of seconds to wait after an update=20
is made to the replica before initiating a=20
replication session.'=20
=20
USAGE dSAOperation )=20
=20
This attribute indicates the number of seconds that a replica=20
should wait after an update is made to the replica before=20
initiating a replication session. If not specified, the value is=20
assumed to be 0. This attribute value is used for updates to all=20
attributes that are NOT specified by either the attrs1 or attrs2=20
attributes.=20
=20
This attribute is always used for updates made to the replica's=20
updateVector if the updateVectorTrigger attribute is set to TRUE. =20
=20
7.2.17. secondsToWait1=20
=20
=20
(2.16.840.1.113719.1.142.4.x NAME 'secondsToWait1'=20
=20
Huber, et al Expires April 2004 [Page 14] =0C
LDUP Information Model =20
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27=20
EQUALITY integerMatch=20
SINGLE-VALUE=20
DESC 'The number of seconds to wait after an update=20
is made to any attributes named in the attrs1=20
attribute before initiating a replication session.'=20
=20
USAGE dSAOperation )=20
=20
This attribute is similar to the secondsToWaitDefault attribute in=20
how it is used. This attribute, however, is used to apply only to=20
the attributes listed in the attrs1 attribute. This allows updates=20
to different attributes to cause replication sessions to be=20
initiated either sooner or later than updates made to other=20
attributes.=20
=20
=20
7.2.18. attrReplicationGroup1=20
=20
( 2.16.840.1.113719.1.142.4.x NAME 'attrReplicationGroup1'=20
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26=20
EQUALITY caseIgnoreMatch=20
DESC 'the set of attributes that are associated with=20
the secondsToWait1 attribute. When updates are=20
made to any of these attributes on the replica,=20
a replication session will be delayed until=20
after secondsToWait1 seconds have passed.' )=20
=20
This attribute identifies a set of attributes that are associated=20
with the secondsToWait1 attribute. When secondsToWait1 seconds=20
have passed since an update to any attribute identified in the=20
attrs1 attribute, a replication session will be initiated.=20
=20
7.2.19. secondsToWait2=20
=20
(2.16.840.1.113719.1.142.4.x NAME 'secondsToWait2'=20
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27=20
EQUALITY integerMatch=20
SINGLE-VALUE=20
DESC 'The number of seconds to wait after an update=20
is made to any attributes named in the attrs2=20
attribute before initiating a replication session.'=20
=20
USAGE dSAOperation )=20
=20
This attribute is similar to the secondsToWaitDefault attribute in=20
how it is used. This attribute, however, is used to apply only to=20
the attributes listed in the attrs2 attribute. This allows updates=20
to different attributes to cause replication sessions to be=20
initiated either sooner or later than updates made to other=20
attributes.=20
=20
=20
=20
Huber, et al Expires April 2004 [Page 15] =0C
LDUP Information Model =20
7.2.20. attrReplicationGroup2=20
=20
( 2.16.840.1.113719.1.142.4.x NAME 'attrReplicationGroup2'=20
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26=20
EQUALITY caseIgnoreMatch=20
DESC 'the set of attributes that are associated with=20
the secondsToWait2 attribute. When updates are=20
made to any of these attributes on the replica,=20
a replication session will be delayed until=20
after secondsToWait2 seconds have passed.' )=20
=20
This attribute identifies a set of attributes that are associated=20
with the secondsToWait2 attribute. When secondsToWait2 seconds=20
have passed since an update to any attribute identified in the=20
attrs2 attribute, a replication session will be initiated.=20
=20
7.2.21. scheduleTimePeriod=20
=20
( 2.16.840.1.113719.1.142.4.x NAME 'scheduleTimePeriod'=20
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44=20
EQUALITY caseIgnoreMatch=20
SINGLE-VALUE=20
DESC 'the absolute time range over which this time=20
specification is valid.' )=20
=20
This attribute is patterned after the TimePeriod property=20
identified in RFC 3060 [RFC3060] and [Policy Schema]. See these=20
references for details on the format and interpretation of this=20
attribute.=20
=20
7.2.22. scheduleMonthOfYearMask=20
=20
( 2.16.840.1.113719.1.142.4.x NAME 'scheduleMonthOfYearMask'=20
SYNTAX 1.3.6.1.4.1.1466.115.121.1.6=20
SINGLE-VALUE=20
DESC 'mask identifying the months of the year during=20
which replication sessions should be performed.' )=20
=20
This attribute is patterned after the MonthOfYearMask property=20
identified in RFC 3060 [RFC3060] and [Policy Schema]. See these=20
references for details on the format and interpretation of this=20
attribute.=20
=20
7.2.23. scheduleDayOfMonthMask=20
=20
( 2.16.840.1.113719.1.142.4.x NAME 'scheduleDayOfMonthMask'=20
SYNTAX 1.3.6.1.4.1.1466.115.121.1.6=20
SINGLE-VALUE=20
DESC 'mask identifying the days of the month during=20
which replication sessions should be performed.' )=20
=20
This attribute is patterned after the DayOfMonthMask property=20
identified in RFC 3060 [RFC3060] and [Policy Schema]. See these=20
=20
Huber, et al Expires April 2004 [Page 16] =0C
LDUP Information Model =20
references for details on the format and interpretation of this=20
attribute.=20
=20
7.2.24. scheduleDayOfWeekMask=20
=20
( 2.16.840.1.113719.1.142.4.x NAME 'scheduleDayOfWeekMask'=20
SYNTAX 1.3.6.1.4.1.1466.115.121.1.6=20
SINGLE-VALUE=20
DESC 'mask identifying the days of the week during=20
which replication sessions should be performed.' )=20
=20
This attribute is patterned after the DayOfWeekMask property=20
identified in RFC 3060 [RFC3060] and [Policy Schema]. See these=20
references for details on the format and interpretation of this=20
attribute.=20
=20
7.2.25. scheduleTimeOfDayMask=20
=20
( 2.16.840.1.113719.1.142.4.x NAME 'scheduleTimeOfDayMask'=20
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44=20
EQUALITY caseIgnoreMatch=20
DESC 'mask identifying the times during the day when=20
replication sessions should be initiated.' )=20
=20
This attribute is patterned after the TimeOfDayMask property=20
identified in RFC 3060 [RFC3060] and [Policy Schema]. See these=20
references for details on the format and interpretation of this=20
attribute.=20
=20
7.2.26. scheduleLocalOrUtcTime=20
=20
( 2.16.840.1.113719.1.142.4.x NAME 'scheduleLocalOrUtcTime'=20
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27=20
EQUALITY integerMatch=20
SINGLE-VALUE=20
DESC 'flag indicating whether or not times in the=20
scheduleTimeOfDayMask are in UTC time or=20
local time.' )=20
=20
This attribute is patterned after the LocaOrUtcTime property=20
identified in RFC 3060 [RFC3060] and [Policy Schema]. See these=20
references for details on the format and interpretation of this=20
attribute.=20
=20
7.3. Class Definitions=20
=20
7.3.1. ReplicationContext=20
=20
( 2.16.840.1.113719.1.142.6.2.2 NAME 'replicationContext'=20
SUP top=20
AUXILIARY )=20
=20
The replicationContext auxiliary class, when present on an object,=20
indicates the beginning, or root, of one or more replication=20
=20
Huber, et al Expires April 2004 [Page 17] =0C
LDUP Information Model =20
contexts. The replication context is said to be rooted at the=20
entry with the replicationContext auxiliary class in its list of=20
object classes. The root-most entry of a replication context is=20
the entry with the replicationContext auxiliary class in its list=20
of object classes.=20
=20
Characteristics of the replication topology of a replication=20
context are defined in the replicaSubentry sub-entries associated=20
with the replication context.=20
=20
The attribute accessControlPolicyOID has been removed from here,=20
and should be published as an subentry subordinate to the=20
replicationContext, instead.=20
=20
The attribute nameContextCreationTimestamp used here in previous=20
drafts has been eliminated as redundant. The=20
ldapChangeSequenceNumber associated with the replicationContext=20
value in the list of objectclass attribute values serves the same=20
purpose.=20
=20
7.3.2. replicaSubentry=20
=20
( 2.16.840.1.113719.1.142.6.3.2 NAME 'replicaSubentry-2'=20
SUP subentry=20
STRUCTURAL=20
MUST ( cn $=20
replicaURI $=20
replicaType $=20
lostAndFoundEntryDN $=20
replicaOnline )=20
MAY ( attributeExclusionFilter $=20
attributeInclusionFilter $=20
replicaSecondaryURI $=20
description $=20
updateVector ) )=20
=20
Entries of type replicaSubentry MUST be named by their cn attribute=20
as defined in [LDAP Subentry]. A replicationContext may have more=20
than one replicaSubentry. All replicaSubentries MUST be placed=20
just below their associated replicationContext root entries in the=20
directory tree.=20
=20
All replicas MUST hold all replicaSubentries for the replication=20
context. This is required for update vectors.=20
=20
The attributes attributeExclusionFilter and=20
attributeInclusionFilter, if present, govern which entries and=20
attributes from the local naming context are to be sent (or not=20
sent) to the replica named in replicaDN of replica agreements for=20
this replica. The attributeExclusionFilter names attributes which=20
SHOULD NOT be sent. The attributeInclusionFilter names attributes=20
which SHOULD be sent.=20
=20
=20
Huber, et al Expires April 2004 [Page 18] =0C
LDUP Information Model =20
The attribute replicaURI contains information in ldapURI format=20
that can be used to contact (i.e., open a connection to) this=20
replica. The replicaSecondaryURI contains the set of ldapURI=20
format addresses that can be used as backup addresses if the=20
replicaURI values cannot be used.=20
=20
The lostAndFoundEntryDN attribute is single-valued attribute that=20
contains the distinguished name of the lost and found entry under=20
which orphaned entries are placed.=20
=20
The replicaOnline attribute is a Boolean attribute which indicates=20
whether or not this replica will supply and/or accept replication=20
sessions. This attribute can be used to prevent replication=20
sessions from being started before replicaAgreement entries have=20
been defined.=20
=20
The attribute description contains a human-readable description of=20
the sub-entry. =20
=20
The attribute updateVector contains a set of=20
ldapChangeSequenceNumbers, one for each of the other replicas for=20
this naming context, which records, from this replicas perspective,=20
the last change event received from the other indicated replica.=20
=20
The subtreespecification attribute of the subentry superior object=20
class is used to define the scope of the replication context. Use=20
of the subtreespecification value SHOULD be limited to the base and=20
components of ChopSpecification portions of this attribute.=20
=20
7.3.3. replicaAgreement=20
=20
( ?? NAME 'replicaAgreement' =20
SUP top=20
STRUCTURAL=20
MUST ( cn )=20
MAY ( description $=20
replicaDN $=20
replicationMechanismOID $=20
replicationStatus $=20
replicationCredentialsDN $=20
replicationScheduleDN ) ) =20
=20
If present, entries of this type MUST be placed just below=20
replicaSubentry entries in the directory tree. =20
=20
If replicaAgreements are used, each replica MUST hold all replica=20
agreements for which it is a supplier as well as the entries=20
containing control information referred to by those replica=20
agreements (credentials, schedules, etc.).=20
=20
Name subordination is used to associate a replicaAgreement with the=20
replicaSubentry representing the supplier of changes for all=20
subordinate replication agreements.=20
=20
=20
Huber, et al Expires April 2004 [Page 19] =0C
LDUP Information Model =20
=20
Processing of allowable changes to be sent is as follows:=20
=20
1) the attributeInclusionFilter from the replica subentry defines a=20
set of attributes which SHOULD be sent, less exclusions;=20
=20
2) the union of attributes excluded by the attributeExclusionFilter=20
from the replicaSubentry and the attributeExclusionFilter from the=20
replicaAgreement defines a set of attributes which SHOULD NOT be=20
sent;=20
=20
3) the subtraction of attributes which SHOULD NOT be sent by (2)=20
from the attributes which SHOULD be sent by (1) constitute the set=20
of attributes for which changes MAY be sent.=20
=20
The attribute description contains a human-readable description of=20
the sub-entry.=20
=20
The attribute replicaDN of syntax distinguishedName names another=20
sub-entry of type replicaSubentry to whom changes are to be sent. =20
If there is no value for the replicaDN attribute on a=20
replicaAgreement, the replicaAgreement is ignored. Absence of a=20
value may occur briefly when replicas and replica agreements are=20
first being created, or when the replica to which a replica=20
agreement applies is being deleted.=20
=20
The attribute replicationMechanismOID is used to indicate the type=20
of replication protocol that is used between the supplier and=20
consumer. If not specified, the default replication protocol=20
defined in [LDUP Update Replication Protocol] is assumed.=20
=20
The attribute replicationStatus MAY be used to record the most=20
recent result of an attempt to send changes to the replica named in=20
replicaDN, whether success, or if failure, the nature of the=20
problem encountered.=20
=20
The attribute replicationCredentialsDN, if present, names an entry=20
which contains information used to initialize authenticated the=20
LDAP connection between the supplier and consumer. Separating the=20
credentials information from the replicaAgreement itself allows for=20
this information to be placed outside of the replication context. =20
=20
The attribute replicationScheduleDN, if present, names an entry=20
which governs the schedule for replication attempts. If not=20
present, replication MUST be attempted when there are changes to be=20
sent (i.e. a default replica schedule of type replicaEventSchedule=20
is assumed with secondsToWaitDefault=3D0 and=20
updateVectorTrigger=3DFALSE). See Section on replicaEventSchedule=20
for more information about these attributes and their meaning.=20
=20
=20
7.3.4. replicaEventSchedule=20
=20
( 2.16.840.1.113719.1.142.6.x.1 NAME 'replicaEventSchedule' =20
=20
Huber, et al Expires April 2004 [Page 20] =0C
LDUP Information Model =20
SUP top=20
STRUCTURAL=20
MUST ( cn )=20
MAY ( description $=20
updateVectorTrigger $=20
secondsToWaitDefault $=20
secondsToWait1 $=20
attrs1 $=20
secondsToWait2 $=20
attrs2 ) )=20
=20
=20
The replicaEventSchedule object class is used to specify when to=20
initiate replication sessions in terms of the time to wait after an=20
update is made to the supplier replica.=20
=20
The attribute cn is used as the naming attribute for the=20
replicaEventSchedule object class. It is thought that=20
replicaEventSchedule entries would be placed below replicaAgreement=20
entries but this is not required.=20
=20
The attribute description contains a human-readable description of=20
the sub-entry.=20
=20
The attribute updateVectorTrigger is a Boolean attribute which=20
indicates whether or not the update of the supplier's updateVector=20
attribute should, itself, be used to trigger replication sessions. =20
Since the updateVector is, itself, an attribute, it has CSNs=20
associated with each of its values. Note that these CSNs may be=20
different from the CSNs that are in the attribute values=20
themselves. Thus, it is possible that the update to the=20
updateVector would, itself, need to be treated as an update to be=20
replicated. Indeed, this is necessary in order for "transitive=20
replication" to work.=20
=20
The secondsToWaitDefault attribute is a non-negative integer value. =20
This value indicates the number of seconds to wait after an update=20
is made before starting a replication session. This value is used=20
for all attributes other than those noted in the attrs1 and attrs2=20
attributes.=20
=20
The secondsToWait1 attribute is similar to the secondsToWaitDefault=20
attribute. This non-negative integer value is used whenever any=20
attribute listed in the attrs1 attribute is updated.=20
=20
The secondsToWait2 attribute is similar to the secondsToWait1=20
attribute but is associated with the attrs2 attribute.=20
=20
Note that whenever any of these seconds-to-wait time periods has=20
expired, a replication session should be initiated and the full set=20
of information that needs to be replicated should be sent to the=20
consumer replica. This implies that some information would be=20
replicated before its associated seconds-to-wait time period had=20
expired.=20
=20
Huber, et al Expires April 2004 [Page 21] =0C
LDUP Information Model =20
=20
7.3.5. replicaTimeSchedule=20
=20
( 2.16.840.1.113719.1.142.6.x.1 NAME 'replicaTimeSchedule' =20
SUP top=20
STRUCTURAL=20
MUST ( cn )=20
MAY ( description $=20
scheduleTimePeriod $=20
scheduleMonthOfYearMask $=20
scheduleDayOfMonthMask $=20
scheduleDayOfWeekMask $=20
scheduleTimeOfDayMask $=20
scheduleLocalOrUtcTime ) )=20
=20
The replicaTimeSchedule object class is used to specify when to=20
initiate replication sessions based on a scheduled time basis=20
rather than in relation to when updates are made to the supplier=20
replica.=20
=20
The attribute cn is used as the naming attribute for the=20
replicaTimechedule object class. It is thought that=20
replicaTimeSchedule entries would be placed below replicaAgreement=20
entries but this is not required.=20
=20
The attribute description contains a human-readable description of=20
the sub-entry.=20
=20
The remaining attributes in this object class are patterned after=20
the attributes defined for the policyTimePeriodCondition construct=20
defined in the Policy Core Information Model [RFC3060]. Because=20
the LDAP schema mapping for this portion of the CIM model is not=20
complete at this time, these attributes are defined specifically=20
for this LDUP-related object class. Refer to RFC 3060 for details=20
of the formats for the scheduleTimePeriod, scheduleMonthOfYearMask,=20
scheduleDayOfMonthMask, scheduleDayOfWeekMask,=20
scheduleTimeOfDayMask, and scheduleLocalOrUtcTime attributes.=20
=20
8. Semantics of the information model=20
=20
The intent of this information model is to allow for useful and=20
expected operation while requiring a minimum amount of data to be=20
specified. In this spirit, replicaAgreement entries are treated as=20
"constraints" on when to initiate replication sessions, not=20
"requirements" on being able to initiate replication sessions.=20
=20
To clarify this concept, two examples are provided in this section.=20
=20
The first example shows the minimal set of information required to=20
get replication going between three replicas:=20
=20
dn: ou=3Daccounting, o=3Dyour company=20
objectclass: organizationalUnit=20
objectclass: replicationContext=20
=20
Huber, et al Expires April 2004 [Page 22] =0C
LDUP Information Model =20
ou: accounting=20
=20
dn: cn=3Dreplica1, ou=3Daccounting, o=3Dyour company=20
objectclass: subentry=20
objectclass: replicaSubentry-2=20
cn: replica1=20
subtreespecification: {}=20
description: replica in location 1=20
replicaURI: ldap://sys1.yourcompany.com=20
replicaType: 2=20
lostAndFoundEntryDN: cn=3DlostAndFound1, o=3Dyour company=20
replicaOnline: TRUE=20
=20
dn: cn=3Dreplica2, ou=3Daccounting, o=3Dyour company=20
objectclass: subentry=20
objectclass: replicaSubentry-2=20
cn: replica2=20
subtreespecification: {}=20
description: replica in location 2=20
replicaURI: ldap://sys2.yourcompany.com=20
replicaType: 2=20
lostAndFoundEntryDN: cn=3DlostAndFound2, o=3Dyour company=20
replicaOnline: TRUE=20
=20
dn: cn=3Dreplica3, ou=3Daccounting, o=3Dyour company=20
objectclass: subentry=20
objectclass: replicaSubentry-2=20
cn: replica3=20
subtreespecification: {}=20
description: replica in location 3=20
replicaURI: ldap://sys2.yourcompany.com=20
replicaType: 2=20
lostAndFoundEntryDN: cn=3DlostAndFound3, o=3Dyour company=20
replicaOnline: TRUE=20
=20
With replicaSubentry entries defined as shown in this first=20
example, replication sessions will be initiated by all replicas=20
whenever an update is made to any attribute within any entries in=20
the replicationContext. The default event schedule will be used=20
which indicates that a replication session is initiated immediately=20
after an update is made to a replica. Further, replication=20
sessions would be initiated to ALL OTHER replicas. As this shows,=20
maximal replication is defined using a minimal amount of=20
configuration.=20
=20
The second example shows how replication sessions can be=20
constrained by replicaAgreement entries. This example builds on=20
the data shown in the first example. Assume that the following=20
entries are added to the entries defined in the first example:=20
=20
dn: cn=3Dagreement1->2, cn=3Dreplica1, ou=3Daccounting, o=3Dyour comp=
any=20
objectclass: replicaAgreement=20
cn: agreement1->2=20
description: Replica agreement constraining replication sessions=20
=20
Huber, et al Expires April 2004 [Page 23] =0C
LDUP Information Model =20
from replica 1 to replica 2.=20
replicationScheduleDN: cn=3Dschedule1, cn=3Dreplica1,=20
ou=3Daccounting, o=3Dyour company=20
replicaDN: cn=3Dreplica2, ou=3Daccounting, o=3Dyour company=20
=20
dn: cn=3Dagreement1->3, cn=3Dreplica1, ou=3Daccounting, o=3Dyour comp=
any=20
objectclass: replicaAgreement=20
cn: agreement1->3=20
description: Replica agreement constraining replication sessions=20
from replica 1 to replica 3.=20
replicationScheduleDN: cn=3Dschedule1, cn=3Dreplica1,=20
ou=3Daccounting, o=3Dyour company=20
replicaDN: cn=3Dreplica3, ou=3Daccounting, o=3Dyour company=20
=20
dn: cn=3Dschedule1, cn=3Dreplica1, ou=3Daccounting, o=3Dyour company=20
objectclass: replicaEventSchedule=20
cn: schedule1=20
description: schedule that initiates replication one minute=20
after any update (including to the updateVector) is made=20
to the replica.=20
secondsToWaitDefault: 60=20
updateVectorTrigger: TRUE=20
=20
dn: cn=3Dagreement2->1, cn=3Dreplica2, ou=3Daccounting, o=3Dyour comp=
any=20
objectclass: replicaAgreement=20
cn: agreement2->1=20
description: Replica agreement constraining replication sessions=20
from replica 2 to replica 1.=20
replicationScheduleDN: cn=3Dschedule2, cn=3Dreplica2,=20
ou=3Daccounting, o=3Dyour company=20
replicaDN: cn=3Dreplica1, ou=3Daccounting, o=3Dyour company=20
=20
dn: cn=3Dagreement2->3, cn=3Dreplica2, ou=3Daccounting, o=3Dyour comp=
any=20
objectclass: replicaAgreement=20
cn: agreement2->3=20
description: Replica agreement constraining replication sessions=20
from replica 2 to replica 3.=20
replicationScheduleDN: cn=3Dschedule2, cn=3Dreplica2,=20
ou=3Daccounting, o=3Dyour company=20
replicaDN: cn=3Dreplica2, ou=3Daccounting, o=3Dyour company=20
=20
dn: cn=3Dschedule2, cn=3Dreplica2, ou=3Daccounting, o=3Dyour company=20
objectclass: replicaEventSchedule=20
cn: schedule2=20
description: schedule that initiates replication two minutes=20
after any update (including to the updateVector) is made=20
to the replica.=20
secondsToWaitDefault: 120=20
updateVectorTrigger: TRUE=20
=20
dn: cn=3Dagreement3->1, cn=3Dreplica3, ou=3Daccounting, o=3Dyour comp=
any=20
objectclass: replicaAgreement=20
cn: agreement3->1=20
description: Replica agreement constraining replication sessions=20
=20
Huber, et al Expires April 2004 [Page 24] =0C
LDUP Information Model =20
from replica 3 to replica 1.=20
replicationScheduleDN: cn=3Dschedule3, cn=3Dreplica3,=20
ou=3Daccounting, o=3Dyour company=20
replicaDN: cn=3Dreplica1, ou=3Daccounting, o=3Dyour company=20
=20
dn: cn=3Dagreement3->2, cn=3Dreplica3, ou=3Daccounting, o=3Dyour comp=
any=20
objectclass: replicaAgreement=20
cn: agreement3->2=20
description: Replica agreement constraining replication sessions=20
from replica 3 to replica 2.=20
replicationScheduleDN: cn=3Dschedule3, cn=3Dreplica3,=20
ou=3Daccounting, o=3Dyour company=20
replicaDN: cn=3Dreplica2, ou=3Daccounting, o=3Dyour company=20
=20
dn: cn=3Dschedule3, cn=3Dreplica3, ou=3Daccounting, o=3Dyour company=20
objectclass: replicaEventSchedule=20
cn: schedule3=20
description: schedule that initiates replication one minute=20
after any update (including to the updateVector) is made=20
to the replica.=20
secondsToWaitDefault: 60=20
updateVectorTrigger: TRUE=20
=20
In this example, replication sessions are limited such that they=20
will begin one or two minutes after an update is made to any one=20
replica, depending on the replica on which the update was made. =20
This "constrains" the replication session initiation from the=20
default of "immediate replication" of updates.=20
=20
There are many ways in which the constraints around when to=20
initiate and/or accept replication sessions between two replicas. =20
The information model defined here provides a small set of options. =20
More elaborate policies can be defined and this is left as a future=20
exercise. It is hoped that the work from the Policy workgroup can=20
offer schema that would support the creation of these complex=20
policies.=20
=20
=20
9. Object Identifier Assignments=20
=20
The LDUP OID prefix is =20
=20
ID ::=3D OBJECT IDENTIFIER=20
=20
ldup ID ::=3D { joint-iso-ccitt(2) country(16) us(840)=20
organization(1) novell(113719) novell-internal-
OIDS(1) ldup(142) }=20
=20
The OID assignments defined in this document are:=20
=20
Attributes:=20
=20
attributeExclusionFilter ID ::=3D 2.16.840.1.113719.1.142.4.1=20
attributeInclusionFilter ID ::=3D 2.16.840.1.113719.1.142.4.2=20
=20
Huber, et al Expires April 2004 [Page 25] =0C
LDUP Information Model =20
replicationStatus ID ::=3D 2.16.840.1.113719.1.142.4.3=20
replicaType ID ::=3D 2.16.840.1.113719.1.142.4.4=20
secToWaitClass1 ID ::=3D 2.16.840.1.113719.1.142.4.5.1 -=20
OBSOLETE=20
secToWaitClass2 ID ::=3D 2.16.840.1.113719.1.142.4.5.2 -=20
OBSOLETE=20
secToWaitClass3 ID ::=3D 2.16.840.1.113719.1.142.4.5.3 -=20
OBSOLETE=20
secToWaitClass4 ID ::=3D 2.16.840.1.113719.1.142.4.5.4 -=20
OBSOLETE=20
secToWaitClass5 ID ::=3D 2.16.840.1.113719.1.142.4.5.5 -=20
OBSOLETE=20
updateVector ID ::=3D 2.16.840.1.113719.1.142.4.6=20
replicaURI ID ::=3D 2.16.840.1.113719.1.142.4.x=20
replicaSecondaryURI ID ::=3D 2.16.840.1.113719.1.142.4.x=20
lostAndFoundEntryDN ID ::=3D 2.16.840.1.113719.1.142.4.x=20
replicaOnline ID ::=3D 2.16.840.1.113719.1.142.4.x=20
replicaDN ID ::=3D 2.16.840.1.113719.1.142.4.x=20
replicationMechanismOID ID ::=3D 2.16.840.1.113719.1.142.4.x=20
replicationCredentialsDN ID ::=3D 2.16.840.1.113719.1.142.4.x=20
replicationScheduleDN ID ::=3D 2.16.840.1.113719.1.142.4.x=20
updateVectorTrigger ID ::=3D 2.16.840.1.113719.1.142.4.x=20
secondsToWaitDefault ID ::=3D 2.16.840.1.113719.1.142.4.x=20
secondsToWait1 ID ::=3D 2.16.840.1.113719.1.142.4.x=20
attrReplicationGroup1 ID ::=3D 2.16.840.1.113719.1.142.4.x=20
secondsToWait2 ID ::=3D 2.16.840.1.113719.1.142.4.x=20
attrReplicationGroup2 ID ::=3D 2.16.840.1.113719.1.142.4.x=20
scheduleTimePeriod ID ::=3D 2.16.840.1.113719.1.142.4.x=20
scheduleMonthOfYearMask ID ::=3D 2.16.840.1.113719.1.142.4.x=20
scheduleDayOfMonthMask ID ::=3D 2.16.840.1.113719.1.142.4.x=20
scheduleDayOfWeekMask ID ::=3D 2.16.840.1.113719.1.142.4.x=20
scheduleTimeOfDayMask ID ::=3D 2.16.840.1.113719.1.142.4.x=20
scheduleLocalOrUtcTime ID ::=3D 2.16.840.1.113719.1.142.4.x=20
supportedReplicationProtocols ID ::=3D 2.16.840.1.113719.1.142.4.x=20
replicaContextRoots ID ::=3D 2.16.840.1.113719.1.142.4.x=20
replicaSubentries ID ::=3D 2.16.840.1.113719.1.142.4.x=20
=20
Object Classes:=20
=20
eventScheduledSubentry ID ::=3D 2.16.840.1.113719.1.142.6.1 -=20
OBSOLETE=20
nameContext ID ::=3D 2.16.840.1.113719.1.142.6.2.1 -=20
OBSOLETE=20
replicaSubentry ID ::=3D 2.16.840.1.113719.1.142.6.3.1 -=20
OBSOLETE=20
replicaAgreementSubentry ID ::=3D 2.16.840.1.113719.1.142.6.4.1 =96=20
OBSOLETE=20
replicationContext ID ::=3D 2.16.840.1.113719.1.142.6.2.2=20
replicaSubEntry-2 ID ::=3D 2.16.840.1.113719.1.142.6.3.2=20
replicaAgreementSubEntry-2 ID ::=3D 2.16.840.1.113719.1.142.6.4.2 -=20
OBSOLETE=20
eventScheduledSubentry ID ::=3D 2.16.840.1.113719.1.142.6.1 -=20
OBSOLETE=20
replicaEventSchedule ID ::=3D 2.16.840.1.113719.1.142.6.x.1=20
=20
Huber, et al Expires April 2004 [Page 26] =0C
LDUP Information Model =20
replicaTimeSchedule ID ::=3D 2.16.840.1.113719.1.142.6.x.1=20
replicaAgreement ID ::=3D TBD=20
=20
Note: Object Class OIDs have version numbers, Attribute OIDs=20
don't.=20
=20
10. Security Considerations=20
=20
Many of the attributes and object classes described in this=20
document should be considered "security sensitive", and protected=20
from unintended modification by LDAP servers. Generally, creating=20
Naming Contexts, Replicas and Replica Agreement entries should only=20
be allowed by directory administrators who are authorized to do so.=20
=20
The values of attributes defined here are intended to control the=20
behavior of the directory service agents, themselves. Unintended=20
modification of their values may result in incomplete replication=20
of data (if ldapSearchFilter or attributeExclusionFilter are=20
changed), inappropriate disclosure of information (if=20
attributeInclusionFilter is changed), or updates may be lost (if=20
updateVector is changed).=20
=20
To avoid depending to much on the ldapAccessPoint values for other=20
replicas, connections between LDAP servers for the purpose of=20
replication MUST ALWAYS be authenticated using an authentication=20
mechanism appropriate for the nature of information to be=20
exchanged.=20
=20
References=20
=20
[LDUP Model] - J. Merrells, E. Reed, U. Srinivisan, "An Abstract=20
Model of LDAP Replication", Internet draft, draft-ietf-ldup-model-
08.txt, March 2003.=20
=20
[LDUP MRM] =96 R. Moats, R. Huber, J. McMeeking, =93Mandatory LDAP=20
Replica Management,=94 Internet Draft, draft-ietf-ldup-mrm-02.txt,=20
March 2003.=20
=20
=20
[LDAP Subentry] =96 K. Zeilenga, Stephen Legg, "Subentries in LDAP",=20
Internet draft, draft-zeilenga-ldap-subentry-07.txt, August 2002.=20
=20
[LDUP Update Protocol] =96 J. McMeeking, "The LDUP Replication Update=
=20
Protocol", Internet Draft, draft-ietf-ldup-protocol-04.txt, March=20
2003.=20
=20
[Policy Schema] - J. Strassner, B. Moore, R. Moats, E. Ellesson, =20
"Policy Core LDAP Schema", Internet draft, draft-ietf-policy-core-
schema-16.txt, October 2002.=20
=20
[RFC822] =96 D. Crocker, "STANDARD FOR THE FORMAT OF ARPA INTERNET=20
TEXT MESSAGES", August 1982, RFC 822.=20
=20
=20
Huber, et al Expires April 2004 [Page 27] =0C
LDUP Information Model =20
[RFC2251] =96 M. Wahl, T. Howes, S. Kille, "Lightweight Directory=20
Access Protocol (v3)", December 1997, RFC 2251.=20
=20
[RFC2252] =96 M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight=20
Directory Access Protocol (v3): Attribute Syntax Definitions",=20
December 1997, RFC 2252.=20
=20
[RFC2255] =96 T. Howes, M. Smith, =93The LDAP URL Format=94, December=
=20
1997, RFC 2255.=20
=20
[RFC2596] - 2596 M. Wahl, T. Howes, =93Use of Language Codes in=20
LDAP=94, May 1999, RFC 2596.=20
=20
[RFC2820] =96 E. Stokes, D. Byrne, B. Blakley, P. Behara, =93Access=20
Control Requirements for LDAP,=94 May 2000, RFC 2820.=20
=20
[RFC3060] =96 B. Moore, E. Ellesson, J. Strassner, A. Westerinen,=20
"Policy Core Information Model =96 Version 1 Specification", February=
=20
2001, RFC 3060.=20
=20
[RFC3384] - E. Stokes, R. Weiser, R. Moats, R. Huber, "Lightweight=20
Directory Access Protocol (version 3) Replication Requirements",=20
October 2002, RFC 3384.=20
=20
[X518] - ITU-T Recommendation X.518 (1997) | ISO/IEC 9594-4:1998,=20
Information Technology =96 Open Systems Interconnection =96 The=20
Directory: Procedures for Distributed Operation.=20
=20
[X680] - ITU-T Recommendation X.680 (1994) | ISO/IEC 8824-1:1995,=20
Information technology =96 Abstract Syntax Notation One (ASN.1):=20
Specification of Basic Notation.=20
=20
11. Copyright Notice=20
=20
Copyright (C) The Internet Society (2001). All Rights Reserved. =20
=20
This document and translations of it may be copied and furnished to=20
others, and derivative works that comment on or otherwise explain=20
it or assist in its implementation may be prepared, copied,=20
published and distributed, in whole or in part, without restriction=20
of any kind, provided that the above copyright notice and this=20
paragraph are included on all such copies and derivative works.=20
However, this document itself may not be modified in any way, such=20
as by removing the copyright notice or references to the Internet=20
Society or other Internet organizations, except as needed for the=20
purpose of developing Internet standards in which case the=20
procedures for copyrights defined in the Internet Standards process=20
must be followed, or as required to translate it into languages=20
other than English.=20
=20
The limited permissions granted above are perpetual and will not be=20
revoked by the Internet Society or its successors or assigns.=20
=20
=20
Huber, et al Expires April 2004 [Page 28] =0C
LDUP Information Model =20
This document and the information contained herein is provided on=20
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET=20
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR=20
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF=20
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=20
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=20
=20
12. Acknowledgements=20
=20
The authors would like to thank Ed Reed and Tim Han, the authors of=20
the original infomod draft, for all their work.=20
=20
The IETF takes no position regarding the validity or scope of any=20
intellectual property or other rights that might be claimed to=20
pertain to the implementation or use of the technology described in=20
this document or the extent to which any license under such rights=20
might or might not be available; neither does it represent that it=20
has made any effort to identify any such rights. Information on the=20
IETF's procedures with respect to rights in standards-track and=20
standards-related documentation can be found in BCP-11. Copies of=20
claims of rights made available for publication and any assurances=20
of licenses to be made available, or the result of an attempt made=20
to obtain a general license or permission for the use of such=20
proprietary rights by implementers or users of this specification=20
can be obtained from the IETF Secretariat.=20
=20
The IETF invites any interested party to bring to its attention any=20
copyrights, patents or patent applications, or other proprietary=20
rights which may cover technology that may be required to practice=20
this standard. Please address the information to the IETF Executive=20
Director.=20
=20
13. Authors' Addresses=20
=20
Richard Huber=20
AT&T Laboratories=20
Email: [email protected]=20
=20
John McMeeking=20
IBM=20
Email: [email protected] =20
=20
Ryan Moats=20
Lemur Networks, Inc.=20
Email: [email protected]=20
=20
LDUP Mailing List: [email protected]=20
=20
=20
Huber, et al Expires April 2004 [Page 29] =0C
--------------050608070409010502060409--