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 and End. 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.