2.1.8 LDAP Duplication/Replication/Update Protocols (ldup)

NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01

Chair(s):

Chris Apple <cwa29@aol.com>
John Strassner <johns@cisco.com>

Applications Area Director(s):

Ned Freed <ned.freed@innosoft.com>
Patrik Faltstrom <paf@cisco.com>

Applications Area Advisor:

Patrik Faltstrom <paf@cisco.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. 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

Internet-Drafts:
No Request For Comments

Current Meeting Report

FINAL Summary and Meeting Minutes LDUP Working Group Meeting 50th IETF, Minneapolis Minutes recorded by John Strassner, March 19, 2000

The agenda was presented by John, and no adjustments were made.

Discussion of Changes Made to Requirements I-D
draft-ietf-ldup-replica-req-07

The discussion was led by one of the co-authors, Rick Huber.

A summary of the changes made in response to Last Call comments was presented. The key points are as follows:

- interoperability paragraph was rewritten and clarified
- replaced the term "naming context" with the term "replication base entry"
- replaced the term "replica ring" with the term "replica group"
- deprecated the term "updateable replicas"
- clarified model 1 and multi-master atomicity
- requirements G9-G11 were added to cover what needs to be replicated at the attribute level
- M3 was reworded for clarity
- requirement P2 was split into two requirements, P2 and P3, and all subsequent P requirements were renumbered
- moved (the old) P7 to G8 since it is not limited to protocol
- rewrote P6 (now P7) to explicitly require propagation of atomicity of LDAP operations as defined in 2251
- explicitly noted (ongoing) ACL work in the security section
- made text in section A.10 self-consistent
- changed text in B.5.5 to clarify the term "at the same time"

Questions:
-Ellen asked about other documents that need to be brought in line. Will be tabled until later in the meeting
-A question of why "updateable replica" was deprecated. It comes from Kurt's mail.
-Point that P7 moving to G8 makes G2 and G8 copies of each other; authors to address this in the next revision of the requirements draft

Rich then presented items that were deferred. The key points were:

- external locking will be addressed in the profiles I-D
- clarified that the term "area of replication" is equivalent to X.525's term "replicated area"

Question:
-Point about "area of replication" and X.525 "replicated area" brought the comment from Ed that the only requirement for LDUP is to define the contiguous sub-tree. Kurt wants a note that LDUP protocol may define it own administrative model. Request that the area of replication is a subset of X.500 and that the administrative model...authors seemed to agree

Next steps:

The authors will issue a new draft (-08) ASAP and are requesting another WG last call. John urged all members to *please* get their comments in this week or as soon as the document was issued so that the authors would have time to address any additional comments before doing another last call.

Kurt wanted to know if this is really necessary? John responded yes, because technical changes have been made. John asked the meeting participants if anyone had any objections to the requirements draft going to last call, and there were no objections. Kurt said that he would look at the security section.

================================================

Discussion of Usage Profile I-D
draft-ietf-ldup-usage-profile-00.txt

The discussion was led by Rick Huber, one of the co-authors of the draft.

Rick gave an overview of the -00 draft. Its scope is to discuss the design and development issues that may arise due to using replication in directory deployments. The document will discuss both single- and multi-master scenarios. The authors encourage any application-specific profiles to be added.

Next steps would be to add a discussion of external locking from the requirements draft, and to discuss different ways to preserve atomicity across replication.

The authors wanted to know whether the target track for this draft should be informational or BCP. The sense of the room was that this should be an informational track document, as there isn't a set of standards from which to recommend best current practices.

John noted that this draft contains multi-master and master-slave profiles, so the charter needs correction. John further noted that this is a working, living draft, and not ready for last call any time soon. John urged everyone to read the draft and submit comments asap, in order to help the authors develop the next version of the draft.

===========================================================

Discussion of Changes Made to Architecture Document
draft-ietf-ldup-model-06.txt

This discussion was led by Ed Reed, one of the authors of the draft. The authors think that it is ready for WG Last Call. This version is based largely on the comments made by Tim Hahn. The discussion of policy inheritance was removed from the document and placed into a new I-D. The one outstanding item that the authors know needs to be removed is to drop a reference to search filter visibility of subentries.

Question from the floor - how well does this version correlate with the requirements document? A lengthy discussion then ensued. However, one of the major questions that arose was, what happened with operations that cross replication boundaries? How should they be handled?

The answer lies in the direction of a distributed directory, but LDAP doesn't yet have a truly distributed model. LDAP Subentry can help. Problem with deleting superiors that have subordinate reference - you either delete the subordinate, move it to Lost+Found, or say that the operation is not allowed because it has children. But this last option is NOT currently in LDAP.

More general question is, how do you take two portions of the namespace, where the superior and the subordinate are in different partitions? Note that you have DSE types - the object is in one management plane and the subordinate is in another management plane (note that LDAP doesn't have DSEs). We need to look at the namedref document.

Both LDAPext and LDUP have a stake in how this comes out. In an LDAP environment, this is an issue that crops up regardless of whether there is replication.

Since this appears to be a significant design issue, John called for a group of volunteers to form a design team to study and resolve this problem. The volunteers were:

John McMeeking
Mark Smith
Mark Wahl
Skip Sloane
Steve Mclane
Kurt Zeilenga
Ed Reed

This design team's first meeting is tomorrow at 3pm. They will report back to the LDUP WG. Their feedback will then be incorporated into the draft.

======================================================

Discussion on URP - ready for Last Call or not?
draft-ietf-ldup-urp-03.txt

Unfortunately, neither of the authors could attend this meeting due to work and illness. John relayed this information.

With respect to the draft, it has timed out, and needs to be reissued. Note that it should be compared against the requirements draft, and nothing will happen until the requirements doc passes WG Last Call.

=======================================================

Discussion on the LDUP Replication Update Protocol
draft-ietf-ldup-protocol-02.txt

The discussion was led by Ellen Stokes, one of the authors of the draft.

This draft has timed out and needs to be reissued. Ellen suggested a hard deadline of Friday the 13th [ed: honest! ;-) ] of April due for an update due to a hard vacation deadline; Roger Harrison to give Ellen an update tomorrow. This document **appears** to be ready for Last Call - only minor comments were posted in the last revision. Poll of room - no negative comments, Roger thinks that it probably is ready as he has been through the document.

==========================================

Discussion on LDUP Subentry Schema
draft-ietf-ldup-subentry-07.txt

This discussion was led by Ed Reed, one of the authors of the draft. Note that this is a product of both the LDUP and the LDAPext WGs.

Issued version 7. Main changes included separating the inheritance discussion, and put that in a separate document (draft-reed-ldup-inheritance-00.txt). Removed the search-filter mechanism for visibility. The search operation behaves as though the visibility control is present, even though it isn't. In other words, it doesn't make any sense if you have used an LDAP Subentry as the base object of the search, and you didn't include the control to return the results of the search. Kurt pointed out that since these may be nested, and if the base object of the search is a subentry, then you should behave as if the control is present. Ed agreed.

A discussion followed clarifying other operations. It was agreed that if the control is present and true, all you get is subentries, otherwise you do not get subentries. Kurt and Ed will recheck the draft one last time to be sure that this (and the above) behavior is specified this way in the draft.

Ed agreed to add the description of an administrative area, and then state that you can't replicate either a rootDSE or any subentries of the rootDSE.

The purpose of InheritableLDAPSubentry was to provide an example of how to add inheritance to policy. After a short discussion, it was agreed in the room that it would be best to remove this from the draft.

======================================================

Discussion of Policy Inheritance Mechanisms for LDAP
draft-reed-ldup-inheritance-00.txt

Ed made a short presentation Ed said that he would make these changes and try and publish the document asap. Ed further stated that he will actively look for an author to take up the inheritance work, because otherwise he will let it die.

===============================================

Discussion on LDAP Client Update Protocol
draft-natkovich-ldap-lcup-02.txt

(Chair note: please resubmit this draft with as a wg draft (i.e.,draft-ietf-ldup-lcup-00.txt)

This discussion was led by Mark Smith, one of the authors of the draft.

Rich Megginson has taken over editing. It has been reviewed by the authors. No substantial changes, but a fair amount of clarifying text. Note that this is not really a -00, as there were several versions of persistent and triggered search, and lcup as an individual submission.

Still some open issues in the document, so we need to decide as a group whether to punt because they are out of scope or not.

It was noted that LCUP is replacing triggered search, persistent search, and dirSync.

======================================================

Discussion of other missing drafts

John McMeeking and Ryan have offered to take up the Mandatory Replica Management draft. Tim Hahn has offered to take up the Infomod draft.

======================================================

Any other business

It has become apparent that, after listening to the discussions on progress of the various drafts, that two things are missing. They are:

- we need common naming and terminology applied to all drafts
- we need someone to compare the requirements document to the other drafts

John suggested that the co-chairs perform this policing (volunteers are solicited and welcome!). Draft authors can't really review the drafts for these points, as they already should be doing this, and we need independent people doing this review.

End of meeting.

Slides

Agenda
'draft-ietf-ldup-model-06'
General Usage Profiles Draft
LDUP Requirements Draft
LDAP Subentries