WDIFF

draft-ietf-ldup-replica-req-02.txt --> draft-ietf-ldup-replica-req-04.txt

LDAP Duplication/Replication/Update Tivoli Systems
Protocols WG Russel F. Weiser
Intended Category: Informational Draft Digital Signature Trust Co.
Expires 21 April
Expires: March 2001 Ryan D. Moats
Coreon, Inc.
Richard V. Huber
AT&T Laboratories
September 2000 Ellen Stokes
IBM
21 October 1999

LDAP V3

LDAPv3 Replication Requirements

<draft-ietf-ldup-replica-req-02.txt>
draft-ietf-ldup-replica-req-04.txt

Status of this This Memo

This document is am an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-
Drafts. Internet-Drafts.

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 "work in
progress.'' progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
http://www.ietf.org/ietf/lid-abstracts.txt.

The list of Internet-Drafts Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Abstract

This document discusses the fundamental requirements for replication of
data accessible via the LDAPv3 [RFC2251] protocol. It is intended to be
a gathering place for general replication requirements needed to
provide interoperability between informational directories.

Stokes, et al Expires February 2001 [Page 1]
Internet-Draft LDAPv3 Replication Requirements August 2000

The key words MUST, MUST "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].

Weiser & Stokes 21 April 2000 [PAGE 1]

INTERNET-DRAFT LDAP

Stokes, et al Expires February 2001 [Page 2]
Internet-Draft LDAPv3 Replication Requirements 21 October 1999 August 2000

Table of Contents

1.Introduction.....................................................3
2. Terminology.....................................................3
3. Objective.......................................................5
4. Applicability Statement.........................................5
5. Replication Model..............................................10
6. Replication Protocol...........................................12
7. Schema.........................................................13
8.

1 Introduction.......................................................4
2 Terminology........................................................4
3 The Possible Models................................................7
4 Requirements.......................................................8
4.1 General.........................................................8
4.2 Model...........................................................8
4.3 Protocol.......................................................10
4.4 Schema.........................................................10
4.5 Single Master..................................................11
4.6 Multi-Master...................................................11
4.7 Administration and Management Considerations...................13
9. Acknowledgement................................................14
10. References....................................................15
11. Author's Address..............................................15

Weiser & Stokes 21 April 2000 Management..................................12
4.8 Security.......................................................12
5 Security Considerations...........................................13
6 Acknowledgements..................................................13
7 References........................................................13
A.APPENDIX A - Usage Scenarios......................................14
A.1.Extranet Example...............................................14
A.2.Consolidation Example..........................................14
A.3.Replication Heterogeneous Deployment Example...................14
A.4.Shared Name Space Example......................................15
A.5.Supplier Initiated Replication.................................15
A.6.Consumer Initiated Replication.................................15
A.7.Prioritized attribute replication..............................16
A.8.Bandwidth issues...............................................16
A.9.Interoperable Administration and Management....................16
A.10.Enterprise Directory Replication Mesh.........................17
A.11.Failure of the Master in a Master-Slave Replicated Directory..17
A.12.Failure of a Directory Holding Critical Service Information...18
B.APPENDIX B - Rationale............................................18
B.1.Meta-Data Implications.........................................18
B.2.Order of Transfer for Replicating Data.........................18
B.3.Schema Mismatches and Replication..............................19
B.4.Detecting and Repairing Inconsistencies Among Replicas.........20
B.5.Some Test Cases for Conflict Resolution in Multi-Master
Replication........................................................21
B.6.Data Privacy During Replication................................24
B.7.Failover in Single-Master Systems..............................25
B.8.Including Operational Attributes in Atomic Operations..........26
Authors' Addresses...................................................26
Full Copyright Statement.............................................27

Stokes, et al Expires February 2001 [Page 2]

INTERNET-DRAFT LDAP 3]
Internet-Draft LDAPv3 Replication Requirements 21 October 1999

1. August 2000

1 Introduction

The ability to distribute directory information throughout the network
provides a two fold two-fold benefit to the network: (1) increasing the
reliability of the directory through fault tolerance, and (2) brings
the directory content closer to the clients using the data. LDAPÆs LDAP's
acceptance as an access protocol for directory information is driving
the need to distribute LDAP directory content among servers within
enterprise and Internet. Currently LDAP does not define a replication
mechanism and only generally mentions LDAP shadow servers (see [RFC2251] and [Changelog])
[RFC2251]) in passing. The
requirements A standard mechanism for replication are that
operates in a multi-vendor directory environment is critical to the
successful deployment and acceptance of LDAP in the market place.

2. Terminology

For

This document sets out the requirements for replication between
multiple LDAP servers. While RFC 2251 and RFC 2252 [RFC2252] set forth
the standards for communication between LDAP clients and servers there
are additional requirements for server-to-server communication. Some
of these are covered here.

This document first introduces the terminology to be used, then
presents the different replication models being considered. The actual
requirements follow, along with security considerations. The reasoning
that leads to the requirements is presented in the purposes Appendix. This was
done to provide a clean separation of this document, the requirements from their
justification.

2 Terminology

The following terminology
definitions terms are used: used in this document:

Area of replication - A whole or portion of a directory tree(DIT)
making Directory Information
Tree (DIT) that makes up a distinct unit of data to be replicated. This
may also be known as "unit of replication".

Atomic operation - The ability to treat and contain several updates
or attribute A set of changes as a single operation for replication purposes to guarantee that directory data which the several updates or attribute changes are
propagated to a replica LDAP
standards guarantee will be treated as a single unit.

Authoritative Master Replica unit; all changes will be made
or all the changes will fail.

Atomicity Information - The Primary updateable replica Information about atomic operations passed as
part of the
replicated information. replication.

Conflict resolution - Deterministic procedures within A situation that arises when changes are made to the same
directory data on different directory servers before replication
protocols, utilized can

Stokes, et al Expires February 2001 [Page 4]
Internet-Draft LDAPv3 Replication Requirements August 2000

synchronize the data on the servers. When the servers do synchronize,
they have inconsistent data - a conflict.

Conflict resolution - Deterministic procedures used to resolve change
information conflicts that may arise due during replication.

Critical OID - Attributes or object classes defined in the replication
agreement as being critical to conflicting changes the operation of the system. Changes
affecting critical OIDs cause immediate initiation of a directory entry. replica cycle.
An example of a critical OID might be a password or certificate.

Fractional replication - The This is the capability to replicate a subset
(as opposed to the full set) of attributes of any given entry. those entries being
replicated.

Incremental Update - The process of updating a replica, or copy, of
a naming context, by updating A replica update that contains only those fields
attributes or objects which that have changed.

Master Replica - In a Master-Slave Replication system, the Master
Replica is the only updateable replica in the replica ring. It is the
supplier in all replication sessions.

Master Slave, or Single Master Replication - Replication A replication model that
assumes only one server, the master, allows write access to the
replicated data. Note that Master-Slave replication can be considered a
proper subset of multi-master replication.

Weiser & Stokes 21 April 2000 [Page 3]

INTERNET-DRAFT LDAP Replication Requirements 21 October 1999

Meta-Data - Data collected by the replication system that describes the
status/state of replication.

Multi-Master Replication - A replication model where entries can be
written and updated on any of several updateable replica copies without
requiring communication with other updateable replicas before the write
or update is performed.

Naming Context - Suffix of a Sub-tree. A sub-tree of entries held in a single
server [X.500].

One-way Replication - The process of synchronization in a single
direction where the authoritative source information is provided to a
replica.

Partial Replication - The capability to replicate some subset of
entries in a naming context. Partial Replication is Fractional Replication,
Sparse Replication, or both.

Stokes, et al Expires February 2001 [Page 5]
Internet-Draft LDAPv3 Replication Requirements August 2000

Propagation behavior - The general behavior of the actual
synchronization process between a consumer and a provider of
replication information.

Read-only Replica - A read-only copy of a replicated directory. A
read-only read-
only replica is assumed to be a slave replica of master slave
or in the single master
replication definition.

Replica - A single instance of a whole or portion of the Directory
tree (DIT) DIT as defined
by the area of replication.

Replica Ring - A set of servers, which hold in common the same DIT
information as, defined by ôArea "Area of replicationö. replication". These servers may be
managed under a single replication agreement that handles all members
of the set of servers as a group.

Replica (or Replication) Cycle - When A replica cycle is the communication
of a change or groups of changes that need to be propagated to the other member
members of a replica ring. The process of contacting a replica member would be
is considered the beginning of a replication cycle; cycle while the
termination of communications with a replica is the end of the cycle whether its cycle.
Termination can occur either due to an error or successful exchange of
update records.

Replication - The process of copying portions of naming context
information and content between multiple LDAP servers, such that
certain predefined portions of the information are available from
different servers. Replication can occur between either homogeneous
implementations across heterogeneous platforms (operating systems)
or heterogeneous implementations supporting identical The replication
across heterogeneous platforms (operating systems).

Sparse Replica process is neither implementation
nor platform specific.

Replication Agreement - A incomplete copy collection of information describing the
parameters of a sub-tree which maybe
inclusive with updateable, or Read-only. See Partial replication and

Weiser & Stokes 21 April 2000 [Page 4]

INTERNET-DRAFT LDAP Replication Requirements 21 October 1999

Fractional replication.

Topology between two or more servers in a replica
ring.

Replication Initiation Conflict - Refers In multi-master replication, a
Replication Initiation Conflict is a situation where two masters want
to update the same replica at the same time.

Replication Session - A session set up between two servers in a replica
ring to pass update information as part of a Replica Cycle.

Slave (or Read-Only) Replica - A replica that cannot be directly
updated. Changes may only be made via replication from a master
replica.

Sparse Replication - The capability to replicate some subset of entries
(other than a complete naming context) of a naming context.

Stokes, et al Expires February 2001 [Page 6]
Internet-Draft LDAPv3 Replication Requirements August 2000

Topology - The shape of the directed graph describing the relationships
between replicas, as in the replicated directory
topology. replicas.

Two-way Replication - The process of synchronization where change
information may flow flows bi-directionally between two replica. replicas.

Update Propagation - Protocol-based process by which directory replicas
are reconciled.

Updateable Replica - A Non-authoritative read-writeable copy of the replicated
information. Such that during conflict resolution a
authoritative master takes precedents in resolving conflicts.

3. Objective

3 The Possible Models

The major objective is to provide an interoperable LDAP V3 directory
synchronization protocol which that is simple, highly efficient and flexible
enough to support both multi-master and master-slave replication operations to
operations. Such a protocol would meet the needs of both the internet Internet
and enterprise environments.

4. Applicability Statement

Generally

Generally, replication can be characterized by looking at data
consistency models across existing technologies. This may provide provides insight
to LDAP v3 replication requirements. The following is a brief
examination of the following data consistency models.

Model 1: Tight Transactional Consistency -- Includes environments where Environments that exhibit all
replicas must always contain exactly
four of the same directory content. Two
phase commit transaction models may be used to preserve transaction
consistency. ACID properties (Atomicity, Concurrency, Independence,
Durability) [ACID].

Model 2: Eventual Consistency or Transient Consistency -- Includes
X.500 Directories, Bayou [XEROX], and NDS (Novell Directory
Services) names service Environments
where definite knowledge of the global replica topology is provided
through predetermined replication agreements. Such that Examples include X.500
Directories, Bayou [XEROX], and NDS (Novell Directory Services) [NDS].
In this model, every update propagates to every replica that it can
reach via a path of stepwise eventual connectivity.
Transaction consistency is preserved for transactions directed at
the master server in X.500 implementations. NDS additionally
provides deterministic consistency over time to all replicas due to
its inherent replication policies.

Weiser & Stokes 21 April 2000 [Page 5]

INTERNET-DRAFT LDAP Replication Requirements 21 October 1999

Model 3: Limited Effort Eventual Consistency -- Includes Xerox
Clearinghouse [XEROX] Environments that provides
provide a statistical probability of convergence with global knowledge
of replica topology. Similar An example is the Xerox Clearinghouse [XEROX].
This model is similar to "Eventual Consistency", except where replicas
may purge updates
therefore dropping updates. Purging drops propagation changes when some replica
time boundary is exceeded, thus leaving some changes replicated to only
a portion of the replica topology. Transactional consistency is not
preserved, though some weaker constraints on consistency are available.

Model 4: Loosest Consistency -- Includes opportunistic or simple
cache Environments where information is
provided from the an opportunistic or simple cache until stale.

Stokes, et al Expires February 2001 [Page 7]
Internet-Draft LDAPv3 Replication Requirements August 2000

Model 5: Ad hoc -- A copy of a date data store where no follow up checks are
made for the accuracy/freshness of the data.

Consistency models 2, 2 and 3 involve the use of prearranged replication
agreements or "Predefined Replication Agreements" between cooperating servers. The added complexity of Model 1's use of 2-
phase 2-phase
commit adds additional overhead required for Model 1 is significant enough that should model 1 will not
be considered at this time. Models 4 and 5 involve unregistered
replicas which that "pull" updates from another directory server without that
server's knowledge. These models can be considered to violate a
directory's security policies. Therefore models 1, 4, and 5 are declared to be
out of scope of this working group.

So through further

Further review of these consistency models 2 and 3 reveal two example application areas can then
that LDAP replication must be derived with even further
characterizations of the data types usages.

Eventual Consistency or Transient Consistency (Model 2) - This model
provides able to handle. These are policy
configuration through security management
parameters; the data is more dynamic parameters (model 2) and utilizes dynamic address
information.

Limited Effort Eventual Consistency (Model 3) - This model matches a
white-pages environment which contains environments that contain fairly static data and address information. This model mainly replicates message
attributes.

Therefore it is believed an LDAP
information (model 3). Therefore, replication should be flexible
enough to cover requirements are
presented for models 2 and 3.

4 Requirements

4.1 General

G1. LDAP Replication MUST support models 2 (Eventual Consistency) and
3 (Limited Effort Eventual Consistency) above.

G2. LDAP Replication SHOULD NOT preclude support for model 1
(Transactional Consistency) in the above range of capabilities. future.

G3. The generalized use act of LDUP replication environment is to provide for SHOULD have minimal impact on both the distribution
of LDAP directory information in order to improve accessibility
system and
consistency network performance.

G4. An LDAP Replication Standard SHOULD NOT limit the transaction rate
of a replication session.

G5. The replication standard SHOULD NOT limit the information held size of a replica.

G6. Any meta-data collected by the directory.

4.1 Replication Scenarios

Weiser & Stokes 21 April 2000 [Page 6]

INTERNET-DRAFT LDAP replication mechanism MUST NOT
grow without bound.

G7. All policy and state data pertaining to replication MUST be
accessible via LDAP.

4.2 Model

Stokes, et al Expires February 2001 [Page 8]
Internet-Draft LDAPv3 Replication Requirements 21 October 1999 August 2000

M1. The model MUST support the following directory deployment examples are intended to
substantiate and validate our replication requirements. It is
assumed in all cases that directory implementations from different
vendors are involved.

4.1.1 Extranet Example

A company has triggers for initiation of a trading partner to whom
replica cycle:

a) A configurable set of scheduled times
b) Periodically, with a configurable period between replica cycles
c) A configurable maximum amount of time between replica cycles
d) A configurable number of accumulated changes
e) Change in the value of a critical OID
f) As the result of an automatic rescheduling after a replication
initiation conflict
g) Administrative request for replication

With the exception of administrative request, the specific trigger(s)
and related parameters in effect for a given server MUST be identified
in a well known place, e.g. the Replication Agreement(s).

M2. The replication model MUST support both master-slave and multi-
master relationships.

M3. All replicated information between the master database and its
replica databases MUST be identical including all non-user modify
operational attributes such as time stamps. Note this does not imply
that the entire database is identical from replica to replica, but that
the subset of data, chosen to replicate is identical from replica to
replica. Some operational attributes may be dynamically evaluated;
these attributes will not necessarily appear to be identical.

M4. LDAP replication MUST encompass schema objects, attributes, access
control, and name space information.

M5. LDAP replication MUST NOT require all copies of the replicated
information to be complete copies of the replicated object. The model
MUST support Fractional, Partial, and Sparse Replicas.

M6. Sub-tree Replication MUST be defined to allow for greater
flexibility in replication topologies of the DIT as defined by partial
replication.

M7. The determination of which OIDs are critical MUST be configurable
in the replication agreement.

M8. Replication activities MUST occur within the context of a
predefined replication agreement that addresses proper knowledge of
access requirements and credentials between the synchronizing
directories.

M9. The replication agreements SHOULD accommodate multiple servers
receiving the same replica under a single predefined agreement.
Stokes, et al Expires February 2001 [Page 9]
Internet-Draft LDAPv3 Replication Requirements August 2000

M10. LDAP replication MUST provide scalability to both enterprise and
Internet environments, e.g. an LDAP server must be able to provide
replication services to replicas within an enterprise as well as across
the Internet.

M11. While different directory implementations can support
different/extended schema, schema mismatches between two replicating
servers MUST be handled. One way of handling such mismatches might be
to raise an error condition.

M12. The LDAP replication model MUST allow for full update to
facilitate replica initialization and reset loading utilizing a
standardized format such as LDIF [RFC2849] format.

4.3 Protocol

P1. The replication protocol MUST provide for recovery and
rescheduling of a replication session due to replication initiation
conflicts (e.g. consumer busy replicating with other servers) and or
loss of connection (e.g. supplier cannot reach a replica).

P2. The replication protocol MUST allow a restart at the last
acknowledged update prior to interruption rather than re-sending
updates it had already sent to a consuming replica.

P3. The LDAP replication protocol MUST allow for full update to
facilitate replica initialization and reset loading utilizing a
standardized format such as LDIF [RFC2849] format.

P4. Incremental replication MUST be allowed.

P5. The replication protocol MUST allow either a master or slave
replica to initiate the replication process.

P6. The protocol MUST support propagation of atomicity information.

P7. The protocol SHOULD NOT preclude future support of Transactional
Consistency (model 1).

P8. The protocol MUST support a mechanism to report schema mismatches
between replicas discovered during a replication session.

4.4 Schema

SC1. A standard way to determine what replicas are held on a server
MUST be defined.
Stokes, et al Expires February 2001 [Page 10]
Internet-Draft LDAPv3 Replication Requirements August 2000

SC2. A standard schema for representing replication agreements MUST be
defined.

SC3. The semantics associated with modifying the attributes of
replication agreements MUST be defined.

SC4. A standard method for determining the location of replication
agreements MUST be defined.

SC5. A standard schema for publishing state information about a given
replica MUST be defined.

SC6. A standard method for determining the location of replica state
information MUST be defined.

SC7. It MUST be possible for authorized administrators, regardless of
their network location, to access replication agreements in the DIT.

SC8. Replication agreements of all servers containing replicated
information MUST be accessible via LDAP.

SC9. All objects MUST be uniquely identifiable throughout the object
lifetime.

4.5 Single Master

SM1. A Single Master system SHOULD provide a fast method of promoting
a slave replica to become the master replica.

SM2. The master replica in a Single Master system SHOULD send all
changes to read-only replicas in the order in which they were applied
on the master.

4.6 Multi-Master

MM1. Replica synchronization SHOULD be handled in such a manner as to
not saturate the network with repetitive entry replication from
supplier replicas.

MM2. The initiator MUST be allowed to determine whether it will become
a consumer or supplier during the synchronization startup process.

MM3. During a replication session, it MUST be possible for the two
servers to switch between the consumer and supplier roles.

Stokes, et al Expires February 2001 [Page 11]
Internet-Draft LDAPv3 Replication Requirements August 2000

MM4. When multiple master replicas want to begin a replication session
with the same replica at the same time, the model MUST have a
deterministic mechanism for resolving the resulting replication
initiation conflict with no operator intervention.

MM5. Multi-master replication MUST NOT lose information during
replication. If conflict resolution would result in the loss of
directory information, the replication process MUST store that
information, notify the administrator of the nature of the conflict and
the information that was lost, and provide a mechanism for possible
override by the administrator.

MM6. Multi-master replication MUST support convergence of the values
of attributes and objects. Convergence may result in an event as
described in MM5.

4.7 Administration and Management

AM1. Replication agreements MUST allow the initiation of a replica
cycle to be administratively postponed to a more convenient period.

AM2. Each copy of a replica MUST maintain audit history information of
which servers it has replicated with and which servers have replicated
with it.

AM3. Access to replication agreements, topologies, and policies
attributes MUST be provided through LDAP access.

AM4. The capability to check the differences between two replicas for
the same information SHOULD be provided.

AM5. A mechanism to fix differences between replicas without triggering
new replica cycles SHOULD be provided.

AM6. The deletion of sensitive data MUST be handled in an orderly
manner so that at no time will that data be available without proper
access control. That is, access control information (ACI) associated
with sensitive data must be deleted after or simultaneously with the
delete of the sensitive data. Likewise, when adding sensitive data,
ACI MUST be added first or simultaneously with the addition of that
data.

4.8 Security

S1. During initiation of a replication session, authentication and
verification of authorization of both the replica and the source
directory MUST be allowed before any data is transferred.

Stokes, et al Expires February 2001 [Page 12]
Internet-Draft LDAPv3 Replication Requirements August 2000

S2. The transport for LDAP synchronization MUST permit assurance of
the integrity and privacy of all data transferred.

S3. To promote interoperability, there MUST be a mandatory-to-
implement data privacy mechanism.

S4. The transport for administrative access MUST permit assurance of
the integrity and privacy of all data transferred.

5 Security Considerations

This document includes security requirements (listed in section 4.8
above) for the replication model and protocol.

6 Acknowledgements

This document is based on input from IETF members interested in LDUP
Replication.

7 References

[ACID] T. Haerder, A. Reuter, "Principles of Transaction-Oriented
Database Recovery", Computing Surveys, Vol. 15, No. 4 (December 1983),
pp. 287-317.

[NDS] Novell, "NDS Technical Overview", 104-000223-001,
http://developer.novell.com/ndk/doc/docui/index.htm#../ndslib/dsov_enu/
data/h6tvg4z7.htm,
September, 2000.

[RFC2119] S. Bradner, "Key Words for Use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.

[RFC2251] M. Wahl, T. Howes, S. Kille "Lightweight Directory Access
Protocol", RFC 2251, December 1997.

[RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight
Directory Access Protocol (v3): Attribute Syntax Definitions", RFC
2252, December 1997.

[RFC2849] Gordon Good, "The LDAP Data Interchange Format (LDIF)", RFC
2849, June 2000.

[X.501] ITU-T Recommendation X.501 (1993), | ISO/IEC 9594-2: 1993,
Information Technology - Open Systems Interconnection - The Directory:
Models.

Stokes, et al Expires February 2001 [Page 13]
Internet-Draft LDAPv3 Replication Requirements August 2000

[XEROX] Hauser, C. "Managing update conflicts in Bayou, a weakly
connected replicated storage system". Palo Alto, CA: Xerox PARC,
Computer Science Laboratory; 1995 August; CSL-95-4. [CSL-95-04]

A. APPENDIX A - Usage Scenarios

The following directory deployment examples are intended to
substantiate and validate our replication requirements. It is assumed
in all cases that directory implementations from different vendors are
involved. This material is intended as background; no requirements are
presented in this Appendix.

A.1. Extranet Example

A company has a trading partner to whom it wishes to provide directory
information. This information may be as simple as a corporate
telephone directory, or as complex as an extranet workflow application.
For performance reasons the company may wish to have a replica of its
directory within the Partner Company, rather than simply exposed beyond
its firewall.

The requirements that follow from this scenario are:
. One-way replication, single mastered.
. Authentication of clients.
. Common access control and access control identification.
. Secure transmission of updates.
. Selective attribute replication (Fractional Replication), so that
only partial entries can be replicated.

A.2. Consolidation Example

Company A acquires company B. In the transition period, whilst the
organizations are merged, both directory services must coexist.
Company A may wish to attach company B's directory to its own.

The requirements that follow from this scenario are:
. Multi-Master replication.
. Common access control model. Access control model identification.
. Secure transmission of updates.
. Replication between DITs with potentially differing schema.

A.3. Replication Heterogeneous Deployment Example

Stokes, et al Expires February 2001 [Page 14]
Internet-Draft LDAPv3 Replication Requirements August 2000

An organization may deliberately deploy multiple directory services
within their enterprise to employ the differing benefits of each
service. In this case multi-master replication will be required to
ensure that the multiple updateable replicas of the DIT are
synchronized. Some vendors may provide directory clients, which are
tied to their own directory service.

The requirements that follow from this scenario are:
. Multi-Master replication
. Common access control model and Access control model identification.
. Secure transmission of updates.
. Replication among DITs with potentially differing schemas.

A.4. Shared Name Space Example

Two organizations may choose to cooperate on some venture and need a
shared name space to manage their operation. Both organizations will
require administrative rights over the shared name space.

The requirements that follow from this scenario are:
. Multi-Master replication.
. Common access control model and Access control model identification.
. Secure transmission of updates.

A.5. Supplier Initiated Replication

This is a single master environment that maintains a number of replicas
of the DIT by pushing changes based on a defined schedule.

The requirements that follow from this scenario are:
. Single-master environment.
. Supplier-initiated replication.
. Secure transmission of updates.

A.6. Consumer Initiated Replication

Again a single mastered replication topology, but the replica initiates
the replication exchange rather than the master. An example of this is
a replica that resides on a laptop computer that may run disconnected
for a period of time.

The requirements that follow from this scenario are:
. Single-master environment.

Stokes, et al Expires February 2001 [Page 15]
Internet-Draft LDAPv3 Replication Requirements August 2000

. Consumer initiated replication.
. Open scheduling (anytime).

A.7. Prioritized attribute replication

The password attribute can provide an example of the requirement for
prioritized attribute replication. A user is working in Utah and the
administrator resides in California. The user has forgotten his
password. So the user calls or emails the administrator to request a
new password. The administrator provides the updated password (a
change).

Under normal conditions, the directory replicates to a number of
different locations overnight. But corporate security policy states
that passwords are critical and the new value must be available
immediately (e.g. shortly) after any change. Replication needs to
occur immediately for critical attributes/objects.

The requirements that follow from this scenario are:
. Incremental replication of changes.
. Immediate replication on change of certain attributes.
. Replicate based on time/attribute semantics.

A.8. Bandwidth issues

The replication of Server (A) R/W replica (a) in Kathmandu is handled
via a dial up phone link to Paris where server (B) R/W replica of (a)
resides. Server (C) R/W replica of (a) is connected by a T1 connection
to server (B). Each connection has a different performance
characteristic.

The requirements that follow from this scenario are:
. Minimize repetitive updates when replicating from multiple
replication paths.
. Incremental replication of changes.
. Provide replication cycles to delay and/or retry when connections
cannot be reached.
. Allowances for consumer initiated or supplier initiated replication.

A.9. Interoperable Administration and Management

The administrator with administrative authority of the corporate
directory which is replicated by numerous geographically dispersed LDAP
servers from different vendors notices that the replication process is
Stokes, et al Expires February 2001 [Page 16]
Internet-Draft LDAPv3 Replication Requirements August 2000

not completing correctly as the change log is continuing to grow and/or
error message informs him. The administrator uses his $19.95 RepCo LDAP
directory replication diagnostics tools to look at Root DSE replica
knowledge on server 17 and determines that server 42 made by LDAP'RUS
Inc. is not replicating properly due to an Object conflict. Using his
Repco Remote repair tools he connects to server 42 and resolves the
conflict on the remote server.

The requirements that follow from this scenario are:
. Provides replication audit history.
. Provisions for managing conflict resolution.
. Provide LDAP access to predetermined agreements, topology and policy
attributes.
. Provide operations for comparing replica's content for validity.
. Provide LDAP access to status and audit information.

A.10. Enterprise Directory Replication Mesh

A Corporation builds a mesh of directory servers within the enterprise
utilizing LDAP servers from various vendors. Five servers are holding
the same area of replication. The predetermined replication
agreement(s) for the enterprise mesh are under a single management, and
the security domain allows a single predetermined replication agreement
to manage the 5 servers replication.

The requirements that follow from this scenario are:
. Predefined replication agreements that manage more than a single area
of replication that is held on numerous servers.
. Common support of replication management knowledge across vendor
implementation.
. Rescheduling and continuation of a replication cycle when one server
in a replica ring is busy and/or unavailable.

A.11. Failure of the Master in a Master-Slave Replicated Directory

A company has a corporate directory that is used by the corporate email
system. The directory is held on a mesh of servers from several
vendors. A corporate relocation results in the closing of the location
where the master copy of the directory is located. Employee
information (such as mailbox locations and employee certificate
information) must be kept up to date or mail cannot be delivered.

The requirements that follow from this scenario are:
. An existing slave replica must be "promote-able" to become the new
master.
Stokes, et al Expires February 2001 [Page 17]
Internet-Draft LDAPv3 Replication Requirements August 2000

. The "promotion" must be done without significant downtime, since
updates to the directory will continue.

A.12. Failure of a Directory Holding Critical Service Information

An ISP uses a policy management system that uses a directory as the
policy data repository. The directory is replicated in several
different sites on different vendors' products to avoid single points
of failure. It is imperative that the directory be available and be
updateable even if one site is disconnected from the network. Changes
to the data must be traceable, and it must be possible to determine how
changes made from different sites interacted.

The requirements that follow from this scenario are:
. Multi-master replication
. Ability to reschedule replication sessions
. Support for manual review and override of replication conflict
resolution

B. APPENDIX B - Rationale

This Appendix gives some of the background behind the requirements. It
is included to help the protocol designers understand the thinking
behind some of the requirements and to present some of the issues that
should be considered during design. With the exception of section B.8,
which contains a suggested requirement for the update to RFC 2251, this
Appendix does not state any formal requirements.

B.1. Meta-Data Implications

Requirement G4 states that meta-data must not grow without bound. This
implies that meta-data must, at some point, be purged from the system.
This, in turn, raises concerns about stability. Purging meta-data
before all replicas have been updated may lead to incomplete
replication of change information and inconsistencies among replicas.
Therefore, care must be taken setting up the rules for purging meta-
data from the system while still ensuring that meta-data will not grow
forever.

B.2. Order of Transfer for Replicating Data

Situations may arise where it wishes would be beneficial to replicate data
out-of-order (e.g. send data to consumer replicas in a different order
than it was processed at the supplier replica). One such case might
occur if a large bulk load was done on the master server in a single-

Stokes, et al Expires February 2001 [Page 18]
Internet-Draft LDAPv3 Replication Requirements August 2000

master environment and then a single change to a critical OID (a
password change, for example) was then made. Rather than wait for all
the bulk data to be sent to the replicas, the password change might be
moved to the head of the queue and be sent before all the bulk data was
transferred. Other cases where this might be considered are schema
changes or changes to critical policy data stored in the directory.

While there are practical benefits to allowing out-of-order transfer,
there are some negative consequences as well. Once out-of-order
transfers are permitted, all receiving replicas must be prepared to
deal with data and schema conflicts that might arise.

As an example, assume that schema changes are critical and must be
moved to the front of the replication queue. Now assume that a schema
change deletes an attribute for some object class. It is possible that
some of the operations ahead of the schema change in the queue are
operations to delete values of the soon-to-be-deleted attribute so that
the schema change can be done with no problems. If the schema change
moves to provide the head of the queue, the consumer servers might have to
delete an attribute that still has values, and then receive requests to
delete the values of an attribute which is no longer defined.

In the multi-master case, similar situations can arise when
simultaneous changes are made to different replicas. Thus, multi-
master systems must have conflict resolution algorithms in place to
handle such situations. But in the single-master case conflict
resolution is not needed unless the master is allowed to send data out-
of-order. This is the reasoning behind requirement SM2, which
recommends that data always be sent in order in single-master
replication.

Note that even with this restriction, the concept of a critical OID is
still useful in single-master replication. An example of its utility
can be found in section A.7.

B.3. Schema Mismatches and Replication

Multi-vendor environments are the primary area of interest for LDAP
replication standards. Some attention must thus be paid to the issue
of schema mismatches, since they can easily arise when vendors deliver
slightly different base schema with their directory information. products. Even
when both products meet the requirements of the standards [RFC2252],
the vendors may have included additional attributes or object classes
with their products. When two different vendor's products attempt to
replicate, these additions can cause schema mismatches. Another
potential cause of schema mismatches is discussed in section A.3.

There are only a few possible responses when a mismatch is discovered.
Stokes, et al Expires February 2001 [Page 19]
Internet-Draft LDAPv3 Replication Requirements August 2000

. Raise an error condition and ignore the data. This information should always be
allowed and is the basis for requirement P8 and the comment on M11.
. Map/convert the data to the form required by the consuming replica.
A system may choose this course; requirement M11 is intended to allow
this option. The extent of the conversion is up to the
implementation; in the extreme it could support use of the
replication protocol in meta-directories.
. Quietly ignore (do not store on the consumer replica and do not raise
an error condition) any data that does not conform to the schema at
the consumer.

Requirement M11 is intended to exclude the last option.

Normal IETF practice in protocol implementation suggests that one be as simple as
strict in what one sends and be flexible in what one receives. The
parallel in this case is that a
corporate telephone directory, or as complex as supplier should be prepared to receive
an extranet work
flow application. For performance reasons the company error notification for any schema mismatch, but a consumer may wish
choose to
have do a replica of its directory within the Partner Company, rather
than simply exposed beyond its firewall. conversion instead.

The requirements, which follow from other option that can be considered in this scenario, are:

- One-way replication, single mastered.
- Authentication of clients.
- Common access control and access control identification.
- Secure transmission situation is the use of updates.
- Selective attribute
fractional replication. If replication (Fractional Replication), is set up so that only partial entries the common
attributes are replicated, mismatches can be avoided.

One additional consideration here is replication of the schema itself.
M4 requires that it be possible to replicate schema. If a consumer
replica is doing conversion, extreme care should be taken if schema
elements are replicated since some attributes are intended to have
different definitions on different replicas.

For fractional replication, the protocol designers and implementors
should give careful consideration to the way they handle schema
replication. Some options for schema replication include:
. All schema elements are replicated.

4.1.2 Consolidation Example

Company
. Schema elements are replicated only if they are used by attributes
that are being replicated.
. Schema are manually configured on the servers involved in fractional
replication; schema elements are not replicated via the protocol.

B.4. Detecting and Repairing Inconsistencies Among Replicas

Despite the best efforts of designers, implementors, and operators,
inconsistencies will occasionally crop up among replicas in production
directories. Tools will be needed to detect and to correct these
inconsistencies.

Stokes, et al Expires February 2001 [Page 20]
Internet-Draft LDAPv3 Replication Requirements August 2000

A acquires company B. special client may accomplish detection through periodic comparisons
of replicas. This client would typically read two replicas of the same
naming context and compare the answers, possibly by BINDing to each of
the two replicas to be compared and reading them both. In cases where
the transition period, whilst the
organizations are merged, both directory services must coexist.
Company A may wish to attach company B's directory automatically reroutes some requests (e.g. chaining),
mechanisms to its own.

The requirements, which follow from this scenario, are:

- Multi-Master replication.
- Common force access control model. Access control model identification.
- Secure transmission of updates.
- Replication between DITs with potentially differing schema.

4.1.3 Replication Heterogeneous Deployment Example

An organization may deliberately deploy multiple directory services
within their enterprise to employ a particular replica should be supplied.

Alternatively, the differing benefits of each
service. In server could support a special request to handle
this case multi-master situation. A client would invoke an operation at some server. It
would cause that server to extract the contents from some other server
it has a replication will be required agreement with and report the differences back to
ensure that
the multiple updateable replicas of client as the DIT are
synchronized. Some vendors may provide directory clients, which are
tied result

If an inconsistency is found, it needs to their own directory service.

The requirements, which follow from this scenario, are:

- Multi-Master replication

Weiser & Stokes 21 April 2000 [Page 7]

INTERNET-DRAFT LDAP Replication Requirements 21 October 1999

- Common be repaired. To determine
the appropriate repair, the administrator will need access control model and Access control model
identification.
- Secure transmission of updates.
- Replication between DITs with potentially differing schemas.

4.1.4 Shared Name Space Example

Two organizations may choose to cooperate on some venture the
replication history to figure out how the inconsistency occurred and need
what the correct repair should be.

When a
shared name space repair is made, it should be restricted to manage their operation. Both organizations
will the replica that
needs to be fixed; the repair should not cause new replication events
to be started. This may require administrative rights over special tools to change the shared name space.

The requirements, which follow from this scenario, are:

- Multi-Master local data
store without triggering replication.
- Common access control model

Requirements AM2, AM4, and Access control model
identification.
- Secure transmission of updates.

4.1.5 Supplier Initiated AM5 address these needs.

B.5. Some Test Cases for Conflict Resolution in Multi-Master
Replication

A single master environment, which maintains a number of replicas

Use of multi-master replication inevitably leads the DIT by pushing changes, based possibility that
incompatible changes will be made simultaneously on different servers.
In such cases, conflict resolution algorithms must be applied.

As a defined schedule.

The requirements, which follow from guiding principle, conflict resolution should avoid surprising the
user. One way to do this scenario, are:

- Single-master environment.
- Supplier-initiated replication.
- Secure transmission of updates.

4.1.6 Consumer Initiated Replication

Again a single mastered replication topology, but is to adopt the replica
initiates principle that, to the replication exchange rather than extent
possible, conflict resolution should mimic the master. An
example of this is a replica situation that resides on would
happen if there were a laptop computer that
may run disconnected for single server where all the requests were
handled.

While this is a period useful guideline, there are some situations where it is
impossible to implement. Some of time.

The requirements, which follow from these cases are examined in this scenario, are:

- Single-master environment.
- Consumer initiated replication.
- Open scheduling (anytime).

4.1.7 Prioritized attribute
section. In particular, there are some cases where data will be "lost"
in multi-master replication

The password attribute can provide an example of that would not be lost in a single-server
configuration.

In the requirement for
prioritized attribute replication. examples below, assume that there are three replicas, A, B, and
C. All three replicas are updateable. Changes are made to replicas A user is working in Utah
and B before replication allows either replica to see the
administrator resides in California. The user has forgotten his
password. So the user calls or emails change made
on the administrator to request a
new password. The administrator provides other. In discussion of the updated password (a
change). Policy states multi-master cases, we assume that this attribute is critical and must be

Weiser & Stokes 21 April 2000

Stokes, et al Expires February 2001 [Page 8]

INTERNET-DRAFT LDAP 21]
Internet-Draft LDAPv3 Replication Requirements 21 October 1999

available to the user for login immediately (e.g. shortly) after August 2000

the
administrator changed it. Replication needs change to occur immediately A takes precedence using whatever rules are in force for
critical attributes/objects.

The requirements, which follow from this scenario, are:

- Incremental replication
conflict resolution.

B.5.1. Create-Create

A user creates a new instance of changes.
- Automatic replication an object with distinguished name DN
to A. At the same time, a different user adds an object with the same
distinguished name on change B.

In the single-server case, one of certain attributes.
- Replicate based the create operations would have
occurred before the other, and the second request would have failed.

In the multi-master case, each create was successful on time/attribute semantics.

4.1.8 Bandwidth issues its originating
server. The replication of Server (A) R/W replica (a) in Katmandu problem is handled
via not detected until replication takes place.
When a dial up phone link replication request to Paris where server (B) R/W replica create a DN that already exists arrives
at one of
(a) resides. Server (C) R/W replica of(a) the servers, conflict resolution is connected by a T1
connection to server (B). Each connection invoked. (Note that the
two requests can be distinguished even though they have the same DN
because every object has a different
performance characteristic.

The requirements, which follow some sort of unique identifier per requirement
SC9.)

As noted above, in these discussions we assume that the change from this scenario, are:

- Minimize repetitive updates when replicating
replica A has priority based on the conflict resolution algorithm.
Whichever change arrives first, requirement MM6 says that the values
from multiple
replication paths.
- Incremental replication of changes.
- Provide replication cycles to delay and/or retry when connections
can not replica A must be those in place on all replicas at the end of the
replication cycle. Requirement MM5 states that the system cannot
quietly ignore the values from replica B.

The values from replica B might be reached.
- Allowances for consumer initiated logged with some notice to the
administrators, or supplier initiated
replication.

4.1.9 Interoperable Administration and Management

The administrator they might be added to the DIT with administrative authority of a machine
generated DN (again with notice to the corporate
directory which is replicated by numerous geographically dispersed
LDAP administrators). If they are
stored with a machine generated DN, the same DN must be used on all
servers from different vendors notices in the replica ring (otherwise requirement M3 would be
violated). Note that in the replication
process is not completing correctly as case where the change log object in question is continuing a
container object, storage with a machine generated DN provides a place
where descendent objects may be stored if any descendents were
generated before the replication cycle was completed.

In any case, some mechanism must be provided to grow and/or error message informs him. The allow the administrator uses his
$19.95 RepCo LDAP directory replication diagnostics tools
to look at
Root DSE replica knowledge on server 17 reverse the conflict resolution algorithm and determines that server
42 made by LDAPÆRUS Inc. force the values
originally created on B into place on all replicas if desired.

B.5.2. Rename-Rename

On replica A, an object with distinguished name DN1 is not replicating properly due renamed to DN.
At the same time on replica B, an
Object conflict. Using his Repco Remote repair tools he connects object with distinguished name DN2 is
renamed to
server 42 DN.

Stokes, et al Expires February 2001 [Page 22]
Internet-Draft LDAPv3 Replication Requirements August 2000

In the single-server case, one rename operation would occur before the
other and resolves the conflict on second would fail since the remote target name already exists.

In the multi-master case, each rename was successful on its originating
server.

The requirements, which follow from this scenario, are:

- Provides replication audit history.
- Provisions for managing Assuming that the change on A has priority in the conflict resolution.
- Provide LDAP access to predetermined agreements, topology
resolution sense, DN will be left with the values from DN1 in all
replicas and
policy attributes.
- Provide operations for comparing replicaÆs content for validity.
- Provide LDAP access DN1 will no longer exist in any replica. The question is
what happens to status DN2 and audit information.

Weiser & Stokes 21 April 2000 [Page 9]

INTERNET-DRAFT LDAP Replication Requirements 21 October 1999

4.1.10 Enterprise Directory Replication Mesh

A Corporation builds a mesh its original values.

Requirement MM5 states that these values must be stored somewhere.
They might be logged, they might be left in the DIT as the values of directory servers within
DN2, or they might be left in the
enterprise utilizing LDAP servers from various vendors. Five servers
are holding DIT as the same area values of replication. The predetermined
replication agreement(s) for some machine
generated DN. Leaving them as the enterprise mesh are under a single
management, and values of DN2 is attractive since it
is the security domain allows same as the single-server case, but if a single predetermined
replication agreement new DN2 has already
been created before the replica cycle finishes, there are some very
complex cases to manage resolve. Any of the 5 servers replication.

The requirements, which follow from solutions described in this scenario, are:

- Predefined replication agreements that manage more than a single
area of replication that is held
paragraph would be consistent with requirement MM5.

B.5.3. Locking Based on numerous servers.
- Common support Atomicity of replication management knowledge across vendor
implementation.
- Rescheduling ModifyRequest

There is an object with distinguished name DN which contains attributes
X, Y, and continuation Z. The value of a replication cycle when one
server in a X is 1. On replica ring A, a ModifyRequest is busy and/or unavailable.

5. Replication Model

5.1 LDAP Replication MUST be allowed
processed which includes modifications to span different vendors
directory services in order change that value of X from 1
to provide interoperability.

5.2 All replicas MUST eventually be updated with 0 and to set the changed
information, if specified by value of Y to "USER1". At the replication policy.

5.3 Replication schedules MUST be configurable same time, replica B
process a ModifyRequest which includes modifications to allow for
periodic replication, with change the replication period determined by
administrator
value of X from 1 to 0 and to set the replicated system.

5.4 Replication Model MUST enable replication cycle value of Y to be initiated
on change or based on "USER2" and the number
value of pending changes.

5.5 Z to 42. The replication model MUST allow for administrative
initiation application in this case is using X as a lock
and is depending on the atomic nature of replication cycle ModifyRequests to provide
mutual exclusion for any replica that may lock access.

In the single-server case, the two operations would have
just come back online or was unavailable during previous
replication cycles.

5.6 occurred
sequentially. Since a ModifyRequest is atomic, the entire first
operation would succeed. The replication model MUST support both master-slave and
authoritative multi-updateable replica relationships.

5.7 All replicated information between second ModifyRequest would fail, since
the master database and its
replica databases MUST value of X would be identical including all non-user
modify operational attributes such as time stamps. Note this
does not imply that 0 when it was attempted, and the entire database is identical modification
changing X from
replica 1 to replica, but that 0 would thus fail. The atomicity rule would cause
all other modifications in the subset of data, chosen to
replicate is identical from replica to replica. Some
operational attributes may be dynamically evaluated; these
attributes will not necessarily appear ModifyRequest to be identical.

Weiser & Stokes 21 April 2000 [Page 10]

INTERNET-DRAFT LDAP Replication Requirements 21 October 1999

5.8 fail as well.

In distributed multi-vendor environment, LDAP replication MUST
NOT require all copies the multi-master case, it is inevitable that at least some of the replicated information
changes will be
complete copies reversed despite the use of the replicated object.

5.9 LDAP replication MUST encompass common schema objects and
attributes, access control, and name space information.

5.10 Sub-tree Replication MUST lock. Assuming the
changes from A have priority per the conflict resolution algorithm, the
value of X should be defined to allow for greater
flexibility in replication topologies 0 and the value of Y should be "USER1" The
interesting question is the DIT as defined by value of Z at the area end of the replication called partial replication.

5.11 Replication of critical values MUST
cycle. If it is 42, the atomicity constraint on the change from B has
been violated. But for it to revert to its previous value, grouping
information must be synchronized retained and have
priority over non-critical values. An example of a critical
value might it is not clear when that information
can be safely discarded. Thus, requirement G6 may be violated.

Stokes, et al Expires February 2001 [Page 23]
Internet-Draft LDAPv3 Replication Requirements August 2000

B.5.4. General Principles

With multi-master replication there are a password number of cases where a user
or certificate value.

5.12 Replication activities MUST occur within the context application will complete a sequence of operations with a
predefined replication agreement that addresses proper
knowledge server but
those actions are later "undone" because someone else completed a
conflicting set of access requirements and credentials between the
synchronizing directories. Currently X.525 DISP [X.525]
discusses operations at another server.

To some extent, this as can happen in any multi-user system. If a shadowing agreement including such
information as unit user
changes the value of replication, update mode, an attribute and access
point defining many of later reads it back, intervening
operations by another user may have changed the policies between value. In the multi-
master and a
replica.

5.13 The acceptance and usage of case, the Internet requires that LDAP
replication be available across disparate vendor directory
services.

5.14 LDAP replication MUST provide scalability to both enterprise
and Internet environments, e.g. an LDAP server may provide
replication services problem is worsened, since techniques used to replicas within an enterprise as well resolve
the problem in the single-server case won't work as across shown in the Internet.

5.15
examples above.

The replication model MUST define deterministic policy such
that replication cycle startup time conflicts between two or
more competing master replicas may be resolved
programmatically. An example might be automatic submission and
rescheduling by major question here is one of the masters. intended use. In such a case, these
replication "conflicts" MUST be resolved by the replication
policy.

5.16 Any replication capable LDAP server MUST allow standards
work, it has long been said that replication provides "loose
consistency" among replicas. At several IETF meetings and on the
mailing list, usage examples from finance where locking is required
have been declared poor uses for LDAP. Requirement G1 is consistent
with this history. But if loose consistency is the 2 replicating servers agree goal, the locking
example above is an inappropriate use of LDAP, at least in a replicated
environment.

B.5.5. Avoiding the Problem

The examples above discuss some of the most difficult problems that can
arise in multi-master replication. While they can replicate. This
may be accomplished through administrative agreements assuming
compatible access control model dealt with,
dealing with them is difficult and common schema can lead to situations that are provided.

5.17 The replication model MUST be able
quite confusing to handle convergence and
resurrection of attributes and objects. This is a consequence
of delete the application and move with respect to users.

The common characteristics of the replication process.

Weiser & Stokes 21 April 2000 [Page 11]

INTERNET-DRAFT LDAP Replication Requirements 21 October 1999

5.18 It is not realistic examples are:

. Several directory users/applications are changing the same data
. They are changing the data at the same time
. They are using different directory servers to assume that all vendors have cooperating
schemas, but make these changes
. They are changing data that replication may be allowed between diverse
schema. The Model MAY allow for replication between divergent
schema of objects.

6. Replication Protocol

6.1 The act are parts of replication SHOULD have minimal impact on a distinguished name or they
are using ModifyRequest to both the
system read and network performance.

6.2 The replica synchronization SHOULD be handled write a given attribute
value in such a manner
as to not saturate network with repetitive entry replication
from multiple synchronization providers points.

6.3 Replication MUST only be allowed after single atomic request

If any one of these conditions is reversed, the authentication and
verification types of problems
described above will not occur. There are many useful applications of
multi-master directories where at least one of authorization the above conditions
does not occur. For cases where all four do occur, application
designers should be aware of both the replica possible consequences.

B.6. Data Privacy During Replication

Stokes, et al Expires February 2001 [Page 24]
Internet-Draft LDAPv3 Replication Requirements August 2000

Directories will frequently hold proprietary information. Policy
information, name and the
source directory.

6.4 The transport for LDAP synchronization MUST allow for the
integrity address information, and confidentiality of each replicated server.

6.5 Replicated data MUST customer lists can be
quite proprietary and are likely to be transferable stored in directories. Such
data must be protected during replication.

In some cases, the network environment (e.g. a secure manner.

6.6 Replication protocol MUST private network) may
provide sufficient privacy for recovery and rescheduling
of a replication cycle due to a replication initiation
conflicts (e.g. consumer busy replicating with the application. In other servers)
and or loss of connection(e.g. supplier cannot reach a
replica). The replication protocol MUST include restarting at cases, the last acknowledged update prior to interruption rather than
re-sending updates it had already sent to a consuming replica.

6.7 LDAP replication MUST allow for full update to facilitate
replica initialization
data in the directory may be public and reset loading utilizing not require protection. For
these reasons data privacy was not made a
standardized format such as LDIF [LDIF] format.

6.8 The requirement for all
replication standard SHOULD NOT limit the size of sessions. But there are a
replica. The area substantial number of replication
applications that will need data privacy, so there is defined to be a whole or
portion of a DIT, also allowing a portion of a naming context
to be replicated. Incremental replication SHOULD be allowed.

6.9 The replication agreements MUST accommodate multiple servers
receiving requirement
(S2) that the same replica under a single predefined agreement.

6.10 The replication protocol MUST allow either a master or replica
to initiate the replication process.

6.11 Additionally for data privacy in those cases where it
is needed.

This leaves the initiator MUST be allowed question of what privacy mechanism(s) to determine
whether it will become use. While
this is ultimately a consumer or supplier during design/implementation decision, replication across
different vendors' directory products is an important goal of the
synchronization startup process. This would allow a replica to

Weiser & Stokes 21 April 2000 [Page 12]

INTERNET-DRAFT LDAP Replication Requirements 21 October 1999

be periodically connected and synchronized from remote sites
replication work at the local administrator's discretion.

6.12 Multiple LDAP changes to a single server: IETF. If transactional
consistency is propagated during replication, then multiple LDAP
changes submitted different vendors choose to a single server SHOULD BE treated as a
single 'atomic unit of work'.

6.13 An LDAP Replication Standard SHOULD NOT limit support
different data privacy mechanisms, the transaction
rate advantages of a standard
replication session.

6.14 Entry change information MUST protocol would be purged or discarded lost. Thus there is a requirement (S3)
for a mandatory-to-implement data privacy mechanism.

B.7. Failover in Single-Master Systems

In a
timely manner when change information becomes outdated due to
propagated to single-master system, all replica members.

7. Schema

7.1 Replica knowledge MUST be provided as DSE attributes.

7.2 The Replication Protocol documents MUST define standard schema
for representing replication agreements, and MUST define the
semantics associated with modifying modifications must originate at the attributes of
replication agreements.
master. The documents MUST also define master is therefore a
standard method for determining the location single point of these
agreements accessible utilizing LDAP.

7.3 The Replication Protocol documents MUST define standard schema failure for publishing state information about a given replica, and
MUST define
modifications. This can cause concern when high availability is a standard method
requirement for determining the location of
this information.

7.4 A location independent management point MUST be defined directory system.

One way to reduce the problem is to provide authorized administrators with well known access a failover process that
converts a slave replica to master when the
replication policies, regardless of network location.

7.5 Replication agreements original master fails. The
time required to execute the failover process then becomes a major
factor in availability of all servers containing replicated
information MUST be accessible via LDAP.

7.6 All objects MUST be uniquely identifiable throughout the object
lifetime .

8. Administration system as a whole.

Factors that designers and Management Considerations

8.1 Replication policies MUST allow replication implementors should consider when working on
failover include:

. If the master replica contains control information or meta-data
that is not part of changed the slave replica(s), this information will
have to be administratively postponed inserted into the slave which is being "promoted" to a more

Weiser & Stokes 21 April 2000 [Page 13]

INTERNET-DRAFT LDAP Replication Requirements 21 October 1999

convenient period.

8.2 Allowance for non-scheduled replication
master as part of a replica MUST the failover process. Since the old master is
presumably unavailable at this point, it may be
provided upon request such that difficult to
obtain this data. For example, if the replica server has been
down or unconnected for a period of time.

8.3 Each copy master holds the status
information of a all replicas, but each slave replica MUST maintain audit history information only holds its
own status information, failover would require that the new master
get the status of which servers it has replicated with and which servers all existing replicas, presumably from those
replicas. Similar issues could arise for replication agreements
if the master is the only system that holds a complete set.
Stokes, et al Expires February 2001 [Page 25]
Internet-Draft LDAPv3 Replication Requirements August 2000

. If data privacy mechanisms (e.g. encryption) are in use during
replication, the new master would need to have
replicated with it.

8.4 A replica MUST store conflicted versions the necessary key
information to talk to all of the replicated
object slave replicas.

. It is not only the new master that needs to allow optional human review and intervention.

8.5 Access be reconfigured. The
slaves also need to replication predetermined agreements, topologies, have their configurations updated so they know
where updates should come from and
policies attributes MUST where they should refer
modifications.

. The failover mechanism should be provided through LDAP access.

8.6 able to handle a situation where
the old master is "broken" but not "dead". The slave replicas
should ignore updates from the old master after failover is
initiated.

. The capability old master will eventually be repaired and returned to check the differences between two replicas
for
replica ring. It might join the same information SHOULD be provided for. This should
entail ring as a client invoking an operation at some server, which
causes that server to extract slave and pick up the contents from some other
server
changes it has a replication agreement with and report "missed" from the
differences back new master, or there might be
some mechanism to bring it into sync with the client new master and then
let it take over as master. Some resynchronization mechanism will
be needed.

. Availability would be maximized if the result.

8.7 Authenticated access SHOULD whole failover process
could be provided so automated (e.g. failover is initiated by an external
system when it determines that Administrative
LDAP clients may query a server for the current state and
replication history for each replica original master is not
functioning properly).

B.8. Including Operational Attributes in Atomic Operations

LDAPv3 [RFC2251] declares that the server maintains
replication agreements with.

8.8 The ability to view replication conflicts, and override the
resolution derived by the replication policy MUST be provided.

8.9 The deletion some operations are atomic (e.g. all of sensitive data MUST be handled
the modifications in an orderly
manner so that at no time will a single ModifyRequest). It also defines several
operational attributes that data be available without
proper access control. That is, access control store information
(ACI) associated with sensitive data must be deleted after or
simultaneously with the delete of the sensitive data. Likewise, about when adding sensitive data, ACI MUST be added first or
simultaneously with changes are
made to the addition of that data.

9. Acknowledgement

This document is based on input from IETF members interested in LDUP
Replication.

Weiser & Stokes 21 April 2000 [Page 14]

INTERNET-DRAFT LDAP Replication Requirements 21 October 1999

10. References

[RFC2251] M. Wahl, T. Howes, S. Kille "Lightweight Directory Access
Protocal", RFC 2251.

[RFC2119] S.Bradner, " Key words directory (createTimestamp, etc.) and which ID was
responsible for use a given change (modifiersName, etc.). Currently, there
is no statement in RFCs RFC2251 requiring that changes to indicate
Requirement Levels", RFC 2119.

[LDIF] Gordon Good, "The LDAP Data Interchange Format (LDIF)",
Internet draft, draft-ietf-asid-ldif-00.txt, November 1996.

[Changelog] Gordon Good, "Definitions of an Object Class these operational
attributes be atomic with the changes to Hold
LDAP Change records", Internet Draft, draft-ietf-asid-changelog-
00.txt, November 1996.

[X.501] ITU-T Recommendation X.501 (1993), | ISO/IEC 9594-2: 1993,
Information Technology - Open Systems Interconnection - The
Directory: Models

[XEROX] Hauser, C. "Managing update conflicts in Bayou, the data.

It is RECOMMENDED that this requirement be added during the revision of
RFC2251. In the interim, replication SHOULD treat these operations as
though such a weakly
connected replicated storage system". Palo Alto, CA: Xerox PARC,
Computer Science Laboratory; 1995 August; CSL-95-4. [CSL-95-04]

11. Author's Address requirement were in place.

Authors' Addresses

Russel F. Weiser
Digital Signature Trust Co.
One
1095 East 2100 South Main Street
Suite #201
Salt Lake City, Utah 84111 84106

Stokes, et al Expires February 2001 [Page 26]
Internet-Draft LDAPv3 Replication Requirements August 2000

USA
E-mail: rweiser@digsigtrust.com
Telephone: +1-801-983-4415
Fax +1-801-983-4408 +1 801 246 4323
Fax: +1 801 246 4361

Ellen J. Stokes
IBM
11400 Burnet Rd.
Tivoli Systems
6300 Bridgepoint Parkway
Austin, Texas 78758 78731
USA
E-mail: stokes@austin.ibm.com estokes@tivoli.com
Telephone: +1-512-838-3725 +1 512 436 9098
Fax: +1-512-838-0156

Weiser & Stokes 21 April 2000 +1 512 436 1199

Ryan D. Moats
Coreon, Inc.
15621 Drexel Circle
Omaha, NE 68135
USA
E-Mail: rmoats@coreon.com
Telephone: +1 402 894 9456

Richard V. Huber
Room C3-3B30
AT&T Laboratories
200 Laurel Avenue South
Middletown, NJ 07748
USA
E-Mail: rvh@att.com
Telephone: +1 732 420 2632
Fax: +1 732 368 1690

Full Copyright Statement

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

Stokes, et al Expires February 2001 [Page 15] 27]
Internet-Draft LDAPv3 Replication Requirements August 2000

in the Internet Standards process must be followed, or as required to
translate it into languages other than English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the
Internet Society.

----