[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: [ldapext] Fwd: I-D ACTION:draft-zeilenga-ldap-incr-00.txt



The application of this problem to Multi-Master Replication (MMR) in
general is incorrect. It should be associated with Loosely Consistent
Multi-Master Replication (LCMMR). There are mechanisms which could allow
for consistent MMR, thus allowing the X.500 service model to be adhered
to.
 
Furthermore, there are mechanisms which would allow even
implementations of LCMMR to act in accordance with the X.500 service
model when required (or conversely -- to make it truly-optional -- allow
the transactional and atomicity semantics of the X.500 service model to
be optionally ignored). For example, enforce that certain modifications
always happen on a predetermined master, but allow that behavior to be
optionally overridden.
 
Note that neither of these points means that the incr I-D (or any other
I-D) needs to consider the problems introduced by LCMMR. It would be the
job of a LCMMR specification to state these problems (and possible
solutions).

Mostly, I dislike it when messages end up demonizing MMR in a general
way, and wanted to clarify the points above.
 
Jim

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 10/21/04 1:49:11 PM >>>
At 10:45 AM 10/21/2004, David Boreham wrote:
>>In LDAP, clients may presume server is acting in accordance
>>with the X.500 data model. If the server is unable or
>>unwilling to do that, then it should not provide service.
>
>I see, I think you've answered my question: this
>feaure should not be implemented by servers that
>are participating in a multimaster replication mechanism
>with respect to the entry being modified (unless the
>server does something unusual to deliver the
>required consistency guarantees such as using 2-phase
>commit).

It's my view that servers which are 'participating in
a multimaster replication mechanism' are not LDAP servers.
LDAP servers, aside from communicating using LDAP PDUs,
act in accordance with X.500. While the servers you
refer might communicate using LDAP PDUs, they are not
acting in accordance with X.500 and hence, in my view,
are not LDAP servers.

>It might be worth noting this in the draft, for those
>who might ask this question in the future.

I think its sufficient to specify that LDAP servers
are to act in accordance with X.500. This I-D does
so by incorporating [Roadmap].

That said, I think it would be good to note to the
community the harm that truly non-optional introduction
of MMR might have on existing directory applications,
to reiterate to implementors that LDAP servers are to
act in accordance with X.500, and encourage those
who desire a different service model to design and
specify a system that offers it. That system could
be based on LDAP, but if so, it should engineered
as a truly optional extension to LDAP.

(For those who don't grok the terms "truly optional"
or "truly non-optional", I refer you to discussion
of the "MAY" keyword in RFC 2119).

Kurt 


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org 
https://www1.ietf.org/mailman/listinfo/ldapext 


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext