Comments on ldup-replica-req-00.txt

[Alan Lloyd <Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx>]

Dear All
Just some observations - re the replication model.


It seems from the requirements text that the client software replicates
by reading one server and then passing that to another.
In X.500 replicas are implied in the replicated system on the fact they
have rxd the data by DISP (a totally different protocol to the access
protocols). Therefore it is the DSA that determines the entry
information context be it a master or a replica. With LDAP doing updates
on behalf of replication operations - is the client software now
responsible for marking the data as a replica before it is sent to the
replicated server.

How is this done? Do we need more labels and/or attribute options in the
schema documents to say that each attribute is a replica or not?

In multimaster mode, information will have to mastered in both - so now
the client software will have to know this if it replicating to a multi
master. or not
In transferring many objects/entries over LDAP the connection may fail
so a recovery point is needed. X.500 DISP is an atomic operation and
implementations must ensure that a single DISP pdu works or does not. In
the LDAP case - what are the recovery steps - are DIT locking mechanisms
required.

ie. If the master has added parts and then deleted others - and this is
sent to the replica via LDAP , the adds could get applied and the
deletes not. (as per 4.1.1 bullet 6.)

Also DAP has a control which can select master or copy information. Will
this be added to LDAP.

Is the LDAP for replication protocol likely to be employed between
servers in a bi- directional fashion to deal with replication or will
the replication be performed as a free standing client?

In the first case looping may happen in multimasters unless attribute
value checking is done . In both cases client or recipient has to apply
copy flags and deal with atomicity and recovery.

I am not sure how this will work given the previous debates re
transactions, object paradigms, resource locking and conflicts with
persistent searches (which can be used in replication for incremental
updates on change).

Are there issues with replica - incomplete entries

regards alan