NOTE: This charter is a snapshot of the 48th IETF Meeting in Pittsburgh, Pennsylvania. It may now be out-of-date. Last Modified: 17-Jul-00
Chair(s):
Chris Apple <capple@att.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. Six 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 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
The LDUP WG Chairs will assign to one or two persons to be official LDUP WG liasons to ITU, to monitor X.500 replication work in ITU, and to coordinate the work of the LDUP WG with similar work in ITU.
Goals and Milestones:
Nov 98 |
|
Submit I-D on LDAPv3 Directory Replication Requirements. |
Nov 98 |
|
Submit Internet-Draft on LDAPv3 Replication Information Model |
Feb 99 |
|
Submit I-D on LDAPv3 Update Reconciliation Procedures. |
Feb 99 |
|
Revise I-D on LDAPv3 Directory Replication Requirements. |
Apr 99 |
|
Revise I-D on LDAPv3 Replication Architecture. |
Aug 99 |
|
Revise I-D on LDAPv3 Replication Architecture. |
Aug 99 |
|
Submit I-D on LDAPv3 Mandatory Replica Management. |
Aug 99 |
|
Submit I-D on LDAPv3 Replication Information Transport Protocol. |
Aug 99 |
|
Revise I-D on LDAPv3 Replication Information Model. |
Sep 99 |
|
LDAPv3 Directory Replication Requirements I-D goes to WG Last Call as Informational. |
Sep 99 |
|
Submit I-D on LDAPv3 Multi-Master Replication Profile. |
Sep 99 |
|
Submit I-D on LDAPv3 Master-Slave Replication Profile.Submit I-D on LDAPv3 Master-Slave Replication Profile. |
Nov 99 |
|
LDAPv3 Replication Information Model I-D goes to WG Last Call as Proposed Standard. |
Nov 99 |
|
LDAPv3 Replication Architecture I-D goes to WG Last Call as Informational. |
Nov 99 |
|
LDAPv3 Update Reconciliation Procedures I-D goes to WG Last Call as Proposed Standard. |
Nov 99 |
|
LDAPv3 Replication Information Transport Protocol I-D goes to WG Last Call as Proposed Standard. |
Mar 00 |
|
LDAPv3 Mandatory Replica Management I-D goes to WG Last Call as Proposed Standard. |
Mar 00 |
|
LDAPv3 Master-Slave Replication Profile I-D goes t WG Last Call as Proposed Standard. |
Mar 00 |
|
LDAPv3 Multi-Master Replication Profile I-D goes to WG Last Call as Proposed Standard. |
Internet-Drafts:
· LDUP Update Reconciliation Procedures
· LDAP Replication Architecture
· LDUP Replication Information Model
No Request For Comments
LDUP WG Meeting, Wednesday August 1, 2000
Meeting minutes recorded by John Strassner
0. Agenda discussed, and no changes were made.
1. "LDAP Replication Requirements"
http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica-req-03.txt
Editor(s): Russ Weiser, Ellen Stokes
This is an expired draft and needs to be republished in order for us to proceed with work on it. By republishing, we mean that the document must be published, with no changes other than an updated revision number. This is necessary so that we can refer to it in the upcoming discussions. This will be done this week
Action: republishing to be done this week; see item 12 below.
2. "LDUP Update Reconciliation Procedures"
http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-03.txt
Editor(s): Steven Legg, A Payne
This draft has undergone a minor revision, having been updated to include the correct use of MUST and MAY as well as a clarification resulting from the discussion with Albert Langer. In addition, the References and Security Considerations sections have also been updated.
In summary, it is ready to go to last call, but can't until the requirements document is updated to reflect the discussions with Albert Langer.
Action: none, pending resolution of requirements draft - see item 12
3. "LDAP Replication Architecture"
http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-04.txt
Editor(s): Ed Reed, U. Srinivasan, John Merrells
There were open comments from the mailing list regarding references in this draft to other drafts. We had a synchronization problem with these other drafts, as these normative references were moving and this draft was getting out of sync. This has been corrected, and the normative references removed.
The only remaining open issue in this draft is the relationship between access control and the definition of naming context. In LDUP, the naming context is the unit of replication, but in access control, it is slightly different (administration points are defined differently than naming contexts). Once these changes are made, the document will be ready for last call.
Action: this draft will be revised by the end of September. Depending on the resolution of the issue above, it may be ready for last call then.
4. "LDUP Replication Information Model"
http://www.ietf.org/internet-drafts/draft-ietf-ldup-infomod-01.txt
Editor(s): Ed Reed
No changes in this document as of now. Reference to ITU UUID document was found and will be incorporated. General reconciliation with the architecture document is now necessary. One additional point is that access control information needs to be replicated, but we don't want to deal with inherited ACI yet. This issue needs to be taken to the list.
Actions:
1) Ed to lead discussion on the list regarding how to handle replication of ACI.
2) The next revision of this draft will be published by the end of October.
5. "LDAP Subentry Schema"
http://www.ietf.org/internet-drafts/draft-ietf-ldup-subentry-03.txt
Editor(s): Ed Reed
Basic problem is that the presence of a subentry causes an administrative area to be defined. So the administrative area may not exactly coincide with the naming context. The subentry document needs to be updated to define what is meant by each of these terms. The management of administrative areas, and how this differs (if at all) from the management of naming contexts, needs to be documented.
This challenges us to as to whether replication needs semantic understanding of administrative areas. This seems like a very thorny issue, and it was suggested that we treat this as a version 2 problem in order to make progress with the existing definition of LDUP. This draft will be revised to make scoping of LDUP subentry more clear.
Open issue raised by Kurt is to use a control instead of a filter mechanism to make subentries visible. This issue has been posted to the list.
Action: The next revision of this draft will be published by the end of October.
6. "The LDUP Replication Update Protocol"
http://www.ietf.org/internet-drafts/draft-ietf-ldup-protocol-01.txt
Editor(s): G. Good, E. Stokes
A few open issues have been raised with respect to the signatures of ReplicationStart and other commands. This will cause the document to be revised.
The big problem is whether this document should or should not use framing. This discussion needs to be taken to the list.
Actions:
1) Ellen and/or Gordon to lead discussion on the list as to whether this document should use framing.
2) The next revision of this draft will be published by the end of October.
7. "Extended Operations for Framing LDAP Operations"
http://www.ietf.org/internet-drafts/draft-ietf-ldup-framing-00.txt
Editor(s): G. Good, E. Stokes, Roger Harrison
This work will be subsumed into the grouping operations work being done in LDAPEXT and produce a new framing document (see below).
Action: The authors will meet with Kurt Zeilenga, author of the related "grouping" I-D, to discuss differences and will recommend an approach to combined the two I-Ds to the WG as soon as possible. (status: completed)
Pending WG consensus on above recommendation, an updated draft will be made available by the end of September. The combined I-D will be authored out of the LDUP WG, but will be put under a joint last call (when ready) with LDAPEXT
8. Mark Wahl - Grouping operations
In Adelaide, work was started on taking the existing LDUP framing document (which LBURP was using) and generalizing it so that other operations could use framing.
One possible use of framing was to add transaction support to the directory protocol, but this was decided to be too big to tackle. However, there is interest in the use of framing in other areas (e.g., for the client to request locking on entries, or for certain integrity constraints to be maintained). One of the desired features is to change the referential integrity enforced by a directory server, such that instead of maintaining referential integrity on an operation by operation basis, it instead changes to maintain referential integrity on a set of updates (e.g., enforce it at the end of the operations).
Mark believes that we need extended operations for delimiting beginXX and endXXX operations, and need a document to cover these associated semantics. Note that what is being proposed is that there is a generic way of saying Begin<insert operation here> and End<insert operation here>.
So the framing document needs to be generalized so that everyone can use it. This should be done with a joint last call with LDAPEXT.
Action: Mark and Roger to work on a revised draft, to be out sometime in October.
9. Some deliverables still missing in action...
9a. Mandatory replica management (Ed Reed). Mark has given us a starting draft; Ed will work with others and try and issue this document in September.
9b. Master-slave and multi-master profile documents are behind schedule. Uppilli will take the lead on this work. Since work has stalled, the question was asked, is it beneficial to have profiles that specify how replication works for single-master vs. multi-master.
Actions:
1) Uppilli to lead discussion on the list as to whether we still need separate profiles for (at least) single- vs. multi-master or not.
2) The next revision of this draft will be published by the end of October.
10. Charter Addition for LCUP?
"LDAP Client Update Protocol"
http://www.ietf.org/internet-drafts/draft-natkovich-ldap-lcup-01.txt
Editor(s): O. Natkovich, M. Smith, M. Armijo
The short summary is that LCUP is dirsync, persistent search, triggered search, and LDUP replication. There is an open issues section in the current draft. PLEASE COMMENT!
Room was polled, and a large majority of the room was in favor of adding it (no one was actually opposed). Patrik asked if this would conflict with or hold up existing work, and the answer was no, there was already a dedicated group of people ready to work on this that weren't involved in other work. This question will therefore be taken to the list.
Actions:
1) Co-chairs to poll the list to ensure that no one objects to adding adding LCUP to the LDUP charter.
2) If no one objects, then co-chairs to propose new charter to list; if acceptable to list, then to work with Ads to get our charter officially amended.
11. Other business (besides discussion of Albert's comments): LBURP
We also have an open question of adding LBURP to our charter. This draft has been revised since the last meeting (draft-rharrison-lburp-02.txt).
The changes to the -02 version include adding a new operation, LBURPOperationPartialResponse (note name change from slide). This tells you what operations have succeeded, failed, or are still pending.
Remaining questions - after a brief discussion, it seems like the ability to defer operations should be taken out, as it causes more problems than it solves.
What is the relation between LBURP and the framing document? Roger will try and move this document to keep it in sync with the framing document.
Finally, there wasn't a lot of feedback as to whether LBURP should be added to our charter or not.
Action: co-chairs to pose the question of adding LBURP to the list or not.
12. Discussion of LDUP Requirements Document
Discussion about issues raised by Albert Langer. It was impossible to judge how to proceed, based on the lack of discussion that occurred on the list. So the co-chairs asked for an independent review. This initial work was done by Rick Huber and Ryan Moats. Both will be added as authors of the requirements document as a result of this work.
Summary of Objections to Requirements
The big four points are as follows:
- No requirement for convergence or eventual consistency
- No requirement for atomic operations
- No requirement to support mandatory operational attributes of LDAP
- Definition of updateable replica inconsistent with multi-master replication
Taking these objections in order...
First point: These seem to be covered by requirements 5.2 and 5.7. But, since the draft goes to the trouble of defining 5 different types of consistency. But, since the draft goes to the trouble of defining five different types of consistency, it would be a Good Thing if the requirements were stated in those terms.
Action: Suggest adding a requirement for Eventual Consistency.
Second point: there is a requirement for atomicity in LDAPv3 per RFC2251, section 4.6, and the referenced Tim Howes quote. So the real question is whether this is covered in sections 5.2 and 5.7.
Action: Suggest adding something more specific, as this would avoid any later confusion.
Still on this point, we had an atomicity discussion. Consider the following replication scenario. Servers A, B, and C replicate with each other using multi-master replication. On server A, attributes 1, 2, and 3 of entry E are changed (an atomic operation). On server B, attribute 2 of entry E is changed. Without descending into the religious { ;-) } argument of which method is best, assume for the moment that the change on B has a later time stamp than the change on A.
There are three possible options: discard all changes from A, make changes from A and ignore B, or make change from A and then make change from B.
Note that this is an example of race conditions. If you want to change attribute 2 based upon the value of attribute 1, then since LDAP doesn't have a true read lock, you can't do this. It was argued that LDAP does have a read lock by virtue of doing a delete-add of the same value (which is basically a test and set).
So, what should happen? There are three possibilities:
1. The entire change from A is discarded since it is atomic and was superceded by the change from B.
2. The change from A is made and all attributes reflect the values on A since the change was atomic, and B is deleted.
3. Attributes 1 and 3 reflect the values from A, attribute 2 reflects the value from B.
Note that the third case is what would happen in the single-server or single-master case. In addition, the third choice seems to be the most reasonable choice according to the time-honored Principle of Least Astonishment. ;-) There was overwhelming consensus in the room that this last case was indeed what was expected.
This boils down to the following problem - if a set of requests were submitted as a group, then the replication system should treat them as an atomic group. However, each operation should be processed on its own for conflict resolution (as opposed to the group). Note that the word atomic causes problems. In the example scenario, we want the value to end up with {1, 2', 3}. It was noted that part of the problem is in viewing this as entry-centric, as opposed to being attribute-centric.
Action: this is a good example, summarizing many of Albert's objections, and why it was felt that in this area his objections were not reasonable. It should be included in the new version of the requirements document.
The third point is that there was no requirement to support the mandatory operational requirements of LDAP. Ryan and Rick noted that ModifiersName is a MAY in 2251 and a SHOULD in 2252. This is a Bad Thing, and Mark promised to fix this.
Action: Mark Wahl, please fix this. ;-)
However, it was noted that ModifiersName applies to Entries, not attributes, so it is unclear how this specific example applies. Summary: doesn't affect requirements draft, but does affect LDAPBIS.
Action: Also recommended that Mark Wahl post to the list a set of additional requirements on operational attributes that must be maintained during replication.
Inconsistent Definitions. It was pointed out by Albert that the definition of an updateable replica conflicts with section 5.6.
Action: Change the definition of an updateable replica to:
"An authoritative read-write copy of the replicated information". The room seemed happy with this.
Summary of issues between URP and MDCR, and resulting action items:
1. Atomicity and related concepts
Action: Making some explicit statements about atomicity in the requirements document would clear up this issue.
2. modifiersName and other operational attributes
Action: this point is moot
3. Change reports - Use ProtocolOps or Primitives
Action: no consensus, need further discussion on the list. It was note that we need to include how each addresses (or doesn't address) atomicity.
4. Eventual convergence - Version numbers or timestamps
Action: looks like a religious argument; no consensus reached.
5. Oscillation
The claim has been made that MDCR oscillates. Everyone agrees that oscillation is bad. Needs more discussion on the list.
6. Implementation and performance issues
Action: There have been claims that URP and MCR have comparable performance and implementation requirements. Suggest that we accept this unless someone can prove that this is not true, and prove it quickly.
7. Revocation notices
Action: unclear. MDCR could add them, and they aren't applicable for URP. Suggest dropping this, there are bigger fish to fry.
8. Strong consistency and transactions
Action: LDAP doesn't do transactions, so this is out of scope. As a result of this, co-chairs will update the charter to note that transactions are expicitly out of scope.
None received.