NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01
Chris Apple <christopher.apple@unitedmessaging.com>
John Strassner <john.strassner@intelliden.com>
Ned Freed <ned.freed@mrochek.com>
Patrik Faltstrom <paf@cisco.com>
Patrik Faltstrom <paf@cisco.com>
General Discussion:ietf-ldup@imc.org
To Subscribe: ietf-ldup-request@imc.org
In Body: subscribe
Archive: http://www.imc.org/ietf-ldup/
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.
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 |
· LDUP Update Reconciliation Procedures
· LDAPv3 Replication Requirements
· LDAP Replication Architecture
· LDUP Replication Information Model
The following are the final minutes for the LDUP working group of the 51st meeting of the IETF.
Minutes recorded by John Strassner and Tim Hahn
Meeting time: Tuesday, 7 August, 2001
0a) Review of Proposed Agenda
Patrik wanted to add a statement on the status of the Appeal.
Otherwise, no comments.
0b) IESG Appeal
Patrik Falstrom reported that there has been nothing further with respect to the appeal made just before the last IETF. He also noted that the official IESG response to the appeal had been mosted on the working group. Thus, this issue is now closed.
1) LDAPv3 Replication Requirements
http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica-req-10.txt
This draft passed WG Last Call, and a request has been sent to the Applications Area ADs for IESG Review.
2) LDUP Update Reconciliation Procedures
http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-04.txt
The archive was recently polled to ensure that all open issues have been answered. Since this has been confirmed, this draft will go to working group last call on Monday AFTER the IETF (8/13). The last call will last for approximately 3 weeks.
3) LDAP Replication Architecture
http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-06.txt
Ed Reed reported that no work has been done since the last meeting, due to the requirements document not being finalized. Now that the requirements doc is done, Ed has started going thru the document doing a detailed compliance matrix. This is about 50% done. The focus is to point out where the req document mandates a specific behavior and the arch document differs. This is also being done for the info arch document. PDF to be mailed within 30 days.
4) LDUP Replication Information Model
http://www.ietf.org/internet-drafts/draft-ietf-ldup-infomod-03.txt
Tim Hahn presented an overview of the current status of this draft. The replicaSubEntry and replicaAgreementSubentry object classes were obseleted, and replaced by two new updated object classes (replicaSubEntry2 and replicaAgreementSubentry2). Two new object classes to control scheduling (replicaEventSchedule and replicaTimeSchedule), and their associated attributes, were defined. Also defined where the replication context exists on the server, and defined attributes that must appear in the server's root DSE entry as part of the LDUP information model.
Clarified the notion that the updateVector is a replicated attribute and should be treated as such. Note that it has CSN information for its attribute values. Also introduced the notion that replicaAgreementSubentry2 entries represent constraints to what is, by default, "immediate" replication session initiation.
(The following will be clearer if the reader refers to the powerpoint presentation, slide 5, that is attached in the proceedings).
Attributes in rootDSE (in dark blue oval) are there to define the various replication contexts that exist in the server. There are two replicas on this server with separate replication contexts. There are two replica agreements for each replication context. There are ldapSubEntry derivatives just below the replication contexts that represent information about replication agreements. The default behavior is "fully-connected", "immediate" replication. Note that there is a further constraint of a time schedule for one of the replication agreements. Added attribute replicaSubentries to point to the replica agreements.
Q: Why did you need the second attribute pointing to particular replica subentries?
A: Because there is a replication agreement for each replication context. One attribute specifies which replication area (naming context), other specifies which replica subentry is being used (i.e., which policy is being used).
Q: does that lead to a relational integrity requirement on the administrator?
A: Yes, but it was thought that the benefit outweighed the extra overhead.
Comments that have been received are being incorporated into the next version of the draft. These include:
- OIDs are incorrect (Will be updated in next revision)
- Attrs1 and attrs2 attributes in replicaEventSchedule are too generically named (Will be renamed to attrsForClassX)
- A couple object classes that have been made obsolete were accidentally removed from the draft (Will be fixed in next revision)
Ed Reed then noted that the policy information regarding scheduling and event-driven operations could be more richly defined. Policy is a "rich opportunity". The current draft has only defined a limited set of scheduling capabilities, the limits being limits on the time periods for which replication suppliers would initiate and define replication sessions. The authors haven't defined how a replica would accept such connections. This was because the authors were looking forward to a richer policy language that would be available in the future, and to not preclude the use of such a language. Event-driven includes a default time period for defining replication. Policy-driven includes a ptpCondition from RFC3060 (periodic, not event driven). These would be implemented as a control. ReplicaSubEntry has a Boolean that specifies offline or online - won't start replicating till you turn it on.
The Info model document could be revised in a month - everything is editorial EXCEPT that it also depends on subentries. [editor's note: the fate of subentries will be decided soon].
5) LDAP Subentry Schema
http://www.ietf.org/internet-drafts/draft-ietf-ldup-subentry-08.txt
Ed Reed reported on this work.
Version -8 created after last IETF in Minneapolis. Removed the inheritance model that was in the previous version of the draft and added an administration model which was a subset of X.500, except that it used LDAPSubentries. Autonomous admin area may have specific admin subareas, which may be (but don't have to be) partitioned into smaller areas for specific uses.
There was quite a bit of discussion on subEntries on the list. Ed notes that LDAP subentries were created, consciously, as a subset of the X.500 subentry model. So, why not just use X.500? There are three main reasons.
First, wanted to use name subordination to describe explicit relationships through nested subentries - this approach seemed more elegant than maintaining a set of DNs, and it is easier to maintain referential integrity. X.500 doesn't allow nested subentries today (though this may be relaxed in the future through means such as families of subentries). So without nesting, it would require "dn-pointers" which bring other problems with respect to referential integrity.
Second, naming flexibility - X.500 mandates the use of CN for naming, and some people in the LDAP community want more flexibility.
Third is scooping: purpose of LDAP subentry is to define a profile of X.500. It doesn't allow refinements, and Ed is worried that this is too powerful a tool for too naïve an audience.
This last point leads into refinement. It was thought that the X.500 refinement mechanism may be too powerful a gun to hand to 65,000 MCSEs and NCSEs to use to manage file access (for instance), must less to the managers and secretaries to whom they delegate ACI management to.
The full X.500 administrative model provides DSETypes to mark special entries. The X.500 administrative model also explicitly expects SINGLE master today ...and therefore some invention is required to go with LDAP MULTI-master.
On the other hand, if X.500 subentries -> DSETypes, and DSETypes -> DSP (chaining), and DSP -> multimaster DISP, and multimaster DISP -> interoperable HOB, then maybe a converged X.500/LDUP is the distributed directory service that is needed.
There are two obvious alternatives:
- just do X.500, which implies that we form a new workgroup to achieve X.500/LDAP/LDUP convergence
- adopt the useful subset defined in ldapSubEntry work. This means that we should work with the X.500 group to converge on nesting, and decide whether CN (or some other attribute) should be used naming
Kurt: in order to split some issues apart to effectively manage, you need SOME sort of "refinement mechanism" - without it, you can't do delegation and coalescing of policy information. Requirements for access controls also seem to require a "refinement mechanism".
Ed: Disagrees. For example, Novell and Microsoft don't do this.
Kurt: Then it isn't compliant with 2820. In addition, if access control chooses another mechanism, then this would be bad. Kurt volunteers to define an alternate approach.
Mark Wahl: RFC 2251 does not REQUIRE you to implement X.500 subentries/refinement. The use of CN is a bad thing for applications that want to automatically create these things without collision. Why not choose some "subset" of the refinement in the X.500 subentry refinement capability?
Ed: we did - the "NULL" refinement implies the "whole subtree until the next subentry"
LOTS of discussion on this item, but no concensus was raised. Therefore, this discussion will be taken to the list. John and Chris will arrange a meeting with the LDAPext and LDAPbis co-chairs to mutually discuss what should be done regading LDUP subentires. The implication to this (the infomod) document is that ALL replication agreement infomration would have to be under a single "root entry" (i.e. peers) and delimited by (perhaps) names of the subentries.
This boils down to:
- allow nesting - X.500 shouldn't have a problem
- allow other naming besides cn - X.500 shouldn't have a problem
- not have refinement - X.500 probably would NOT like this ... and thus LDAP would diverge from X.500 ... and this is not good
Skip Sloan (X.500 rep) indicated that X.500 would be amenable to adding nesting and non-cn naming
Action: co-chairs will respond to the list after the minutes.
Need to talk with other co-chairs about an overall strategy.
6) General Usage Profile for LDAPv3 Replication
http://www.ietf.org/internet-drafts/draft-ietf-ldup-usage-profile-01.txt
<no editors present>
Steven: what is the document actually trying to accomplish? It doesn't seem to address how LDUP is used. It instead seems to describe some of the operating characteristics/concerns when using replication. It should instead show what/how replication SHOULD be used/set up. Example: if someone's implementation does not support unordered changes, then they haven't implemented URP and aren't using the replication architecture.
Kurt: thought that this was supposed to be an applicability statement to define the minimum requirements needed to support LDUP. This document clearly doesn't do this (in fact, it is informational). So where is the applicability statement, we need one.
Chris: this seems to be correct, this info will be taken back to the authors. You should post these comments to the list also.
7) LDAP Client Update Protocol
http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-01.txt
Mark Wahl reported on behalf of the authors that the LCUP changes from -00 to -01 consisted of adding an OID to specify the algorithm for making the cookie. Also added an operational attribute to specify the supported algorithms.
Kurt: can this document define A cookie format, leaving it open to allow other drafts to create OTHER cookie formats - and then let this workgroup attempt to limit the set of cookie formats defined.
Roger Harrison - sounds like we're starting to try to allow potentially more than one server to be able to interpret a single cookie instance ... and this is not the intent.
Rick recommends that we declare this explicitly OUT of scope
Jim Sermersheim: there is some language implying that re-connection (to some other server possibly) and re-start/re-use of the cookie is supported
Kurt: we need to narrow the focus of what LCUP specification does; maybe explicitly add that the cookie is NOT reusable to a different server
One technical comment: why isn't the list of supported cookies in the RootDSE. It seems reasonable to make this change.
OID issue:
1) don't standardize and hope for the best
2) standardize a minimum subset of OIDs that vendors must support, which gives you interoperability among the OIDs,
3) LCUP cookies don't matter (VLV cookie interoperability).
Kurt: have LCUP specify "a" cookie format, and leave it open for other cookie formats to be specified in the future.
Co-Chairs will have to re-examine the mailing list and make a recommendation.
Some additional concern as to what we allow the cookie to be used for. But first, we need to define the applicability of first, the protocol, and second, the cookie. For example, if it is just one client and one server, then you wouldn't need to define the format of the cookie at all. On the other hand, if you want to share the cookie between servers, that's a completely different case and would probably require the specification of a cookie.
8) Adding LCUP Cookie Scheme(s) to LDUP WG Charter as Deliverables?
The discussion of this item was merged with item 7).
9) LDAP Access Control Model Work
The focus of this agenda item was to ferret out any concerns that people had on the ACM work to ensure that these would not affect LDUP.
It was noted that the model document does not define how access control will work in a replicated environment. The LDUP general usage profile document is a good job of indicating lots of things (besides access control) that are affected when replication is added to the environment.
Open question to group by Chris Apple with respect to what outstanding problems people have with the access control model and replication?
Kurt: model document still lists access control as not defined how access control works in a replicated environment. There is a need for LDUP folks to read and comment on the current ACL model draft.
10) Definition of an object class to hold LDAP change records
Mark Wahl reported that this draft by Ludwic describes the old changelog format. It is useful in some of the previous sync tools, such as persistent and triggered search, that have now been folded into LCUP. This document is not suitable for a server that is doing LDUP with multi-master. However, if you are doing LCUP or another constrained environment, it is useful.
It was proposed that this should be progressed as an INFORMATIONAL RFC. LDUPers are encouraged to comment on it.
10) General Charter Review
The following updates can be made to the charter:
- update the repl reqs to WG last call date
- update reconciliation procedures to WG last call to be August
- update the multi-master replication profile, master-slave replication profile are by the same authors as general usage profile - so need a new date for all or drop them
- information model: +30 days from decision on ldapSubEntry (i.e., if ldapSubEntry stays, then this document will be submitted in 30 days from that decision; otherwise, a new approach and date will be defined)
- architecture: +30 days from information model
- LDAP mandatory replica management draft "up in the air" - need to get current status from Ryan Moats
- LDAP update replication protocol to be published +30 days from now (8/7/2001)
- LDAP Extended Ops for Framing can go to WG last call, though it is co-dependent on Kurt Zelienga's grouping I-D, so they will be last called together within 30 days from now
- LCUP I-D to WG last call no later than December 2001
The time left in the meeting was spent on discussing how to better align with X.500.
Chris Harding (from The Open Group) stated that many customer requirements are requesting alignment between X.500 and LDAP. How's it going to happen?
Ed: it is time and appropriate for the LDAP community to reciprocate with what the X.500 team has started, i.e. LDAP alignment. One thing to help interoperability - where solutions were created that are aligned closely with X.500 solutions - we shouldn't create new ones.
Skip Sloan - common solutions are good - but where not practical, proper subsets are preferable. Where not possible, please advise Skip that a difference exists and LDAP has gone "above" X.500.
Ed Reed and Kurt Zelienga recommended NOT making this a part of