Last Modified: 2003-02-12
o Multi-Master Replication - A replication model where entries can be written and updated on any of several replica copies, without requiring communication with other masters before the write or update is performed.
o Master-Slave, or Single-Master Replication - A replication model that assumes only one server, the master, allows write access to the replicated data. Note that Master-Slave replication can be considered a proper subset of multi-master replication.
The WG's approach is to first develop a set of requirements for LDAPv3 directory replication and write an applicability statement defining scenarios on which replication requirements are based. An engineering team was formed consisting of different vendors and the co-chairs in order to harmonize the existing approaches into a single standard approach. All of these have been accomplished during the pre-working group stage. It should be noted, however, that replication using heterogeneous servers is dependent on resolving access control issues, which are the domain of other working groups.
The new replication architecture support all forms of replication mentioned above. Seven areas of working group focus have been identified through LDUP Engineering Team discussions, each leading to one or more
Engineering Team discussions, each leading to one or more documents to be published:
o LDAPv3 Replication Architecture
This documents a general-purpose LDAPv3 replication architecture, defines key components of this architecture, describes how these key components functionally behave, and describes how these components interact with each other when in various modes of operation
o LDAPv3 Replication Information Model
Defines the schema and semantics of information used to operate, administer, maintain, and provision replication between LDAPv3 servers. Specifically, this document will contain common schema specifications intended to facilitate interoperable implementations with respect to:
+ replication agreements
+ consistency models
+ replication topologies
+ managing deleted objects and their states
+ administration and management
o LDAPv3 Replication Information Transport Protocol
LDAPv3 extended operation and control specifications required to allow LDAPv3 to be used as the transport protocol for information being replicated
o LDAPv3 Mandatory Replica Management
Specifications required to allow administration, maintenance, and provisioning of replicas and replication agreements. These specifications may take the form of definitions for LDAPv3 extended operations, controls, and/or new schema elements.
o LDAPv3 Update Reconciliation Procedures
Procedures for detection and resolution of conflicts between the state of multiple replicas that contain information from the same unit of replication.
o LDAPv3 Profiles
Including the LDAPv3 Replication Architecture, Information Model, Protocol Extensions, and Update Reconciliation Procedures for:
+ LDAPv3 Master-Slave Directory Replication
+ LDAPv3 Multi-Master Directory Replication
o LDAPv3 Client Update
A protocol that enables an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content.
The work being done in the LDUP WG should be coordinated to the closest extent possible with similar work being done in the ITU. This is necessary both because LDAP depends on X.500 and because it makes sense from an operational perspective.
|Done||Submit I-D on LDAPv3 Directory Replication Requirements.|
|Done||Submit Internet-Draft on LDAPv3 Replication Information Model|
|Done||Submit I-D on LDAPv3 Update Reconciliation Procedures.|
|Done||Revise I-D on LDAPv3 Directory Replication Requirements.|
|Done||Revise I-D on LDAPv3 Replication Architecture.|
|Done||Revise I-D on LDAPv3 Replication Information Model.|
|Done||Submit I-D on LDAPv3 Replication Information Transport Protocol.|
|Done||Revise I-D on LDAPv3 Replication Architecture.|
|JAN 01||LDAPv3 Directory Replication Requirements I-D goes to WG Last Call as Informational.|
|JAN 01||LDAPv3 Update Reconciliation Procedures I-D goes to WG Last Call as Proposed Standard.|
|Done||Submit I-D on LDAPv3 Mandatory Replica Management.|
|MAR 01||Submit I-D on LDAPv3 Multi-Master Replication Profile.|
|MAR 01||Submit I-D on LDAPv3 Master-Slave Replication Profile.Submit I-D on LDAPv3 Master-Slave Replication Profile.|
|APR 01||LDAPv3 Replication Information Model I-D goes to WG Last Call as Proposed Standard.|
|APR 01||LDAPv3 Replication Architecture I-D goes to WG Last Call as Informational.|
|APR 01||LDAPv3 Subentry Schema goes to WG Last Call (joint with LDAPEXT) as Proposed Standard.|
|JUN 01||LDAPv3 Client Update Protocol I-D goes to WG Last Call as Proposed Standard|
|JUN 01||LDAPv3 Replication Information Transport Protocol I-D goes to WG Last Call as Proposed Standard.|
|AUG 01||LDAPv3 Extended Operations for Framing I-D goes to WG Last Call as Proposed Standard.|
|DEC 01||LDAPv3 Mandatory Replica Management I-D goes to WG Last Call as Proposed Standard.|
|DEC 01||LDAPv3 Multi-Master Replication Profile I-D goes to WG Last Call as Proposed Standard.|
|DEC 01||LDAPv3 Master-Slave Replication Profile I-D goes t WG Last Call as Proposed Standard.|
|DEC 01||Reevaluate Charter and Milestones|
|RFC3384||I||LDAPv3 Replication Requirements|
See text below. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:firstname.lastname@example.org http://www.dsi-consulting.com ======================================== ================================= LDAP Duplication/Replication/Update Protocols WG (ldup) Tuesday, March 18 at 1300-1400 =============================== CHAIRS: Chris Apple <email@example.com> John Strassner <firstname.lastname@example.org> Minutes taken by: John Strassner The meeting was run according to the posted agenda. The meeting minutes therefore mirror the agenda topics. 1. Consensus on a path to conclude - Chris Apple reporting It was obvious from the last meeting that we weren't going to be able to achieve consensus to produce standards-based documents for all of the work that is listed in our current charter. After an email exchange, consensus was reached that the working group would try and move all documents forward on an experimental path. The one exception to this is the LCUP document, which is targeted at the standards track. There were no comments to this presentation. 2. Status of various documents. 2a. LDAP Client Update Protocol - Rich Megginson reporting The URL for this is: http://www.ietf.org/internet-drafts/draf t-ietf-ldup-lcup-04.txt Rich opined that the draft is good as is and ready to be released, with the one exception that Kurt Zeilenga and John Young are not happy with the draft. Kurt has posted a counter draft, called LDAP Content Sync, available at the following URL: http://www.ietf.org/internet-drafts/draf t-zeilenga-ldup-sync-01.txt First, it should be noted that the two drafts have moved closer to agreement. However, there are still significant differences between these two drafts, and the nature of the disputes are fundamental to the design of each. The disputes boil down to three points of contention. The first point of contention is that while both protocols synchronize directory information, LCUP operates within the user information model, while LDAP Content Sync operates within the system information model. An example of a facsimileTelephoneNumber implemented as a virtual or a collective attribute was used. The difference between how the two protocols operate for this example is two-fold: LCUP provides the changed data, LDAP Content Sync doesn't. LCUP causes every entry with the collective attribute definition to be reported as modified (which could in turn cause a large number of entries to be returned to the client), while LDAP Content Sync only returns one entry. The difference in the above is that with LCUP, the client doesn't need to know the details of the physical information model, whereas with LDAP Content Sync, the client must know the details of the physical information model. The second area of difference is that LCUP requires history to be maintained, while LDAP Content Sync doesn't. LCUP sends one entry because it has historical data present; LDAP Content Sync sends the full requested entry if modified, or sends the DN or UUID of the entry for unchanged entries. This means that the client is responsible for deleting entries from its local store that are not returned.Â This in turn means that if there are N entries in the result set of the search, modifying one value will cause N messages to be sent. The final major difference is that in LCUP, changes to meta data, as well as subtree operations may either cause the client to resync, or to send a large number of messages. This is because LCUP assumes that these operations are very infrequent and therefore relatively inexpensive. LDAP Content Sync doesn't have this side-effect because it always sends a message for every entry. Kurt stated that as designed, LCUP doesn't meet the needs of OpenLDAP. Rich stated that the issues that Kurt is raising are beyond the original design scope of LCUP. The co-chairs recommended two action items, which were accepted by the meeting attendees: 1) Rich and Kurt should meet and try and resolve their differences by COB Friday this week. If their differences can't be resolved, then they should report that to the working group. 2) Both drafts will need applicability statements added if they want to be progressed. The co-chairs will propose a recommended course of action based on the results of the meeting of Rich and Kurt. 2b. LDUP Update Reconciliation Procedures - Steven Legg reporting The URL for this is: http://www.ietf.org/internet-drafts/dra ft-ietf-ldup-urp-07.txt Steven reported that there are no technical changes to this document; it was reissued to avoid becoming obsolete. Some minor work needs to be done to update references, and then it is ready to go. 2c. LDAP Replication Architecture - Chris Apple reporting for Uppili Srinivasan The URL for this is: http://www.ietf.org/internet-drafts/dra ft-ietf-ldup-model-08.txt Chris reported that there are no technical changes to this document; it was reissued to avoid becoming obsolete. Ed Reed is retiring as an author from this effort, but John Merrells and Gerry Maziarski have both volunteered to help. While the document is ready from the point-of-view of the LDUP requirements and the Mandatory Replica documents, it still has references to many issues that are outside the scope of LDUP as it is currently defined. Examples of this include access control and the administration model. Thus, the plans for finishing this document are to first ensure consistency with other LDUP documents, then to excise these other issues, and finally to do one last pass before a last call. 2d. LDUP Replication Information Model - Chris Apple reporting on behalf of the authors The URL for this is: http://www.ietf.org/internet-drafts/dra ft-ietf-ldup-infomod-06.txt This is an important draft, especially because many other documents depend on it. An update for it is promised by mid to late April. The current update was done to avoid it expiring. 2e. The LDUP Replication Update Protocol - Chris Apple reporting on behalf of the authors The URL for this is: http://www.ietf.org/internet-drafts/dra ft-ietf-ldup-protocol-04.txt Chris reported that there are no technical changes to this document; it was reissued to avoid becoming obsolete. It is in good shape for being released. Two actions need to be taken before that can happen: 1) Document Editor needs to complete search of mail archives to ensure that no open issues exist (currently doesn't believe that any exist). 2) Changes to other LDUP docs that affect this document will of course cause it to change; we'll need to see if any such changes happen or not. 2f. General Usage Profile for LDAPv3 Replication - Chris Apple reporting on behalf of the authors The URL for this is: http://www.ietf.org/internet-drafts/dra ft-ietf-ldup-usage-profile-04.txt Chris reported that there are no technical changes to this document; it was reissued to avoid becoming obsolete. The co-chairs would like to see comments on this document. One thing to think about as you comment is whether this profile is sufficient, or whether the single- and multi-master replication profiles are still needed. 2g. Mandatory LDAP Replica Management - Chris Apple reporting on behalf of the co-authors The URL for this is: http://www.ietf.org/internet-drafts/dra ft-ietf-ldup-mrm-02.txt This draft is dependent on the information model, and can't really be updated until the Information Model is updated. It will be turned around as quick as possible once this is done. 3. WG Charter Revision/Review The only thing that has changed so far was the milestones. This is because we have established consensus on a path to conclude our work. If the co-chairs detect that there is significant slippage in these dates, then the co-chairs will most likely recommend that the working group conclude immediately. We need to discuss on the mailing list whether we need to keep the single- and multi-master profiles in the charter, or whether the general usage profile is sufficient. Kurt expressed concern over the charter wording, and would like to see "re-evaluate" changed to "conclude." Chris responded that in the past, the use of "conclude" was discouraged by the ADs. 4. Next steps Chris will revise the charter posting. The LCUP gang will get together with Kurt and report progress (or lack thereof) to the WG by this Friday (3/21). Information model draft needs to be discussed and revised as soon as possible. End of meeting.