Repl Req Summary

["John Merrells" <merrells@xxxxxxxxxxxx>]

To help my understanding of the requirements document I
extracted and numbered all the clauses. This may help you
too...


Summary of Replication Requirements

<4. General Requirements>

1) Simple - Replication MUST be simple to configure and maintain.

2) Efficient - The act of replication MUST have minimal impact on both
the system and network performance and throughput. In order to
achieve this efficiency, replication policies SHALL allow
replication of changed information to be postponed to a more
convenient period, or done at user request. It is not required to
have all replica copies on the network available at replication
time. In a distributed enterprise environment, it is unrealistic to
assume that all copies of a replica will be available for update at
all times. Under this circumstance, when a previously unavailable
replica copy comes on line, it SHOULD initiate replication with
another replicated copy such that its local replicated information
is brought up to date.

3) Reliable - All replicated copies MUST eventually be updated with
the changed information, specified by the replication policy.

4) Provides Interoperability between vendors - Replicas MUST  be
allowed to span different vendors directory services. Without such
vendor interoperability, Internet based directory services will not
be feasible.

5) Security of data, connections and replication process - Replicated
data MUST be transferred in a secure manner, where both endpoints
in the communication have identified and authenticated themselves
to the other server.

6) Robustness - The ability to deal with differences in directory
services schemas in a cross vendor enterprise. The ability to
recover when a replica server is unavailable during replication.

7) Location independent manageability - A replica administrator MUST
be allowed access to the replication policies, regardless of
network location.

8) Auditability - Each copy of a replica MUST maintain a history of
who it has replicated with and who has replicated with it.

9) Ability to Set Change Metrics - Replication schedules MUST be
dynamic to allow for periodic replication, with the replication
period determined by administrator of the replicated system. In
addition, replication policy must be globally available to any
authorized administrator from anyplace on the network.

10) Replication Policy Mechanisms - Policies to allow both schedule and
content of replicated information MUST be allowed.  Policies SHALL
allow replication to be schedule both on a periodic basis, as well
as on a number of changes basis.

11) Multi-master and Master-Slave - Support for both multi-master and
master-slave environments should be a driving requirement. Since
master-slave is considered a proper subset of multi-master, both
these models MUST be supported.

12) Flexibility - LDAP replication MUST allow for both total and
incremental update of objects. In addition, updates MUST be allowed
to multiple replicas to enhance distributed performance and
reliability.

13) Synchronization of LDAP replicas MUST allow either master or
replica to initiate the replication process and allow the initiator
to determine whether it will become a consumer and or supplier
during the synchronization process. This would allow a replica to
be periodically connected and synchronized from remote sites at the
local administrator's discretion.

14) All replicated information between the master database and its
replica databases SHALL be identical including all no 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.

15) Distributed multi-vendor environment, LDAP replication SHALL NOT
ensure all copies of the replicated information be complete copies
of the replicated object. It is not realistic to assume that all
vendors have cooperating schemas, but it is required that different
vendors schemas allow replication from diverse schemas. LDAP
replication SHALL encompass common schema objects and attributes,
and MAY define a model whereby divergent schemas can replicate
non-common or extended attributes for common LDAP objects.

16) SubTree Replication - Subtree Replication SHALL be defined to allow
for greater flexibility replication toplologies of the DIT as
discussed in X.525 section 7.2 [X.525].


<4.1 Replication policy>

17) Policies for the LDAP replication SHALL be defined in such a manner as
to allow programmatic representation; these policies shall be kept as
replica attributes or as entries of the predetermined agreement
discussed in section 4.2 to be propagated during replication.


<4.1.1 Propagation behavior>

18) Replication SHALL only be allowed after the authentication and
verification of authorization of both the replica and the source
directory.

19) The transport for LDAP synchronization MUST allow for the integrity
and confidentiality of each replicated server.

20) The replica synchronization MUST be handled in such a manner as to
not saturate network with repetitive entry replication from multiple
synchronization providers points.

21) Full copy replication SHOULD be supported for reset and initial
loading of a replica using the LDIF [LDIF].

22) The normal means of synchronizing replicas SHALL be performed
through incremental synchronization and in accordance with the
scheduling policies of section 4.1.2.

23) Multiple LDAP changes, to a single server, SHOULD be allowed to be
treated as single atomic unit of work propagated during replication.

24) Entry change information SHALL be purged upon completion of a
synchronization cycle where all replica members have been synchronized
with the master(s).

25) Replication policies SHOULD contain clauses to account for the
instance of a replica being unavailable at the scheduled update time.


<4.1.2 Scheduling policies>

26) A propagation schedule SHALL be defined and SHOULD be tunable such
that every X hours and or N changes will automatically begin a
replication cycle.

27) Immediate replication of critical values in secs/mins such as user
password changed SHALL be supported.

28) Allowance for non scheduled replication of a replica SHALL be
provided upon request such that the replica server has been down or
unconnected for a period of time.


<4.2 Predetermined Replication Agreements>

29) The use of predetermined replication agreements between the master
directories and replica directories MUST be addressed to provide
proper knowledge of access requirements and credentials between the
synchronizing directories.

30) Replication agreements SHOULD be accessible, via LDAP, to all servers
containing replicated information.


<4.3 Scalability>

31) Large amounts of replicated data. The unit of replication is
defined to be the naming context. This naming context may consist of
large amounts of data, all of which may be replicated. The replication
mechanism must account for any amount of data to be replicated.
Incremental replication MUST be allowed to attempt to keep the amount
of data replicated to a minimum.

32) Scale to global Internet, or not. Due to the acceptance and usage
of the Internet, and the requirement that LDAP replication be
available across disparate vendors directory services, LDAP
replication MUST scale to the internet level, but also must function
at the enterprise level.

33) Large numbers of replicas, ie distributivity. A policy MUST be
defined to account for simultaneous updates to multiple master
replicas, where simultaneous is defined to be a period between
replications. In such a case, these replication "conflicts" SHALL be
resolved by the replication policy. A replica MAY store the conflicted
versions of the replicated object to allow optional human review and
intervention.

34) Arbitrary replication topology. Replication SHALL be allowed to any
LDAP server available on the network.


<4.4 LDAP Access>

35) MUST provide access to replication topology and policies via LDAP.

<4.5 Administration Utility Requirements>

36) SHALL The capability to check the differences between two replicas of the
same information.

37) SHALL The capability to view the replication topology from a single
server in the topology.

38) SHALL The capability to view the current state and replication history of
each replicated copy in the replication topology, from a single server
in the topology.

39) SHALL The ability to view replication conflicts, and override the
resolution derived by the replication policy.



--
John Merrells
Netscape Communications
Directory Server
Software Engineer

http://people.netscape.com/merrells