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

[Richard Huber <rvh@xxxxxxx>]

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

John Strassner wrote:

> 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
>
> At 08:41 AM 2/20/2001 -0700, Ed Reed wrote:
> >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" <Albert.Langer@xxxxxxxxxxxxxxxxxxxxx> 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]