Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D

From: "Ed Reed" <[email-masked]>
Date: Tue, 20 Feb 2001 08:41:31 -0700

Hmmm...I've found a point of agreement with Albert ;-)... see [eer]

=================
Ed Reed
Reed-Matthews, Inc.
+1 801 796 7065
http://www.Reed-Matthews.COM

>>> "Albert Langer" <[email-masked]> 02/17/01 01:30PM >>>
[Kurt]
At 04:39 PM 2/17/01 +1100, Albert Langer wrote:
>Put succinctly: LDUP directories won't interoperate. Period.

I would say that two LDUP peers could interoperate (from
a protocol perspective) but that this, in itself, does
not:
        1) preserve LDAP/X.500 semantics nor
        2) provide "equally capable" replicas.

The former issue can not be resolved unless one requires
transactional consistency in multiple master replication.
The latter issue can be tackled by writing a very tight
applicability statements.

[Albert]

...snip...

A necessary consequence of multi-master, as opposed to single master,
is that in addition to transient inconsitencies between data read from
different directory servers there will also be problems with data read
from a single server. There are 2 options possible for multi-master:

1) Conflicting updates to the same entry are prioritized so that only
one succeeds and the others are rolled back. That necessarily results
in different behaviour to single master directories but is not
fundamentally inconsistent with LDAP semantics and does not prevent
interoperability. Problems arising can be resolved by users rather than
sysadmins by notifying them of lost updates (whether due to name conflicts
or
other conflicts). An applicability statement should clearly indicate
that multi-master is unsuitable in any situation with a high rate of
concurrent changes to the same entries.

[eer] I certainly agree that we should make clear (if we have not
already), that multi-master is unsuitable in any situation with a
high rate (say, frequently faster than the time it takes for a change
to fully propagate to all registered replicas) of concurrent changes
to the same entries at different master replicas.

The "frequently..." qualifier represents my own bias as to what
is "reasonable" and might be changed to simply say "faster than...".

[/eer]

---

From: John Strassner <[email-masked]>
Date: Tue, 20 Feb 2001 08:21:29 -0800

This seems reasonable, but I would suggest that we quantify this, perhaps 
in terms relative to the (average) replication frequency of the system. 
Thoughts?

regards,
John

---

From: Richard Huber <[email-masked]>
Date: Tue, 20 Feb 2001 18:09:39 -0500

John, I really don't think the requirements document is the place to quantify
this.  If the list really thinks we need to quantify it, let's do it in the
profile document (though it probably won't make the -00 draft which needs to
get in by Friday).

As for Albert's/Ed's original point, I agree.  The requirements already note in
B.5.5 that  having multiple users/applications changing the same data at the
same time is a way to get into trouble.  I suppose we could change "at the same
time" to "before previous changes have replicated" if that makes it clearer.

Rick Huber