Last Modifield: 06/07/2002
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||Submit I-D on LDAPv3 Replication Information Transport Protocol.|
|Done||Revise I-D on LDAPv3 Replication Architecture.|
|Done||Revise I-D on LDAPv3 Replication Information Model.|
|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 Subentry Schema goes to WG Last Call (joint with LDAPEXT) as Proposed Standard.|
|APR 01||LDAPv3 Replication Architecture I-D goes to WG Last Call as Informational.|
|JUN 01||LDAPv3 Replication Information Transport Protocol I-D goes to WG Last Call as Proposed Standard.|
|JUN 01||LDAPv3 Client Update 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|
LDUP WG Meeting Minutes November 20, 2002 We initiated a chat conference with remote attendees using the facilities provided. Roger G. Harrison volunteered to take notes for the meeting minutes. The co-chair in attendance, Chris Apple, spoke on behalf of remote attendees and displayed the chat conference room window on the overhead screen while doing so. Some WG members in the meeting room were also in the chat conference room and made comments there in response to comments from remote attendees. We reviewed the agenda and there were no changes requested. Chris Apple gave a brief overview of current WG deliverables status. The requirements document has been published as an RFC LCUP's WG last call concluded and a substantial number of issues were raised. The document editors, the remote WG attendees in this case, are working to resolve the issues. LCUP will go through a second WG Last Call after it is revised. Kurt Zeilenga led a discussion about eventual convergence for LCUP. The current proposal from WG fails to provide eventual convergence of updates made to server at client. Kurt believes that eventual convergence is a strong requirement based on conversations with authors of LCUP. Kurt and colleagues have developed a protocol that they believe does provide convergence, but it is too chatty. Question: can we solve problem and still meet other LCUP Requirements. In particular, can we do it without maintaining session state? The general belief is no. Current LCUP eventual convergence status: we understand the problems and have explored ideas to solve them, but the feeling is that we're not at the end of LCUP effort, we're in the middle. There are still significant engineering issues to be resolved. There was some discussion held during this LCUP topic that is reflected in the chat conference room archive. The discussion that still needs to occur on this topic is largely in the technical details. Chris Apple recommended that the discussion Be moved to the mailing list. Mark Wahl requested that the LCUP authors publish a revised specification before the next IETF meeting. We acknowledged that there have been rumblings of concluding WG. Chris Apple has talked with several people to get perspectives and proposed a path to conclusion of work for WG to consider. The proposal was reviewed by John Strassner and Patrick Faltstrom. The presentation covered the state of various WG deliverables and followed that by a proposal from the co-chairs to proceed with an aim of publishing LCUP as a standards track document and all other documents as either Informational or Experimental depending on the nature of their content. There was some discussion about the usage profile document being more appropriate as an Informational document than Experimental as proposed by the co-chairs. The general feeling of the room was that Informational would be more appropriate for the usage profile document. The proposal also mentions referencing X.500 BAC and/or the recent I-Ds written by Kurt Zeilenga and Steven Legg related to the X.500 administrative model. The WG chairs also proposed that they would request that the LDAP Directorate to review those I-Ds from Kurt and Steven with that context in mind. There was some concern expressed over giving more weight to the recommendations of the LDAP Directorate than the rest of the WG. These concerns were discussed and resolved by the co-chair emphasizing that Kurt Zeilenga was correct in his observation that the LDAP Directorate not receive more weight than the WG members in evaluation of consensus. It was pointed out by Chris Apple that volunteers are willing to continue and/or take over editing documents. The document for which there is no confirmed volunteer for editor is the main LDUP protocol specification. The current editor of that document, Tim Hahn recommended that John McMeeking take over. The co-chairs will approach John about doing this. The co-chair's proposal also indicates a target date for completing all documents by June 2003. Completion in the context of this proposal means the documents are ready to enter WG last call or have already completed WG last call. There was some concern expressed by Ed Reed over the normal use of a WG Last Call in relation to LDUP documents in their present state because he doesn't believe that this could be accomplished by that date. In particular, Ed sees the administrative and access control models as potential deadlocks. Chris Apple replies that we would attempt to use external documents for access control and that the administrative model proposal was on the table in the form of an individually contributed I-D. Mark Wahl asked if there would be more than one vendor who is willing to implement in a way that implementation interoperability can be tested. Chris Apple responded that we don't have a clear answer and that this is the primary reason for suggesting experimental publication for most LDUP documents. Perhaps the best thing is to publish the experiment and let the market decide the answers. Ed Reed then proposed that the documents simply be frozen and published as Experimental. Chris Apple responded that this was more or less what he hopes to accomplish but wants to have a last chance to remove gross inconsistencies before publication. Mark Wahl made an alternate proposal for concluding LDUP by suggesting that the WG consider putting drafts back to individual submission status as was done in LDAPEXT when it was concluding. Chris Apple concluded the meeting by indicating that both the proposal from the co-chairs and the proposal from Mark Wahl be discussed on the mailing list. If consensus can be established on one of the proposals, the co-chairs will take appropriate actions to implement that consensus. For the case of the co-chairs' proposal, this means revising the LDUP WG Charter. For the case of Mark Wahl's proposal, the WG simply concludes after attempting to achieve consensus on a revised LCUP specification and does not attempt to do more work as a chartered IETF group on other LDUP specifications.