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||  ||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|
Current Meeting Report
0) Agenda Bashing
No additions or changes were made to the agenda.
1) LDAPv3 Replication Requirements
This version represents the WG's first attempt to address IESG feedback and comment. Some list discussion has taken place and appears to be circling in on consensus relative to language to address IESG comments. There are also some off-list discussions that are being resolved with the assistance of the Applications ADs. We expect that this document will be ready to re-submit to the IESG for consideration for publication as an Informational RFC by mid-April.
2) LDAP Client Update Protocol
As of the last WG meeting there were believed to be small, non-contentious issues to be resolved with the document. It became obvious during this WG meeting that there may be a larger number of issues to discuss on the list that previously anticipated based on the number of people who have actually commented on it. Therefore, more list discussion and a revision of the document are expected. Despite this expectation, this document is Still considered to be one of the next documents we will be delivering to the IESG for consideration for publication as an RFC, in this case, as a standards-track document.
3) LDUP Update Reconciliation Procedures
Changes were made to the document based on list discussion. The slides used during the meeting by the document editor show the details - these slides will be submitted for inclusion in the Proceedings as well as to the WG mailing list. There are still some issues to resolve relative to synchronizing this document with the content of the LDAP Replication Architecture document.
4) LDAP Replication Architecture
This revision resulted from a major overhaul of the prior version to bring its content into convergence with other WG documents and list discussion.
Specific changes are documented in slides used by the document editor presenting at the WG meeting. These slides will be submitted for the IETF proceedings and also will be posted to the WG mailing list. When the question about this document being ready for WG Last Call was raised, the room generally indicated that more time on the mailing list would be appropriate. One particular issue on which the architecture document is dependent is the selection or specification of an administrative model for replication by the WG.
5) LDUP Replication Information Model
This document is in a holding pattern, so to speak. The issue of selecting an administrative model for replication should be resolved before its revised.
6) LDAP Subentry Schema
This document has been withdrawn from WG consideration. A similar WG deliverable may or may not be needed depending on WG consensus relative to the selection or specification of an administrative model for replication. The question was raised about the X.500 administrative model being sufficient for the needs of LDAPv3 replication. This particular way of resolving the administrative model issue will be considered by the WG along with other options
7) The LDUP Replication Update Protocol
Not revised prior to the WG meeting. It is expected to enter WG Last Call along with the URP document. A revision of this document may be needed once the URP document is believed to be stable enough to enter WG Last Call.
8) General Usage Profile for LDAPv3 Replication
Not revised prior to the WG meeting. This document is expected to be the last to mature of all WG documents because it is a profile of how to make use of all other specifications.
9) Profile for Framing LDAPv3 Operations
Not revised prior to the WG meeting. This document has the same issue/dependency as the LDAP Subentry Schema and the LDAP Replication Information Model documents. an administrative model needs to be selected or specified by the WG before there is any utility in either revising it or adopting one or more individual contributions to take its place.
10) Mandatory LDAP Replica Management
This document has been significantly fleshed out since the last WG meeting.
There are issues flagged in the document which are known to need WG discussion to stabilize the document's content. The specific issues are documented in slides presented during the WG meeting. These slides will be submitted for inclusion in the IETF proceedings as well as be posted to the WG mailing list.
11) LDUP Access Control Design Team
The co-chair present at the WG meeting presented a status report on the recently formed LDUP Access Control Design Team. Specifically, a terse mission statement and proposed team work plan was presented to the WG. There were some concerns expressed about the lack of any obvious status reports into the WG being included explicitly in the work plan. There were also concerns raised about how far the proposed work plan goes down the path of allowing for the possibility of the current design team members actually creating specifications for access control in the context of LDAPv3 replication. A third area of concern was not having the design team membership included in the document presented during the WG meeting. The co-chair agreed to do the following to help alleviate these concerns:
i) revise the design team's work plan to include explicit status reports and inputs to the WG
ii) add a list of design team member names with e-mail addresses to the work plan
iii) post the resulting document to the WG mailing list for further discussion
12) WG Charter Bashing
The room consensus was that the WG charter needs to be revised to address:
+ actual versus anticipated publication of revisions to WG documents
+ the formation of the LDUP Access Control Design Team
+ the current dependency of the WG charter on the Access Control deliverables of the soon-to-conclude LDAPEXT WG
+ the LDAPv3 framing/grouping concept
+ an administrative model for replication
+ replication-relevant access control input from the LDUP Access Control Design Team
During this discussion topic, the WG room was polled for likelihood of attendance by WG participants and document editors of an LDUP meeting in Japan. Only one document editor raised their hand indicating that they were planning to be at the next IETF meeting in Japan. Therefore, unless list consensus indicates that there is value in scheduling a session at the next IETF meeting, the LDUP WG will defer meeting until the Fall IETF meeting in Atlanta, GA.
LDAP Replication Architecture
Changes to URP Document 'draft-ietf-ldup-urp-06'
Mandatory Replica Management