2.1.18 LDAP Duplication/Replication/Update Protocols (ldup) bof

Current Meeting Report

Minutes of the LDAP Duplication/Replication/Update Protocols (ldup) Working Group

Recorded by John Strassner and Chris Apple (co-chairs).

We first reviewed the proposed charter and arguments that led to the charter from the December meeting. The point of concern was the prescribed ordering of problems to solve in the charter - one-way dir sync, then two-way dir-sync, then multi-master replication. We then reviewed recent discussion on the list concerning the charter. Central to this were two themes:

1) The need for an architecture document that addresses multi-master replication, with other forms of replication and synchronization emanating from that, and
2) The concept of a specification "bake-off", which would seek to bring together differing implementations

Theme #1 means that we must define a replication architecture that addresses multi-master requirements from the beginning. The concern is that if was not done first, there might be fundamental deficiencies in the resulting architecture that would have to be revisited. Furthermore, it was thought that other flavors of replication (as mentioned in the proposed charter) could be treated as functional subsets of such a multi-master replication architecture.

Theme #2 addresses the fact that individual vendors have already started addressing the need to do multi-master replication. However, this has resulted in differing implementation approaches, and there is concern that with no agreed-upon standard in place, this will fragment the LDAP community and lead to solutions that are not interoperable. To prevent this, the idea of a "specification bake-off" was proposed. The intent is to get rapid convergence on a common implementation. By forcing candidate implementations and ideas from those implementations to be written down and reviewed in an open forum, it will "weed out" people that don't have time to come up with a full proposal, and help converge dissimilar architectures that are starting to be developed from differing implementations. This was proven to be true - about 25 people raised their hands when asked if they had an implementation to offer or were working on one; only 8 companies ended up agreeing to present a specification for the proposed bake-off.

Concern was expressed that the architecture document must be structured in such a way as to enable the parts that are required only for multi-master to be "stripped off" so that "clean and lean" simpler implementations (e.g., 1-way dir sync) could be supported.

After much discussion, the group converged on the following approach:

1) Finish off a new draft of the requirements document asap (note that this document already assumes a multi-master system)
2) Concurrently, set up an engineering group to enable interested people to work on a common architecture.
3) The architecture document would then result in a set of specifications that were aimed specifically at 1-way, 2-way, and multi-master implementations.

An engineering team mailing list has been set up to allow interested architectural constituents to share information about their ideas for an architectural draft. An abstract of each proposal is due to be submitted to the engineering group by 17 April. A face-to-face meeting of these constituents is scheduled for May 1, 1998. Constituents will discuss their proposal concepts at this meeting with a goal of reducing the total number of independent architectural proposals to one. The idea is for individual proposals to build off of each other and either result in a new proposal that uses elements from previous proposals or be subsumed by another proposal. If this goal is not achieved, we may end up with multiple proposals that will be discussed on the LDUP mailing list by a broader community. The proposers were exhorted by Harald as well as other members of the group to try to converge asap.

There are currently six companies involved: Netscape, Microsoft, Innosoft, IBM, Novell, Oracle, Cisco, and Stanford. Several of these stated up front that they are not trying to submit a full-blown proposal by themselves; rather, they are looking to contribute resources and ideas as part of a larger effort. It appears that there are at least four proposals that will be written.

The applicability statement will be folded into the requirements document. Each proposal will address how it satisfies the functionality stated in the requirements draft.

Our schedule is as follows:

Slides

None Received

Attendees List

go to list