Re: Applicability of LDAP Content Sync to loosely coupled replica sets

[email protected] (Mark C Smith) Mon, 09 Jun 2003 10:18:09 -0400
Newsgroups gmane.ietf.ldup
Organization Netscape Communications Corp.
Message-ID <[email protected]>
John McMeeking wrote:
> 
> 
> 
> 
> I think either of the sync proposals could be made to work with loosely
> coupled replicas if:
> 1) the replication mechanism supports something like LDUP's "update vector"
> -- something that indicates the latest information a replica has seen from
> other replicas, AND
> 2) the cookie contains the equivalent of an update vector, AND
> 3) there is a defined cookie format that is understood by the DSAs the
> client syncs with (possibly requested by the client)
> 
> This is already described in the back of LCUP, but it applies to both sync
> proposals.
> 
> Or did I misinterpret this discussion?
> 
> [BTW - (3) is something else that is missing from draft-zeilenga-ldup-sync,
> but I'm almost convinced it isn't needed.  Read on.]

In the past, there were very strong feelings expressed by several LDUP 
WG members that a defined cookie format IS needed. Assume Server A was 
written by Vendor A and Server B by Vendor B. Without a well defined 
cookie format, an LCUP client will not be able synchronize with Server A 
today and with Server B tomorrow without doing a full reload. While I 
think we are some distance away from being ready to define a standard 
cookie format, I do agree we will want to do so eventually. Hence the 
cookie scheme identifier (OID) contained in the LCUP working group 
deliverable.

Because I interpreted the recent charge from the WG chairs and ADs as 
"focus on whether draft-ietf-ldup-lcup-05 has any show stopper problems" 
I have avoided diving into a detailed discussion of 
draft-zeilenga-ldup-sync.  But one comment related to this cookie issue: 
the text in draft-zeilenga-ldup-sync leads me to believe that its 
"Synchronization Sessions" not only can't occur across different vendor 
implementations, but are restricted to one particular server instance as 
well. That limitation might be OK if your primary goal is to provide 
server to server replication, but it is unacceptable in many other 
scenarios. For example, I want to provide a distributed set of LDAP 
replicas that email clients may use to maintain offline copies of the 
corporate addressbook.

-Mark