Current Meeting Report
Jabber Logs

2.1.10 LDAP Duplication/Replication/Update Protocols (ldup)

NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 06/07/2002

Chris Apple <>
John Strassner <>
Applications Area Director(s):
Ned Freed <>
Patrik Faltstrom <>
Applications Area Advisor:
Patrik Faltstrom <>
Mailing Lists:
General Discussion:
To Subscribe:
In Body: subscribe
Description of Working Group:
As LDAPv3 becomes more widely deployed, replication of data across servers running different implementations becomes an important part of providing a distributed directory service. However, the LDAPv3 community, to date, has focused on standardizing the client-server access protocol. Therefore, this group will standardize master-slave and multi-master LDAPv3 replication as defined below:

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.

Goals and Milestones:
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
  • - draft-ietf-ldup-urp-06.txt
  • - draft-ietf-ldup-replica-req-12.txt
  • - draft-ietf-ldup-model-07.txt
  • - draft-ietf-ldup-usage-profile-03.txt
  • - draft-ietf-ldup-lcup-03.txt
  • - draft-ietf-ldup-mrm-01.txt
  • No Request For Comments

    Current Meeting Report

    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 
    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 
    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.