Current Meeting Report

2.1.7 LDAP Duplication/Replication/Update Protocols (ldup)

NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It may now be out-of-date. Last Modified: 04-Dec-01
Chris Apple <>
John Strassner <>
Applications Area Director(s):
Ned Freed <>
Patrik Faltstrom <>
Applications Area Advisor:
Patrik Faltstrom <>
Mailing Lists:
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   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.
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
No Request For Comments

Current Meeting Report

LDAP Duplication/Replication/Update Protocols WG (ldup)

Thursday, December 13 at 1530-1730

CHAIRS: Chris Apple <>
John Strassner <>

0) Agenda Bashing

No changes were made to the agenda.

1) LDUP Update Reconciliation Procedures

A new version was issued several weeks prior to the WG Meeting.

Specific changes to the document are listed at the end of the draft. Some editorial changes were made. Other changes to be made in a future document revision will include the addition of other reference documents.

2) LDAPv3 Replication Requirements

This document has passed WG Last Call. Comments recently posted to the list after the conclusion of the WG Last Call period will be handled as a part of IETF Last Call. Co-Chairs have an action item to follow up with the Applications Area ADs to find out when the document will be included in the IESG queue for consideration.

3) LDAP Replication Architecture

A requirements coverage matrix has been posted to the WG mailing list.

This posting indicates that the architecture model document lags other WG documents somewhat and needs to be revised. Some requirements are defined in the requirements document that the architecture document doesn't address.

Requirements related to state-based systems are not covered. Log-based replication requirements are not adequately addressed.

It was pointed out by Ed Reed that this requirements coverage matrix will also help to identify holes in information model document.

4) LDUP Replication Information Model

A new revision was submitted shortly before the IETF meeting deadline. No comments on this document revision had been posted to the list as of the WG meeting date. Slides were presented covering the changes made to the document. These slides have been posted to the WG mailing list.

5) LDAP Subentry Schema

Discussion via e-mail between the document editors and Kurt Zeilenga have led to WG consensus that the original proposal in this document should not be used. An individual alternative was published by Kurt Zeilenga. The document will be considered by the WG as a proposal on the list. The X.500 committee has agreed to consider changes to the X.500 subentry specification to foster compatibility between LDAP and X.500 provided that we publish rationale and requirements for their consideration. There was some discussion about adoption of the individual proposal from Kurt Zeilenga as a WG deliverable that would replace the existing WG deliverable. This discussion was deferred until such time as the next WG Charter revision proposal is posted to the WG mailing list.

6) The LDUP Replication Update Protocol

A revision was submitted shortly before the IETF meeting deadline. Several changes were made since the -02 version. These changes are documented in slides that were posted to the WG mailing list. It is likely that this document will need to be revised at least once more prior to considering WG Last Call.

7) General Usage Profile for LDAPv3 Replication

The document editors were unable to attend the WG meeting but submitted a slide to the Co-Chairs for presentation at the meeting. This slide was posted to the mailing list. It is likely that this document will need to be revised again after several other WG documents have been revised.

8) LDAP Client Update Protocol

Based on mailing list discussion, this document is close to being ready for WG Last Call. The changes made to the document since the -01 revision are included in the document. There is one major issue that requires more mailing list discussion. The issue is whether or not a discovery mechanism enabling client/server implementations to determine what cookie schemes are supported may be overkill. There was some general agreement in the room that this might indeed be overkill and that it should be discussed on the WG mailing list. Once this issue is resolved by the WG, the document should be ready for WG Last Call.

9) Profile for Framing LDAPv3 Operations

There was discussion about the possibility of relaxing the framing constraints on LDAPv3 operations in the context of LDUP. Appropriate text from this document should be included in a revised grouping document. The Co-Chair requested that this topic be aired on the list a bit more as there were concerns about having a WG document subsumed by a non-WG document without adopting the subsequent document as a WG deliverable. This topic will be discussed further once a post-Salt Lake City WG charter proposal is posted to the list.

10) Mandatory LDAP Replica Management

This document was published by the editors as a very rough draft. The Co-Chairs encouraged members of the WG to review this document with this in mind.

Kurt Zeilenga asked if the word mandatory in the title carried its traditional weight as it does when included in requirements language in the body of a document. The general answer given by the Co-Chairs was "not quite" but agreed that the WG should consider an alternate title for the document to clear up confusion if it indeed shouldn't carry its traditional weight.

11) LDAPv3 Access Control - Options to Consider

a) Adding it to LDUP?
b) Forming a WG Solely to Address Access Control for LDAPv3?
c) Handling the Access Control problem by (potentially competing) individual contributions?
d) Do nothing and let the work go on outside of the IETF?
e) Other options?

Discussion about this topic indicates that it is generally accepted that LDUP will not have successfully concluded if it publishes deliverables which do not support and actively address interoperable, secure replication of information between LDAP servers. Room belief is that it belongs in a WG. The pending conclusion of the LDAPEXT WG prior to completion of the LDAP Access Control Model work creates an issue that the LDUP WG needs to resolve. When the questions above were posed to the WG members in attendance, they clearly expressed a belief that a general LDAP Access Control model should not become an LDUP deliverable. However, there was also a strong belief among those in attendance that such work does belong in a working group.

After much discussion of possible paths to successful WG conclusion, it was proposed that concensus on an access control model applicable only within the context of LDUP specifications might be achieved by using X.500 basic or a profile thereof - or some even simpler proposal.

An Engineering Team needs to be convened to draft a list of the minimally required factors needed in an access control model for LDUP.

It was pointed out by Kurt Zeilenga that identity to authentication credential mapping will have to be addressed by any access control model for LDUP implementations to use it effectively.

12) Broader WG Charter Discussion

The most recent WG Charter proposal posted to the WG mailing list will be revised to remove present wording related to LDUP adoption of the LDAPEXT Access Control Model work. This charter content and associated deliverables will be replaced with content consistent with the discussion that took place during the WG meeting.


None received.