2.1.10 LDAP Duplication/Replication/Update Protocols (ldup)

NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-10-16

Chris Apple <capple@dsi-consulting.net>
John Strassner <john.strassner@intelliden.com>
Applications Area Director(s):
Ned Freed <ned.freed@mrochek.com>
Ted Hardie <hardie@qualcomm.com>
Applications Area Advisor:
Ted Hardie <hardie@qualcomm.com>
Mailing Lists:
General Discussion: ietf-ldup@imc.org
To Subscribe: ietf-ldup-request@imc.org
In Body: subscribe
Archive: http://www.imc.org/ietf-ldup/
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. This group was originally chartered to 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.

Recently, the WG established consensus on a change of direction to pursue publication of a standards track protocol for LDAPv3 client synchronization, an experimental LDAPv3 replication protocol, and supporting informational documents. Thus the new work program is largely the same as the original work program with one notable exception, the LDAPv3 replication protocol is intended to be an experimental rather than a standards track protocol.

The WG's approach was 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 were the domain of other working groups. Because the responsible WG failed to achieve consensus on a standard access control model for LDAPv3, the LDUP WG formed a design team to explore the issue of how to address the lack of such a model in the context of LDAPv3 replication. This design team made recommendations to the working group. The working group considered these recommendations and consensus was established on addressing these recommendations in the context of revising other working group deliverables rather than adding new deliverables specific to access control for replication. Largely because of the lack of a standard access control model for LDAPv3, the working group also established consensus on pursuing an experimental or informational publication path for a majority of working group documents formerly intended to become proposed standards.

The new replication architecture supports 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 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 Replica Management

Specifications designed to support 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 A General Usage Profile of the LDAPv3 Replication Architecture, Information Model, Protocol Extensions, and Update Reconciliation Procedures.

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  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.
Done  LDAPv3 Directory Replication Requirements I-D goes to WG Last Call as Informational.
Done  Submit I-D on LDAPv3 Mandatory Replica Management.
Done  Submit I-D on LDAPv3 Replication General Usage Profile
Apr 03  Revise LDAPv3 Replication Information Model I-D
Done  Revise LDAPv3 Client Update Protocol I-D
Done  LDAPv3 Client Update Protocol I-D goes to WG Last Call as Proposed Standard
May 03  Revise LDAPv3 Update Reconciliation Procedures I-D
May 03  Revise LDAPv3 Replication Architecture I-D
Jun 03  LDAPv3 Replication Information Model I-D goes to WG Last Call as Informational
Jun 03  LDAPv3 Replication Architecture I-D goes to WG Last Call as Informational.
Jun 03  Revise LDAPv3 Replication General Usage Profile I-D
Jul 03  Revise LDAPv3 Replication Information Transport Protocol I-D
Jul 03  Revise LDAPv3 Replica Management I-D
Jul 03  Evaluate Deliverables Status
Aug 03  LDAPv3 Replication Information Transport Protocol I-D goes to WG Last Call as Experimental
Aug 03  LDAPv3 Update Reconciliation Procedures I-D goes to WG Last Call as Experimental
Aug 03  LDAPv3 Mandatory Replica Management I-D goes to WG Last Call as Experimental
Sep 03  LDAPv3 Replication General Usage Profile I-D goes to WG Last Call as Informational
  • - draft-ietf-ldup-urp-08.txt
  • - draft-ietf-ldup-model-09.txt
  • - draft-ietf-ldup-infomod-08.txt
  • - draft-ietf-ldup-usage-profile-06.txt
  • - draft-ietf-ldup-lcup-06.txt
  • Request For Comments:
    RFC3384 I LDAPv3 Replication Requirements

    Current Meeting Report

    LDUP WG Meeting Minutes
    TUESDAY, November 11, 2003
    1415-1515 Afternoon Sessions II
    Rochester APP ldup LDAP 
    Duplication/Replication/Update Protocols WG
    Kurt Zeilenga volunteered to take notes for the meeting minutes.
    Chris Apple chaired the meeting and presented the previously circulate 
    meeting agenda. No changes were requested.
    Chris gave a presentation on the general WG status that concluded with a 
    recommendation from the chairs that WG Last Call for various documents 
    should proceed in a sequence consistent with the order listed in the WG 
    Charter. Chris also pointed out that this would likely be the last IETF 
    Meeting at which LDUP has a need to meet face-to-face.
    John McMeeking gave a status update of infomod/mrm/protocol I-Ds. 
    Infomod is ready for WG Last Call. Protocol is close to done. MRM needs 
    some more work.
    Chris Apple noted that the:
    + Editors of Information and Architectural Models have requested that a 
    last call be initiated
    + Editors of General Usage Profile document report being ready for WG Last 
    + Editors of URP indicate that the document is ready for WG Last Call
    Ted Hardie pointed out that some documents seem to be missing from the WG 
    Charter page; Chris Apple replied that they were expired and need to be 
    Chris presented a proposal for managing WG last Call that was 
    discussed. After identifying a few issues related to dependencies and 
    remaining work to Be done on certain documents, the following schedule was 
    settled upon:
    + First Grouping: Information and Architectural Model Documents
      (2 week duration)
    + Second Grouping: URP and Protocol
      (3 week duration)
    + Third Grouping: General Usage Profile and MRM
      (3 week duration)
    The original proposal indicated starting WG Last Call for the first 
    grouping on the first Monday after the IETF Last Call. But it was 
    decided in the meeting that this would happen as soon as possible, but not 
    necessarily on that particular day because John McMeeking noted that there 
    may need to be some changes to infomod. 
    draft-ietf-ldup-infomod-08 might be revised prior to WG Last Call. Chris 
    suggested not deferring the WG Last Call if the changes are minor. No 
    concerns were voiced about this.
    Ted Hardie asked whether the documents should be subject to IETF-wide last 
    call or not. Chris to consider the issue and ask WG (on the mailing list) 
    for input.
    The meeting concluded.