draft-zeilenga-ldup-harmful-00.txt

IMHO, this draft takes a very extreme position, stated here:
---------------------------------------------------
6. Conclusions

  The X.500/LDAP information and service models does not support
  multi-master replication and cannot be altered to support multi-master
  replication without causing great harm.  LDAP server developers should
  heed this implementation absolute imperative [RFC 2251, Section 3.3].

      This document defines LDAP in terms of X.500 as an X.500 access
      mechanism.  An LDAP server MUST act in accordance with the
      X.500(1993) series of ITU recommendations when providing the
      service.  However, it is not required that an LDAP server make use
      of any X.500 protocols in providing this service, e.g. LDAP can be
      mapped onto any other directory system so long as the X.500 data
      and service model as used in LDAP is not violated in the LDAP

------------------------------------------------------

Multimaster deployments of LDAP are common.  Yes, they can have the kind of
deleterious effects Kurt describes.  But they are widely used anyway, and
do not cause "great harm".  Multimaster deployments are necessary to
provide a highly available writeable directory infrastructure, because a
single master can crash, making the resulting directory service read-only
until the server is recovered.  We have to have highly available write
support.

Why do we not see "great harm" in the many existing multimaster
deployments?  Typically, this is because multiple masters are used in a
failover configuration, so that only one master is active at a given time.
This usage pattern can't guarantee that update collisions and a consequent
breakage of the service model.  First, when failover occurs, one master may
not have replicated some recent updates, so that the newly active master
could accept updates that conflict with not yet replicated ones.  Second,
and more seriously, failover could occur because of loss of a WAN
connection, in which case one could have several masters active at the same
time.  Despite these risks, LDAP directories are widely deployed in
multimaster configurations, because the consequences of losing write access
are severe enough to justify the risk of collisions.

Another reason "great harm" does not occur is because the usage examples
from this draft are not representative of most LDAP operations.  When an
entry is updated, it is typically not to increment a counter or to create a
value that must be unique directory-wide.  These use cases are the
exception rather than the rule, but there is good reason to support them as
well.  This can be done using an operations mastering control.  The control
would ensure that the change is made on a single authoritative master, or
failed if that master is not available.  Via this approach, reliable
counters and uniqueness registries could be implemented in LDAP.
Operations mastering does require code changes on the client side.  This is
as it should be, although it is not in formal compliance with the cited
paragraph RFC 2251 section 3.3.  We want clients to default to high
availability behavior and not to operations mastering.


John McGarvey
IBM directory architect
919-877-4892