Fascinating...I'm attaching the .doc and resulting .txt file I'm using for the LDUP information model i-d...I've tried your doc and got the same results (see t3.txt, below)... In the finest tradition of reuseable code, I didn't invent this...another guy here at Novell passed it on to me (Scott Isaccson, who worked on the Internet Print Protocol spec)...where he came up with it, I'm not sure... Ed ---------------------- Ed Reed, Technologist Novell, Inc. +1 801 861-3320 >>> "David Chadwick" <d.w.chadwick@iti.salford.ac.uk> 12/22/1998 10:11:55 >>> Date forwarded: Mon, 21 Dec 1998 16:09:55 -0800 (PST) Date sent: Mon, 21 Dec 1998 16:09:58 -0800 (PST) From: RL Bob Morgan <Bob.Morgan@Stanford.EDU> > I suggest not bothering. I suggest that the addition of page > breaks/headers/footers in I-Ds is an anachronism that wastes authors' > preparation time (e.g. yours here), too true. I spent (i.e. wasted) nearly as many hours trying to get the page numbers etc inserted correctly in .txt format, as in producing the ID in the first place, and I failed. I then spent more hours trying to get the generic printer to work, which it does not (if you dont believe me I attach a simple one sentence word document to this message with the accompanying text prn file (renamed to .txt) >is pointless when reading docs in > browsers/editors (where I suspect the vast majority of them are read), and > only makes it harder for readers to compare successive versions of drafts. > For what it's worth I made this suggestion in the recent thread on the > main IETF list about document formats and received only positive comments > ... > great. So what are we going to do about it? the main benefit I can see from using .txt format is that you send 2k of bits instead of a mega 20k using Word, to say essentially the same thing. (see the current attachments) So I dont advocate moving to Word, as downloading my email by modem will then take ten times as long. But .txt without headers and footers would certainly be a big step forward, at least for IDs David > - RL "Bob" > > > > *************************************************** David Chadwick IT Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 370 957 287 Email D.W.Chadwick@iti.salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string A7OX-K3QT-JPTU ***************************************************
T
h
i
s
i
s
a
t
e
s
t
d
o
c
u
m
e
n
t
t
o
t
h
e
p
r
i
n
t
e
r
Attachment:
draft-reed-ldup-infomod-00-4.doc
Description: MS-Word document
INTERNET-DRAFT
draft-reed-ldup-infomod-00.txt
Ed Reed
Novell, Inc.
November 18, 1998
LDUP Replication Information Model
Copyright (C) The Internet Society (1998). All Rights Reserved.
1. Status of this Memo
This draft, file name draft-reed-ldup-infomod-00.txt, is intended to
be become a Proposed Standard RFC, to be published by the IETF Working
Group LDUP, when it is formed. Distribution of this document is
unlimited. Comments should be sent to the LDUP Replication mailing
list <ldup-repl@external.cisco.com> or to the author(s).
This document is an Internet-Draft. 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".
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim),
ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
This Internet-Draft expires on 18 May 1999.
2. Abstract
[LDUP Model] describes the architectural approach to replication of
LDAP directory contents. This document describes the information
model and schema elements which support LDAP Replication Services
which conform to [LDUP Model].
Directory schema is extended to provide object classes, subentries,
and attributes to describe areas of the namespace which are under
Reed [Page 1]
Expires 18 May 1999
INTERNET-DRAFT 18 November 1998
LDUP Replication Information Model
common administrative authority, units of replication (ie, subtrees,
or partitions of the namespace, which are replicated), servers which
hold replicas of various types for the various partitions of the
namespace, which namespaces are held on given servers, and the
progress of various namespace management and replication operations.
Among other things, this knowledge of where directory content is
located will provide the basis for dynamic generation of LDAP
referrals for clients who can follow them.
The controlling framework by which the relationships, types, and
health of replicas of the directory content will be defined so that,
as much as possible, directory content is itself used to monitor and
control the environment.
Security information, including access control policy identifiers and
information will be treated as directory content by the replication
protocols when specified by the LDAPEXT group.
The information model will describe required and optional house-
keeping duties for compliant systems to implement, such as garbage
collection of deleted objects, reconciliation of moved and renamed
objects, update sequencing and transaction bracketing of changes, etc.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. The
sections below reiterate these definitions and include some additional
ones.
Reed [Page 2]
Expires 18 May 1999
INTERNET-DRAFT 18 November 1998
LDUP Replication Information Model
Table of Contents
1. Status of this Memo 1
2. Abstract 1
3. Introduction 3
3.1 Scope 3
3.2 Terms and Definitions 4
4. Data design: 4
5. Directory Knowledge 4
6. Schema 5
6.1 Syntax Definitions 5
6.1.1 lDAPChangeSequenceNumber 5
6.1.2 lDAPAccessPointSyntax 6
6.2 Attribute Definitions 7
6.2.1 lDAPAccessPoint 7
6.2.2 attributeExclusionFilter 7
6.2.3 attributeInclusionFilter 8
6.2.4 lDAPSearchFilter 8
6.2.5 replicationStatus 9
6.2.6 replicaType 10
6.2.7 updateVector 11
6.3 Class Definitions 11
6.3.1 lDAPsubEntry 11
6.3.2 nameContext 12
6.3.3 replicaSubentry 12
6.3.4 replicaAgreementSubentry 13
6.3.5 scheduleSubentry Class 14
6.4 Matching Rule Specifications 15
6.4.1 LDAPChangeSequenceNumberOrderingMatch 15
7. Security Considerations 15
8. References 16
9. Copyright Notice 16
10.Acknowledgements 17
11.Author's Address 17
3. Introduction
3.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.
Reed [Page 3]
Expires 18 May 1999
INTERNET-DRAFT 18 November 1998
LDUP Replication Information Model
3.2 Terms and Definitions
Definitions are provided in [LDUP Requirements], and may be reproduced
here for the convenience of the reader.
4. 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 naming contexts
[RFC2251]. Directory subentries [X501] are used to hold information
about replicas and replica agreements.
5. 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.
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 Naming Context Auxiliary Class (nameContext) is added to container
objects which may have separately defined replication policy.
Immediately subordinate to a Naming Context object are the Replica
Subentry containers which identify where the identified replica
resides (ie, its LDAP Access Point), its type (Primary, Updateable,
Reed [Page 4]
Expires 18 May 1999
INTERNET-DRAFT 18 November 1998
LDUP Replication Information Model
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).
6. Schema
6.1 Syntax Definitions
For the purposes of defining the encoding rules for attribute
syntaxes, the BNF definitions in section 4.1 of [RFC2252] will be
used. They are based on the BNF styles of [RFC822].
6.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 are no whitespace separators, although there may be
embedded whitespace in the value of replicaID.
Note there is some discussion ongoing as to whether the replicaID
should be considered before the seqno, or after. This definition will
be changed to support the consensus when reached.
LDAPChangeSequenceNumber = GeneralizedZTime "$" replicaID "$" seqno
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
seqno = numericstring
The GeneralizedTime is used as described (cf. [X680] section 39.3 case
b) without separators or whitespace, and representing a coordinated
universal time (i.e., Greenwich Mean Time, or GMT). All times
Reed [Page 5]
Expires 18 May 1999
INTERNET-DRAFT 18 November 1998
LDUP Replication Information Model
referenced by this syntax MUST be normalized to GMT - no local times,
nor time zone offsets are permitted.
The ReplicaID is the distinguished commonName (CN) of the Replica of
this Naming Context where the event associated with this
LDAPChangeSequenceNumber occurred.
The seqno is a sequence number which is used to order two events with
the same Generalized Time and ReplicaID. See the
LDAPChangeSequenceNumberMatch and
LDAPChangeSequenceNumberOrderingMatch matching rules, defined
elsewhere in this document.
6.1.2 lDAPAccessPointSyntax
( 1.3.6.1.4.1.1466.115.121.1.TBD DESC 'LDAP Access Point' )
Values in this syntax are encoded according to the following BNF.
LDAPAccessPointSyntax = DN "$" OTHER "$" labeledURIList
DN = dstring
OTHER = dstring
labeledURIList = qdstrings
dstring = 1*utf8
utf8 = <any sequence of octets formed from the UTF-8 [RFC2044]
transformation of a character from [ISO10646] >
DN is the distinguished name of the LDAP Service Agent to which this
LDAP Access Point Syntax refers. It is single valued.
OTHER - Any additional information to be stored with the reference,
such as connection-specific credentials, etc. This is a single valued
string. Note: this means that the OTHER field applies to ALL of the
labeledURIs in the labeledURIList, so if OTHER is used to store
credential information, for instance, that credential information
needs to be able to be used with ANY of the labeledURI addresses
listed.
labeledURIList is used as defined in [RFC2079], as a HINT (i.e.,
cached address) as to where an LDAP replication client may connect to
the LDAP service named in DN. There may be one LabeledURI, or more
than one inside a pair of matched parentheses. Each LabeledURI is
single-quoted so they can be separated if there are more than one.
The rational for using LabeledURI format is that it is already defined
in [RFC2079], it is generally extensible (via the normal scheme
extensions mechanisms and registration systems being defined elsewhere
Reed [Page 6]
Expires 18 May 1999
INTERNET-DRAFT 18 November 1998
LDUP Replication Information Model
in the IETF), which means it should be usable for storing any kind of
address (such as IPX, AppleTalk, OSI, Ipv6, or whatever). It is
flexible enough to store information about the protocols to be used
(such as ldap://), network addresses using either dotted quads or DNS
names (such as ldap://www.nldap.com, or ldap://192.108.102.213), and
port numbers (such as ldap://www.nldap.com:389), according to the
scheme definition used, as needed.
Multiple labeledURI values are permitted, so that multi-homed and
clustered LDAP DSAs can be conveniently represented, and so that each
of the various protocols by which the replica can be reached may be
cached.
As mentioned, the labeledURI in this syntax is a HINT. The
authoritative address information is expected to be stored on the
object named in the DN of the LDAP Access Point. However, because a
copy of the object named may not be held on an LDAP DSA which
references it (i.e., it may be named in a Naming Context of the DIT
which is not replicated locally), it is convenient to cache the
addresses where it may be found, here.
6.2 Attribute Definitions
6.2.1 lDAPAccessPoint
( {LDUPATTR 2} NAME 'lDAPAccessPoint'
SYNTAX LDAPAccessPointSyntax
USAGE dSAOperation )
The lDAPAccessPoint names a DSA in its DN component, provides an
optional OTHER string to store information specific to that DSA, and a
list of one or more network addresses, in the form of a labeledURI,
which may be used to bind to that DSA.
A common use of the OTHER string is intended to be to hold credentials
needed to authenticate to the other DSA, but I have real heart burn
with that. If the lDAPAccessPoint attributes on replica agreement
subentries are replicated to other DSAs, then the secrecy of such
authentication credentials is lost.
The OTHER string may be useful, but the author is not sure how so.
6.2.2 attributeExclusionFilter
( {LDUPATTR 3} NAME 'attributeExclusionFilter'
SYNTAX OCTET STRING
Reed [Page 7]
Expires 18 May 1999
INTERNET-DRAFT 18 November 1998
LDUP Replication Information Model
SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )
The attributeExclusionFilter is intended to contain a list of
attributes in the form of an AttributeDescriptionList as described in
section 4.5.1. Search Request of [RFC2251] with the following
interpretation: an empty attributeExclusionFilter means that no
attributes are excluded; the special values ?*? and ?1.1? mean that
ALL attributes are excluded.
A non-empty attributeExclusionFilter attribute on a replica subEntry
describes the attributes NOT PRESENT on entries held by that replica.
Replicas MUST NOT accept changes for attributes they're not permitted
to hold, per the attributeInclusionFilter and attributeExclusionFilter
attributes on their replica subEntry.
A non-empty attributeExclusionFilter attribute on a
replicationAgreement subEntry describes which additional attributes
are to be excluded from the updates to be sent from the supplier
replica to the consumer replica.
6.2.3 attributeInclusionFilter
( {LDUPATTR 4} NAME 'attributeInclusionFilter'
SYNTAX OCTET STRING
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 attributeIncludionFilter and
attributeExclusionFilter attributes on their replica subEntry.
6.2.4 lDAPSearchFilter
( {LDUPATTR 5} NAME 'lDAPSearchFilter'
SYNTAX caseExactString
SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )
Reed [Page 8]
Expires 18 May 1999
INTERNET-DRAFT 18 November 1998
LDUP Replication Information Model
The lDAPSearchFilter is intended to contain a Filter as described in
section 4.5.1. Search Request of [RFC2251].
A non-empty lDAPSearchFilter attribute on a replica subEntry describes
the contents of that replica. Replicas MUST NOT accept changes for
objects they're not permitted to hold, per the lDAPSearchFilter
attribute on their replica subEntry.
A non-empty lDAPSearchFilter attribute on a replicationAgreement
subEntry describes which other objects are to be excluded from the
updates to be sent from the supplier replica to the consumer replica.
Note that because the replica asserts and controls what entries it
holds, a replication agreement MAY NOT send changes for objects the
replica does not hold, but if it does, the consuming replica MUST NOT
accept them.
6.2.5 replicationStatus
( {LDUPATTR 9} NAME 'replicationStatus'
DESC 'human readable status of last replication attempt'
SYNTAX DirectoryString
SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )
The replicationStatus attribute MAY be used to hold a human readable
message describing the most recent replication session attempt for a
replicationAgreement.
For example, such a messages might include
1) [1998/08/05 16:22:03Z] Success
2) [1998/08/05 16:23:22Z] Failure - Server too busy, try again
3) [1998/08/05 17:02:15Z] Failure - Unable to connect to DSA
4) [1998/08/06 00:23:01Z] Failure - Authentication failed
5) [1998/08/06 00:32:01Z] Failure - lost connection, reset by peer
It is suggested, but not required, that the time of the attempt
success or failure, the result of the attempt, and any additional
information about a failure be included in the message.
It is suggested, but not required, that the messages be stored with
language tags (English, French, German, Japanese, Chinese, per [LANG
Reed [Page 9]
Expires 18 May 1999
INTERNET-DRAFT 18 November 1998
LDUP Replication Information Model
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,
but do not belong in the directory content itself.
6.2.6 replicaType
( {LDUPATTR 10} NAME 'replicaType'
DESC 'Enum: 0-reserved, 1-Primary, 2-Updateable, 3-ReadOnly, all
others reserved'
EQUALITY integerMatch
SYNTAX INTEGER
SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )
ReplicaType is a simple enumeration, used to identify what kind of
replica is being described in a Replica object entry.
A ReadOnly replica only accepts LDAP Search operations (to Read
entries, list containers, and search for entries). Because no updates
ever originate from ReadOnly replicas, they never have changes to send
to another replica. However, a ReadOnly replica may be designated a
supplier DSA in a replica agreement, if it is simply passing along
information it receives from other Updateable replicas about entries
and their changes.
ReadOnly replicas may be incomplete replicas.
An Updateable replica may accept both LDAP Search operations (to read,
list, or search entries), as well as modification operations (to add,
modify, or delete entries).
The consequences of having incomplete updateable replicas are not
fully understood. LDAP DSAs MAY require updateable replicas to be
complete replicas.
A Primary replica is an Updateable replica, but it is ?more special?
than other Updateable replicas. When LDAP application want to direct
their operations to a single replica, so that the application can be
sure that all application LDAP modification (add, delete, modify)
operations will be immediately visible to application readers, the
Primary replica is a good choice. Such a use would be consistent with
High Confidence DAP option [X518]. One such 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.
Reed [Page 10]
Expires 18 May 1999
INTERNET-DRAFT 18 November 1998
LDUP Replication Information Model
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.
6.2.7 updateVector
( {LDUPATTR 12} NAME 'updateVector'
SYNTAX lDAPChangeSequenceNumberSyntax
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.
This uniqueness constraint may mean that the syntax should be a single
list, or array, of values, rather than the set of values?discussion on
the list to follow. Discussion is invited on the list.
6.3 Class Definitions
6.3.1 lDAPsubEntry
( 1.3.6.1.4.1.1466.115.121.1.?? NAME 'LDAPsubEntry'
DESC 'Limited X.501 Subentry class, named by cn'
SUP top STRUCTURAL MUST ( cn ) )
By agreement, LDUP will use subentries with commonName attributes
instead of subtreeSpecification attributes.
Reed [Page 11]
Expires 18 May 1999
INTERNET-DRAFT 18 November 1998
LDUP Replication Information Model
Note: the use of the [X501] subEntry is a matter of convenience, and
does not constitute the "nose of the camel". That is, X.500 makes
many uses of subEntries, and we don't claim to be doing them all.
However, it's a very convenient concept, and its usefulness has been
demonstrated (by all those very things that X.500 uses them for!). We
choose to use them, because they're useful, flexible, extensible, and
easy to specify. They're even easy to understand, once the reader
figures out that they're just another object class (with possibly
special treatment - they may be treated as "operational objects" in
much the same way that "operational attributes" are not regularly
provided in search results and read operations when only user
attributes are requested).
NOTE: As other uses for the lDAPsubEntry object class are found (in
the Access Control extensions design work, and in the non-global
schema representation work, it is probably desireable to move its
definition to a separate, stand-alone document)
6.3.2 nameContext
( TBD NAME 'nameContext' SUP top AUXILIARY )
The nameContext auxiliary class, when present on an object, indicates
the beginning, or root, of a naming context. The naming context is
said to be rooted at the entry with the nameContext auxiliary class in
its list of object classes. The root-most entry of a naming context
is the entry with the nameContext 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 lDAPsubEntry subordinate to the nameContext,
instead.
The attribute nameContextCreationTimestamp used here in previous
drafts has been eliminated as redundant. The lDAPChangeSequenceNumber
associated with the nameContext value in the list of objectClasses
attribute serves the same purpose.
6.3.3 replicaSubentry
( TBD NAME 'replicaSubentry' SUP lDAPsubEntry STRUCTURAL
MUST (cn, replicaID, lDAPAccessPoint, replicaType)
Reed [Page 12]
Expires 18 May 1999
INTERNET-DRAFT 18 November 1998
LDUP Replication Information Model
MAY (attributeExclusionFilter, attributeInclusionFilter,
description, lDAPSearchFilter, updateVector) )
The replicaID must be unique for all entries of type replicaSubentry
for a particular naming context.
Entries of type replicaSubentry MUST be named by their cn attribute.
The attributes attributeExclusionFilter, attributeInclusionFilter, and
lDAPSearchFilter, 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
lDAPSearchFilter attribute identifies entries whose values may or may
not be sent. The attributeExclusionFilter names attributes which are
not to be sent. The attributeInclusionFilter names attributes which
may be sent.
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.
6.3.4 replicaAgreementSubentry
( TBD NAME 'replicaAgreementSubentry' SUP lDAPsubEntry STRUCTURAL
MUST ( cn )
MAY ( attributeExclusionFilter, description, lDAPSearchFilter,
replicaDN, replicationMechanismOID, replicationStatus, schedule ) )
Entries of type replicaSubentry MUST be named by their cn attribute.
The attributes attributeExclusionFilter, and lDAPSearchFilter, 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. The lDAPSearchFilter attribute identifies entries whose
values may or may not be sent. The attributeExclusionFilter names
attributes which are not to 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:
Reed [Page 13]
Expires 18 May 1999
INTERNET-DRAFT 18 November 1998
LDUP Replication Information Model
1) the lDAPSearchFilter from the replica subentry defines a set of
entries;
2) the lDAPSearchFilter from the replicaAgreementSubentry defines a
set of entries;
3) the intersection of the two lDAPSearchFilter sets constitutes the
set of entries about which changes will be sent;
4) the attributeInclusionFilter from the replica subentry defines a
set of attributes which may be sent, less exclusions;
5) the union of attributes excluded by the attributeExclusionFilter
from the replicasubentry and the attributeExclusionFilter from the
replicaAgreementSubentry defines a set of attributes which may not
be sent;
6) the subtraction of attributes which may not be sent by (5) from
the attributes which may be sent by (4) and which are present on
entries which may be sent by (3) 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 DN 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 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 schedule, if present, names one or more entries of type
scheduleSubentry which govern the schedule for replication attempts.
If not present, replication shall be attempted when there are changes
to be sent.
6.3.5 scheduleSubentry Class
Need to pull this from Oracle's proposal?along with the attributes it
specifies, or define it separately in another draft.
Reed [Page 14]
Expires 18 May 1999
INTERNET-DRAFT 18 November 1998
LDUP Replication Information Model
6.4 Matching Rule Specifications
6.4.1 LDAPChangeSequenceNumberOrderingMatch
As mentioned above, there is ongoing discussion as to the ordering to
be used. This text will be changed to reflect the consensus when it
is reached.
Two lDAPChangeSequenceNumbers are compared according to the following:
1) the GeneralizedZTime components are compared (they may be compared
using the same algorithm as generalizedTimeOrderingMatch ?
1.3.6.1.4.1.1466.115.121.1.24 [RFC2252]), and if different, the
one with the later (highest) date and time is considered ?greater
than? the other; if the same, the comparison continues?
2) the replicaID components are compared, and if different, the one
with the lower value (implying that the replica was created prior
to the other replica ? such that the ?oldest? replica is more
?senior? to ?newer? ones; in most cases, the ?oldest? replica
will likely also be the Primary replica, too) is considered ?more
preferred? than the other; if the same, the comparison continues?
3) the seqno components are compared, and if different, the one with
the higher numeric value is considered ?greater than? the other;
if the same, the two entries are the same, and so they match for
equality.
7. 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
Reed [Page 15]
Expires 18 May 1999
INTERNET-DRAFT 18 November 1998
LDUP Replication Information Model
replication MUST ALWAYS be authenticated using an authentication
mechanism appropriate for the nature of information to be exchanged.
8. References
[LANG TAG] ? M. Wahl, T. Howes, ?Use of Language Codes in LDAP?,
Internet draft, draft-ietf-ldapext-lang-01.txt
[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
[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
[X525] - ITU-T Recommendation X.525 (1997) | ISO/IEC 9594-9:1997,
Information Technology ? Open Systems Interconnection ? The Directory:
Replication
[X680] - ITU-T Recommendation X.680 (1994) | ISO/IEC 8824-1:1995,
Information technology ? Abstract Syntax Notation One (ASN.1):
Specification of Basic Notation
9. Copyright Notice
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.
Reed [Page 16]
Expires 18 May 1999
INTERNET-DRAFT 18 November 1998
LDUP Replication Information Model
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
10. Acknowledgements
The use of subEntry object class to store Replica and Replication
Agreement information is due primarily to the lucid explanation by
Mark Wahl, Innosoft, of how they could be used and extended.
11. Author's Address
Edwards E. Reed
Novell, Inc.
122 E 1700 S
Provo, UT 84606
USA
E-mail: Ed_Reed@Novell.com
LDUP Engineering Mailing List: ldup-repl@external.cisco.com
Reed [Page 17]
Expires 18 May 1999