From owner-ietf-ldup@mail.imc.org Sun Jun 1 21:45:38 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08493 for ; Sun, 1 Jun 2003 21:45:37 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h521b9AF077835 for ; Sun, 1 Jun 2003 18:37:09 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h521b92M077834 for ietf-ldup-bks; Sun, 1 Jun 2003 18:37:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from tconl91223.tconl.com (tconl91223.tconl.com [204.26.91.223]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h521b4AF077814 for ; Sun, 1 Jun 2003 18:37:04 -0700 (PDT) (envelope-from jayhawk@tconl91223.tconl.com) Received: (from jayhawk@localhost) by tconl91223.tconl.com (8.11.6/8.11.0) id h521aWe01664; Sun, 1 Jun 2003 20:36:32 -0500 Date: Sun, 1 Jun 2003 20:36:32 -0500 From: Ryan Moats To: Chris Apple Cc: "'Kurt D. Zeilenga'" , "'Ramsay, Ron'" , ietf-ldup@imc.org Subject: comments on draft-zeilenga-ldup-sync (was Re: LDAP Client Update: consideration of alternative proposals) Message-ID: <20030601203632.E1461@privateer.local.windrose.omaha.ne.us> Reply-To: rmoats@lemurnetworks.net References: <5.2.0.9.0.20030528213812.0297ebb0@127.0.0.1> <007901c325f8$42a28490$6500a8c0@D7ST2111> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <007901c325f8$42a28490$6500a8c0@D7ST2111>; from capple@dsi-consulting.net on Thu, May 29, 2003 at 11:37:22AM -0400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Well I've re-looked at these both and I've got concerns/questions about each of them. This first piece of mail addresses one process concern (in two parts) and a technical concern that I have about draft-zeilenga-ldup-sync-02: Since the working group decided that replication protocols should be experimental and this document is standards track, I'm uncomfortable with the inclusion of "lightweight master-slave replication" in the possible use list. Kurt has pointed out: | "When I said: | >While Jong and I certainly intend to use LDAP Sync as a basis | >for single-master replication, this I-D does not attempt to | >detail how LDAP Sync might be used for single-master replication. | >(We saved that for a future draft.) | | my point was that specification how a future LDAP Relication | specification might use LDAP Sync is beyond the scope of | draft-zeilenga-ldup-sync as draft-zeilenga-ldup-sync is | intended to be a complete technical specification of the | LDAP Content Sychronization Operation (a LDAPv3 client update | protocol). Jong and I do believe draft-zeilenga-ldup-sync | is complete." This is all well and good, but if a standards track document is going to include "lightweight master-slave replication" as a possible use, then said document should make reference to how it meets or does not meet RFC 3384. I could also live with that possible use being removed and introduced in a self-contained experimental draft. My technical concern is that this draft does not discuss the implications of each client having an open connection to the server. Sockets are one of the more precious OS resources, and so there needs to be an applicability statement about this as well as a discussion of what happens what a server terminates a persistent connection when conserving resources. Ryan From owner-ietf-ldup@mail.imc.org Sun Jun 1 21:57:44 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08994 for ; Sun, 1 Jun 2003 21:57:43 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h521p4AF079217 for ; Sun, 1 Jun 2003 18:51:04 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h521p4pF079216 for ietf-ldup-bks; Sun, 1 Jun 2003 18:51:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from tconl91223.tconl.com (tconl91223.tconl.com [204.26.91.223]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h521p3AF079198 for ; Sun, 1 Jun 2003 18:51:03 -0700 (PDT) (envelope-from jayhawk@tconl91223.tconl.com) Received: (from jayhawk@localhost) by tconl91223.tconl.com (8.11.6/8.11.0) id h521oao01676; Sun, 1 Jun 2003 20:50:36 -0500 Date: Sun, 1 Jun 2003 20:50:36 -0500 From: Ryan Moats To: Chris Apple Cc: "'Kurt D. Zeilenga'" , "'Ramsay, Ron'" , ietf-ldup@imc.org Subject: Re: comments on draft-zeilenga-ldup-sync (was Re: LDAP Client Update: consideration of alternative proposals) Message-ID: <20030601205036.F1461@privateer.local.windrose.omaha.ne.us> Reply-To: rmoats@lemurnetworks.net References: <5.2.0.9.0.20030528213812.0297ebb0@127.0.0.1> <007901c325f8$42a28490$6500a8c0@D7ST2111> <20030601203632.E1461@privateer.local.windrose.omaha.ne.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030601203632.E1461@privateer.local.windrose.omaha.ne.us>; from rmoats@lemurnetworks.net on Sun, Jun 01, 2003 at 08:36:32PM -0500 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Well I've re-looked at these both and I've got concerns/questions about each of them. This second piece of mail addresses one technical/process concern I have with draft-ietf-ldup-lcup-05.txt. There was a suggestion (from me) that the initial backoff period be specified with the lcupResourcesExhausted error. This had some support, but I have never seen a reply on this issue. I still think that having the server specify the initial backoff time (via an additional control) is superior to the current proposed method. Ryan From owner-ietf-ldup@mail.imc.org Mon Jun 2 19:24:51 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29759 for ; Mon, 2 Jun 2003 19:24:50 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h52NEDAF076034 for ; Mon, 2 Jun 2003 16:14:13 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h52NEDK3076033 for ietf-ldup-bks; Mon, 2 Jun 2003 16:14:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h52NEBAF076028 for ; Mon, 2 Jun 2003 16:14:12 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h52NEDc6076870 for ; Mon, 2 Jun 2003 23:14:14 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030602154953.0299fcc8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 02 Jun 2003 16:11:08 -0700 To: ietf-ldup@imc.org From: "Kurt D. Zeilenga" Subject: LCUP show stopper Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: To LCUP, Let us try to describe what we consider to be the primary show-stopping issue in the draft-ietf-ldup-lcup proposal. For convenience, we will refer to this below as LCUP. LCUP expects server implementations to maintain sufficient history so that they provide incremental refreshes of content instead of full reloads on subsequent client requests. For subsequent client request, full reloads should be the exception not the norm. We argue that full reloads will actually be more of the norm, certainly not limited to rare exceptions. As you know, we think it is not reasonable to require servers maintain history information in order to support LCUP. That forces a particular design choice which may be counter to other design factors, such as scalability. However, we will focus our discussions on servers which choose to maintain some amount of historical information. We think LCUP misjudges the completeness of history information that would need to be maintained to avoid reloads in the general case and the complexity of computing the clients state based upon that history (in order to determine what "deletes" need to be sent). Complete history implies that server can compute the client's state and generate the smallest amount of traffic to converge the client's state to server's state based upon the information contained in the cookie. Of course, if we were to assume complete history, we could do much better than sending complete copies of entries. Sufficient history implies that the server is able to determine which entry update and delete messages need to be delivered to the client to converge its state to that of the server. Determining which entries need updating requires no history, the server can simply send all entries presently meeting the search criteria that have been updated since the previous request (based upon time stamps). However, determining which delete messages to send requires history. Minimally, the server needs to a) maintain history about deleted entries and b) track the time each entry was modified and/or renamed, and send a delete message for each entry deleted or modified since the previous content was provided. That is, without additional history, the server has to assume that all deletes, modifications, and renames affected entries to leave the result set. This is problematic as the server has to force a reload as a result of modifications which are not and were not ever of interest to the application. That is, when a client is interested in 100 entries of a 1,000,000 entry context and 10,000 (1%) were modified since the last refresh, the server would have to prove most of these 10,000 entries were not previously in the result set otherwise return an error indicating a full reload was required. This is because 1 update (1% of 100) and 9,999 delete messages are likely far more traffic than 100 full entry messages. Now, a server could maintain additional information about entry renaming. Then it could prove which entries could not possibly be in the search's scope and trim out those "deletes". However, unless it maintained history of entry modifications (and other changes in entry visibility based upon other factors), the server would still have to send deletes for all modified entries which are in scope regardless of whether they currently match the search criteria. That is, without entry modification history, if the scope was subtree covering 10% of the context (as described above), then 9000 of the deletes could be eliminated. The server would still have to send 1 update + 999 deletes. If we assume 1K entry size (common for many directories), that's about the same amount of traffic as required for a full reload. As another example, let's look at two general history maintenance mechanism common in existing servers, tombstones and changelogs. LDAP servers supporting these mechanisms generally do not maintain history of old attribute types and values of modified or deleted entries and, hence, cannot compute after an update operation an entry's previous state. If the server cannot compute the entry's previous state, it cannot generally compute whether that entry was previously in the LCUP result set. It must assume that it was. Hence, even where no or few modified or deleted entries were previously in the result set, the server is forced to either send delete messages for all of these entries or cause a full reload. LCUP does not provide a reasonably efficient solution for the LDAP servers maintaining history information through common practices. The first example was intended to be illustrative of one of many use scenarios. As a general solution to the client update problem, we believe LCUP needs to work well in a wide variety of use scenarios having different characteristics in factors like total number of entries, the amount of changes, the percent of in-scope entries, the percent of entries in the result set and average entry size. The second example was intended to illustrate that history information currently maintained in today's LDAP servers is not "sufficient history" for LCUP purposes. Basically, LCUP requires vendors to maintain "sufficient history" (significantly more than servers currently maintain today for other purposes) when in many use scenarios that history is ineffective in reducing traffic. And in use scenarios where that history might be effective, the protocol doesn't allow the server to fully take advantage of that history (because it doesn't support entry change deltas). It is our opinion that LCUP is generally not more suitable than persistent search solutions it was intended to replace, while coming at a significantly higher implementation cost (the cost of maintaining/using "sufficient history"). After 3 years of LCUP engineering, we don't yet have "running code". Our (Jong and Kurt's) own efforts to develop a LCUP prototype were stopped shortly after we concluded LCUP was unsuitable. We are currently pursuing a technical alternative. Kurt and Jong From owner-ietf-ldup@mail.imc.org Mon Jun 2 20:25:35 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01426 for ; Mon, 2 Jun 2003 20:25:35 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h530IZAF078707 for ; Mon, 2 Jun 2003 17:18:35 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h530IZx8078706 for ietf-ldup-bks; Mon, 2 Jun 2003 17:18:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h530IYAF078701 for ; Mon, 2 Jun 2003 17:18:34 -0700 (PDT) (envelope-from hardie@qualcomm.com) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h530IX6I025491; Mon, 2 Jun 2003 17:18:33 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by crowley.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h530IVix005562; Mon, 2 Jun 2003 17:18:31 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <5.2.0.9.0.20030602154953.0299fcc8@127.0.0.1> References: <5.2.0.9.0.20030602154953.0299fcc8@127.0.0.1> Date: Mon, 2 Jun 2003 17:18:24 -0700 To: "Kurt D. Zeilenga" , ietf-ldup@imc.org From: hardie@qualcomm.com Subject: Is this really an LCUP show stopper? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt, Jong, In the section on applicability, the LCUP draft says: > 1) The server stores some degree of historical state or change > information to reduce the amount of wire traffic required for > incremental synchronizations. The optimal balance between server > state and wire traffic varies amongst implementations and usage > scenarios, and is therefore left in the hands of implementers. > To me, you seem to be arguing below that the approach (client pull, optimized by some server state) is invalid, when my reading both of the draft and this text would be that this approach allows a wide range of variation in the balance between optimizing wire traffic by increasing server state and optimizing server scale by allowing for profligate returns. While I certainly respect your sense of the difficulty of implementation this might pose to existing clients and servers, I'm not sure how this makes this invalid. It is an engineering balance between two costs, and the protocol allows the balance to shift both ways. If I'm reading this right, you believe the text in 4.2.7 in particular poses a problem: > Servers SHOULD keep > enough information about the attributes in the deleted entries to > determine if an entry should be removed from the result set. Since > this may not be possible, the server MAY return an entry as having > left the result set even if it is not or never was in the client's > result set. Clients MUST ignore these notifications. > Clearly, maintaining this state does add a burden to the server implementation and deployment, and servers which do not maintain state might be compliant but would be sub-optimal for the clients using this protocol. But it also seems clear that this state can be maintained in a variety of conditions, and that the balance can be shifted the other way when it cannot. To me, this looks like another engineering trade-off, not like a show stopper. I appreciate the time and effort you've taken in putting forward this analysis and I think this section: >The second example was intended to illustrate that history information >currently maintained in today's LDAP servers is not "sufficient >history" for LCUP purposes. > >Basically, LCUP requires vendors to maintain "sufficient >history" >(significantly more than servers currently maintain today for other >purposes) when in many use scenarios that history is ineffective >in reducing traffic. And in use scenarios where that history might >be effective, the protocol doesn't allow the server to fully take >advantage of that history (because it doesn't support entry change >deltas). is a good, short precis of your points. I do see an engineering disagreement here on how to balance increases in state for deployed servers vs. the value it presents. I don't see a show stopper, though, as the draft acknowledges the possibility that maintaining state will not be appropriate for all cases and provides other mechanisms for them. That those are sub-optimal from a consumption perspective is not exactly surprising, given the basic design. Given my relative newness to this arena, it is entirely possible that I have missed your point, and I invite your corrections (either privately or on-list). regards, Ted Hardie At 4:11 PM -0700 6/2/03, Kurt D. Zeilenga wrote: >To LCUP, > >Let us try to describe what we consider to be the primary >show-stopping issue in the draft-ietf-ldup-lcup proposal. For >convenience, we will refer to this below as LCUP. > >LCUP expects server implementations to maintain sufficient history >so that they provide incremental refreshes of content instead of >full reloads on subsequent client requests. For subsequent client >request, full reloads should be the exception not the norm. We >argue that full reloads will actually be more of the norm, certainly >not limited to rare exceptions. > >As you know, we think it is not reasonable to require servers >maintain history information in order to support LCUP. That forces >a particular design choice which may be counter to other design >factors, such as scalability. However, we will focus our >discussions on servers which choose to maintain some amount of >historical information. > >We think LCUP misjudges the completeness of history information >that would need to be maintained to avoid reloads in the general >case and the complexity of computing the clients state based upon >that history (in order to determine what "deletes" need to be sent). > >Complete history implies that server can compute the client's state >and generate the smallest amount of traffic to converge the client's >state to server's state based upon the information contained in the >cookie. Of course, if we were to assume complete history, we could >do much better than sending complete copies of entries. > >Sufficient history implies that the server is able to determine >which entry update and delete messages need to be delivered to the >client to converge its state to that of the server. > >Determining which entries need updating requires no history, the >server can simply send all entries presently meeting the search >criteria that have been updated since the previous request (based >upon time stamps). However, determining which delete messages to >send requires history. > >Minimally, the server needs to > a) maintain history about deleted entries and > b) track the time each entry was modified and/or renamed, > >and send a delete message for each entry deleted or modified since >the previous content was provided. That is, without additional >history, the server has to assume that all deletes, modifications, >and renames affected entries to leave the result set. This is >problematic as the server has to force a reload as a result of >modifications which are not and were not ever of interest to the >application. That is, when a client is interested in 100 entries >of a 1,000,000 entry context and 10,000 (1%) were modified since >the last refresh, the server would have to prove most of these >10,000 entries were not previously in the result set otherwise >return an error indicating a full reload was required. This is >because 1 update (1% of 100) and 9,999 delete messages are likely >far more traffic than 100 full entry messages. > >Now, a server could maintain additional information about entry >renaming. Then it could prove which entries could not possibly be >in the search's scope and trim out those "deletes". However, unless >it maintained history of entry modifications (and other changes in >entry visibility based upon other factors), the server would still >have to send deletes for all modified entries which are in scope >regardless of whether they currently match the search criteria. > >That is, without entry modification history, if the scope was subtree >covering 10% of the context (as described above), then 9000 of the >deletes could be eliminated. The server would still have to send >1 update + 999 deletes. If we assume 1K entry size (common for >many directories), that's about the same amount of traffic as >required for a full reload. > >As another example, let's look at two general history maintenance >mechanism common in existing servers, tombstones and changelogs. >LDAP servers supporting these mechanisms generally do not maintain >history of old attribute types and values of modified or deleted >entries and, hence, cannot compute after an update operation an >entry's previous state. If the server cannot compute the entry's >previous state, it cannot generally compute whether that entry was >previously in the LCUP result set. It must assume that it was. >Hence, even where no or few modified or deleted entries were >previously in the result set, the server is forced to either send >delete messages for all of these entries or cause a full reload. >LCUP does not provide a reasonably efficient solution for the >LDAP servers maintaining history information through common >practices. > >The first example was intended to be illustrative of one of many >use scenarios. As a general solution to the client update problem, >we believe LCUP needs to work well in a wide variety of use scenarios >having different characteristics in factors like total number of >entries, the amount of changes, the percent of in-scope entries, >the percent of entries in the result set and average entry size. >The second example was intended to illustrate that history information >currently maintained in today's LDAP servers is not "sufficient >history" for LCUP purposes. > >Basically, LCUP requires vendors to maintain "sufficient >history" >(significantly more than servers currently maintain today for other >purposes) when in many use scenarios that history is ineffective >in reducing traffic. And in use scenarios where that history might >be effective, the protocol doesn't allow the server to fully take >advantage of that history (because it doesn't support entry change >deltas). > >It is our opinion that LCUP is generally not more suitable than >persistent search solutions it was intended to replace, while coming >at a significantly higher implementation cost (the cost of >maintaining/using "sufficient history"). After 3 years of LCUP >engineering, we don't yet have "running code". Our (Jong and Kurt's) >own efforts to develop a LCUP prototype were stopped shortly after >we concluded LCUP was unsuitable. We are currently pursuing a >technical alternative. > >Kurt and Jong From owner-ietf-ldup@mail.imc.org Tue Jun 3 20:32:52 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01311 for ; Tue, 3 Jun 2003 20:32:52 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h540KwAF073222 for ; Tue, 3 Jun 2003 17:23:28 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h540KwFg073221 for ietf-ldup-bks; Tue, 3 Jun 2003 17:20:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h540IMAF073156 for ; Tue, 3 Jun 2003 17:20:52 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h540Hxc6086634; Wed, 4 Jun 2003 00:18:01 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030603164026.02a87568@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 03 Jun 2003 17:15:00 -0700 To: From: "Kurt D. Zeilenga" Subject: RE: LDAP Client Update: consideration of alternative proposals Cc: "'Ramsay, Ron'" , In-Reply-To: <007901c325f8$42a28490$6500a8c0@D7ST2111> References: <5.2.0.9.0.20030528213812.0297ebb0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 08:37 AM 5/29/2003, Chris Apple wrote: >Perhaps one source of difficulty in discussions >related to this topic is that there is not >agreement between yourself and the editors >of LCUP as to how broad a range of applicability >is appropriate for the LCUP deliverable? It's my opinion that LCUP deliverable should be generally applicable to directory applications needing content synchronization facilities. Both drafts seem to have the same applicability in terms of directory applications they apply to, how they differ significantly in the kinds of constraints they place on their implementations. I use the term constraint here instead of requirement to highlight the distinction of fulfilling a need of the directory applications versus of fulfilling a need of the design of a protocol. Our basic application requirement is that protocol provide efficient and effective content synchronization, with modes for polling for changes and listing for changes. Efficient implies a need to manage protocol exchanges to minimize traffic in most cases while generally avoiding "overly" chatty behavior. Effective implies a need for a reasonable level of data consistency. Applications could care less of whether their requirement was met using a history based approach or using state indicators based approach, that's an server implementation detail to them. Hence, draft-ietf-ldup-lcup need for servers to maintain and use history information is not an application requirement but a design constraint. I consider the draft-ietf-ldup-lcup's history design constraint unreasonable. This constraint certainly will will have an impact on its wide adoption as a technical solution to the general problem. Kurt From owner-ietf-ldup@mail.imc.org Tue Jun 3 23:09:58 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05305 for ; Tue, 3 Jun 2003 23:09:58 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h542uLAF078020 for ; Tue, 3 Jun 2003 19:58:51 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h542uLYr078018 for ietf-ldup-bks; Tue, 3 Jun 2003 19:56:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from REED (smtp.oncalldba.com [24.97.89.25]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h542rnAF077944 for ; Tue, 3 Jun 2003 19:56:19 -0700 (PDT) (envelope-from eer@OnCallDBA.COM) Received: from RMINC_DOM-MTA by REED with Novell_GroupWise; Tue, 03 Jun 2003 22:55:58 -0400 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Tue, 03 Jun 2003 22:55:36 -0400 From: "Ed Reed" To: , Cc: , Subject: RE: LDAP Client Update: consideration of alternative proposals Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Irony is having someone else argue for state-based synchronization approaches after going so long with LDUP in which no one was interested in them. As I recall, some of us thought the implementation choice of the backend didn't matter to the consumers of the protocol, until we ran into all the various ordering constraints necessary to deal with partial transfers of changes (necessary in the absence of commit/rollback semantics, if you want to avoid retransmission of already sent changes). I'm glad I'm not the one trying to justify them, this time. >>> "Kurt D. Zeilenga" 6/3/2003 6:15:00 PM >>> At 08:37 AM 5/29/2003, Chris Apple wrote: >Perhaps one source of difficulty in discussions >related to this topic is that there is not >agreement between yourself and the editors >of LCUP as to how broad a range of applicability >is appropriate for the LCUP deliverable? It's my opinion that LCUP deliverable should be generally applicable to directory applications needing content synchronization facilities. Both drafts seem to have the same applicability in terms of directory applications they apply to, how they differ significantly in the kinds of constraints they place on their implementations. I use the term constraint here instead of requirement to highlight the distinction of fulfilling a need of the directory applications versus of fulfilling a need of the design of a protocol. Our basic application requirement is that protocol provide efficient and effective content synchronization, with modes for polling for changes and listing for changes. Efficient implies a need to manage protocol exchanges to minimize traffic in most cases while generally avoiding "overly" chatty behavior. Effective implies a need for a reasonable level of data consistency. Applications could care less of whether their requirement was met using a history based approach or using state indicators based approach, that's an server implementation detail to them. Hence, draft-ietf-ldup-lcup need for servers to maintain and use history information is not an application requirement but a design constraint. I consider the draft-ietf-ldup-lcup's history design constraint unreasonable. This constraint certainly will will have an impact on its wide adoption as a technical solution to the general problem. Kurt From owner-ietf-ldup@mail.imc.org Wed Jun 4 01:14:30 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07300 for ; Wed, 4 Jun 2003 01:14:30 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h54585AF081876 for ; Tue, 3 Jun 2003 22:08:05 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h54585sx081875 for ietf-ldup-bks; Tue, 3 Jun 2003 22:08:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h54584AF081870 for ; Tue, 3 Jun 2003 22:08:04 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h5457wc6088745; Wed, 4 Jun 2003 05:07:58 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030603214303.02b3b928@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 03 Jun 2003 22:04:59 -0700 To: "Ed Reed" From: "Kurt D. Zeilenga" Subject: RE: LDAP Client Update: consideration of alternative proposals Cc: , , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 07:55 PM 6/3/2003, Ed Reed wrote: >Irony is having someone else argue for state-based synchronization >approaches after going so long with LDUP in which no one was >interested in them. Maybe its just those who have implemented state-based synchronization are not interested in LDUP... >As I recall, some of us thought the implementation choice of the >backend didn't matter to the consumers of the protocol, until >we ran into all the various ordering constraints necessary >to deal with partial transfers of changes (necessary in >the absence of commit/rollback semantics, if you want to >avoid retransmission of already sent changes). I recall it being resolved that log-based implementations had like problems dealing with partial replication. Anyways, I think the conclusion of that particular thread was that LDUP should not get into log-based nor state-based implementation details. >I'm glad I'm not the one trying to justify them, this time. I rather not have to justify any particular implementation approach and just leave those to the implementors. LCUP, unlike LDUP, precludes viable implementation approaches. >>>> "Kurt D. Zeilenga" 6/3/2003 6:15:00 PM >>> > >At 08:37 AM 5/29/2003, Chris Apple wrote: >>Perhaps one source of difficulty in discussions >>related to this topic is that there is not >>agreement between yourself and the editors >>of LCUP as to how broad a range of applicability >>is appropriate for the LCUP deliverable? > >It's my opinion that LCUP deliverable should be generally >applicable to directory applications needing content >synchronization facilities. Both drafts seem to have the >same applicability in terms of directory applications they >apply to, how they differ significantly in the kinds of >constraints they place on their implementations. > >I use the term constraint here instead of requirement to >highlight the distinction of fulfilling a need of the >directory applications versus of fulfilling a need of the >design of a protocol. > >Our basic application requirement is that protocol provide >efficient and effective content synchronization, with modes >for polling for changes and listing for changes. Efficient >implies a need to manage protocol exchanges to minimize >traffic in most cases while generally avoiding "overly" >chatty behavior. Effective implies a need for a reasonable >level of data consistency. > >Applications could care less of whether their requirement >was met using a history based approach or using state >indicators based approach, that's an server implementation >detail to them. Hence, draft-ietf-ldup-lcup need for >servers to maintain and use history information is not an >application requirement but a design constraint. > >I consider the draft-ietf-ldup-lcup's history design >constraint unreasonable. This constraint certainly will >will have an impact on its wide adoption as a technical >solution to the general problem. > >Kurt From owner-ietf-ldup@mail.imc.org Wed Jun 4 09:28:59 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18485 for ; Wed, 4 Jun 2003 09:28:58 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h54DMGAF030869 for ; Wed, 4 Jun 2003 06:22:16 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h54DMGaW030868 for ietf-ldup-bks; Wed, 4 Jun 2003 06:22:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h54DMFAF030861 for ; Wed, 4 Jun 2003 06:22:15 -0700 (PDT) (envelope-from jongchoi@us.ibm.com) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h54DM79X109860; Wed, 4 Jun 2003 09:22:07 -0400 Received: from d01ml233.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h54DM6cO080588; Wed, 4 Jun 2003 09:22:06 -0400 To: hardie@qualcomm.com, ietf-ldup@imc.org Cc: "Kurt D. Zeilenga" MIME-Version: 1.0 Subject: Re: Is this really an LCUP show stopper? X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Jonghyuk Choi Date: Wed, 4 Jun 2003 09:22:05 -0400 X-MIMETrack: Serialize by Router on D01ML233/01/M/IBM(Release 6.0.1 [IBM]|May 30, 2003) at 06/04/2003 09:22:06, Serialize complete at 06/04/2003 09:22:06 Content-Type: multipart/alternative; boundary="=_alternative 0049699B85256D3B_=" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0049699B85256D3B_= Content-Type: text/plain; charset="us-ascii" Ted, > To me, you seem to be arguing below that the >approach (client pull, optimized by some server state) is invalid, >when my reading both of the draft and this text would be that this >approach allows a wide range of variation in the balance between >optimizing wire traffic by increasing server state and optimizing >server scale by allowing for profligate returns. While I certainly >respect your sense of the difficulty of implementation this might >pose to existing clients and servers, I'm not sure how this makes >this invalid. It is an engineering balance between two costs, >and the protocol allows the balance to shift both ways. Because even a single omission of delete / modify in history can make it impossible to recreate the previous sync result the cookie of a sync request refers to, it looks more like a matter of how long the full history information is maintained rather than how complete the history information is. That is, as to the completeness of history, it is a binary decision, not a wide range of variations. How long the full history is maintained for sync purpose would give a tradeoff. But it still requires maintaining full history in order to benefit even a small from the tradeoff. It in fact assumes an implementation option and gives tradeoffs only within that option. > is a good, short precis of your points. I do see an engineering >disagreement here on how to balance increases in state for >deployed servers vs. the value it presents. I don't see a show stopper, >though, as the draft acknowledges the possibility that maintaining state >will not be appropriate for all cases and provides other mechanisms for >them. That those are sub-optimal from a consumption perspective >is not exactly surprising, given the basic design. The concern here is that other mechanisms (full reload / sending excessive entries) would be the norm for most cases. Jong ------------------------ Jong Hyuk Choi IBM Thomas J. Watson Research Center - Enterprise Linux Group P. O. Box 218, Yorktown Heights, NY 10598 email: jongchoi@us.ibm.com (phone) 914-945-3979 (fax) 914-945-4425 TL: 862-3979 --=_alternative 0049699B85256D3B_= Content-Type: text/html; charset="us-ascii"
Ted,

>                 To me, you seem to be arguing below that the
>approach (client pull, optimized by some server state) is invalid,
>when my reading both of the draft and this text would be that this
>approach allows a wide  range of variation in the balance between
>optimizing wire traffic by increasing server state and optimizing
>server scale by allowing for profligate returns.  While I certainly
>respect your sense of the difficulty of implementation this might
>pose to existing clients and servers, I'm not sure how this makes
>this invalid.  It is an engineering balance between two costs,
>and the protocol allows the balance to shift both ways.

Because even a single omission of delete / modify in history can make
it impossible to recreate the previous sync result the cookie of a sync
request refers to, it looks more like a matter of how long the full
history information is maintained rather than how complete the history
information is. That is, as to the completeness of history, it is a binary
decision, not a wide range of variations. How long the full history is
maintained for sync purpose would give a tradeoff. But it still requires
maintaining full history in order to benefit even a small from the tradeoff.
It in fact assumes an implementation option and gives tradeoffs only within that option.

>                 is a good, short precis of your points.  I do see an engineering
>disagreement here on how to balance increases in state for
>deployed servers vs. the value it presents.  I don't see a show stopper,
>though, as the draft acknowledges the possibility that maintaining state
>will not be appropriate for all cases and provides other mechanisms for
>them.  That those are sub-optimal from a consumption perspective
>is not exactly surprising, given the basic design.

The concern here is that other mechanisms (full reload / sending excessive
entries) would be the norm for most cases.

Jong

------------------------
Jong Hyuk Choi
IBM Thomas J. Watson Research Center - Enterprise Linux Group
P. O. Box 218, Yorktown Heights, NY 10598
email: jongchoi@us.ibm.com
(phone) 914-945-3979    (fax) 914-945-4425   TL: 862-3979
 --=_alternative 0049699B85256D3B_=-- From owner-ietf-ldup@mail.imc.org Thu Jun 5 04:54:00 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11947 for ; Thu, 5 Jun 2003 04:54:00 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h558kmAF000741 for ; Thu, 5 Jun 2003 01:46:48 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h558km9c000740 for ietf-ldup-bks; Thu, 5 Jun 2003 01:46:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from echt.caledonia.net (echt.caledonia.net [207.40.197.226]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h558khAF000729 for ; Thu, 5 Jun 2003 01:46:44 -0700 (PDT) (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 ([199.72.166.218]) by echt.caledonia.net; Thu, 05 Jun 2003 02:46:05 -0600 Reply-To: From: "Chris Apple" To: Cc: "'Ramsay, Ron'" , "'Kurt D. Zeilenga'" Subject: RE: LDAP Client Update: consideration of alternative proposals Date: Thu, 5 Jun 2003 04:45:56 -0400 Organization: DSI-Consulting, Inc. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <5.2.0.9.0.20030603164026.02a87568@127.0.0.1> Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit One goal in writing applicability statements is to define constraints on how a particular protocol should be used. You are defining different types of constraints below. You can call one thing applicability and one thing a constraint, but with respect to a protocol specification that references requirements in an informative, rather than a normative way, they really do and should have the same effect on the protocol: to describe the scenario(s) in which its use is considered appropriate, scalable, efficient, effective, etc. One type of constraint relates to the types of applications for which LCUP's use is considered appropriate. Another type might be related to server design. There are many others... I do not dispute that you have an opinion which is counter to those of the authors of LCUP about the historical constraint present in their document. I do not see support for your arguments on the mailing list that the LCUP draft's applicability statement is flawed. To keep this local instance of IETF process open and fair with respect to LCUP and other LDUP deliverables, we should let the consumers/users of this technology decide if they are willing to live with the constraints in such an applicability statement during an IETF Last Call. And the Area Directors/IESG will have their say as well before it gets there. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Tuesday, June 03, 2003 8:15 PM To: capple@dsi-consulting.net Cc: 'Ramsay, Ron'; ietf-ldup@imc.org Subject: RE: LDAP Client Update: consideration of alternative proposals At 08:37 AM 5/29/2003, Chris Apple wrote: >Perhaps one source of difficulty in discussions >related to this topic is that there is not >agreement between yourself and the editors >of LCUP as to how broad a range of applicability >is appropriate for the LCUP deliverable? It's my opinion that LCUP deliverable should be generally applicable to directory applications needing content synchronization facilities. Both drafts seem to have the same applicability in terms of directory applications they apply to, how they differ significantly in the kinds of constraints they place on their implementations. I use the term constraint here instead of requirement to highlight the distinction of fulfilling a need of the directory applications versus of fulfilling a need of the design of a protocol. Our basic application requirement is that protocol provide efficient and effective content synchronization, with modes for polling for changes and listing for changes. Efficient implies a need to manage protocol exchanges to minimize traffic in most cases while generally avoiding "overly" chatty behavior. Effective implies a need for a reasonable level of data consistency. Applications could care less of whether their requirement was met using a history based approach or using state indicators based approach, that's an server implementation detail to them. Hence, draft-ietf-ldup-lcup need for servers to maintain and use history information is not an application requirement but a design constraint. I consider the draft-ietf-ldup-lcup's history design constraint unreasonable. This constraint certainly will will have an impact on its wide adoption as a technical solution to the general problem. Kurt From owner-ietf-ldup@mail.imc.org Thu Jun 5 09:34:28 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24364 for ; Thu, 5 Jun 2003 09:34:27 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h55DNCAF022350 for ; Thu, 5 Jun 2003 06:23:12 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h55DNCKv022349 for ietf-ldup-bks; Thu, 5 Jun 2003 06:23:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h55DNBAF022342 for ; Thu, 5 Jun 2003 06:23:11 -0700 (PDT) (envelope-from mcs@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h55DN1E17759 for ; Thu, 5 Jun 2003 06:23:01 -0700 (PDT) Received: from netscape.com ([10.169.192.40]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HG0FUF00.BOM; Thu, 5 Jun 2003 06:23:03 -0700 Message-ID: <3EDF4437.9000208@netscape.com> Date: Thu, 05 Jun 2003 09:23:03 -0400 From: mcs@netscape.com (Mark C Smith) Organization: Netscape Communications Corp. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030428 Netscape/7.02+ X-Accept-Language: en-us, en MIME-Version: 1.0 To: rmoats@lemurnetworks.net CC: Chris Apple , "'Kurt D. Zeilenga'" , "'Ramsay Ron'" , ietf-ldup@imc.org Subject: Re: comments on draft-zeilenga-ldup-sync (was Re: LDAP Client Update: consideration of alternative proposals) References: <5.2.0.9.0.20030528213812.0297ebb0@127.0.0.1> <007901c325f8$42a28490$6500a8c0@D7ST2111> <20030601203632.E1461@privateer.local.windrose.omaha.ne.us> <20030601205036.F1461@privateer.local.windrose.omaha.ne.us> In-Reply-To: <20030601205036.F1461@privateer.local.windrose.omaha.ne.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ryan Moats wrote: > > Well I've re-looked at these both and I've got concerns/questions about > each of them. This second piece of mail addresses one technical/process > concern I have with draft-ietf-ldup-lcup-05.txt. > > There was a suggestion (from me) that the initial backoff period be > specified with the lcupResourcesExhausted error. This had some support, > but I have never seen a reply on this issue. > > I still think that having the server specify the initial backoff time > (via an additional control) is superior to the current proposed method. The response that Rich Megginson posted as part of the LCUP last call reply basically says that clients have sufficient flexibility. But thinking about this again, I think this is a valid concern and that it would be an improvement to have the server specify the initial retry delay. Clients of course should be free to wait even longer if they choose to do so, use any variety of retry strategies, etc. For reference, here is the start of the relevant email thread: http://www.imc.org/ietf-ldup/mail-archive/msg01528.html -Mark Smith Netscape From owner-ietf-ldup@mail.imc.org Thu Jun 5 10:09:17 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26839 for ; Thu, 5 Jun 2003 10:09:16 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h55DxHAF023169 for ; Thu, 5 Jun 2003 06:59:17 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h55DxHsW023168 for ietf-ldup-bks; Thu, 5 Jun 2003 06:59:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h55DxGAF023160 for ; Thu, 5 Jun 2003 06:59:16 -0700 (PDT) (envelope-from mcs@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h55Dx6E22035 for ; Thu, 5 Jun 2003 06:59:06 -0700 (PDT) Received: from netscape.com ([10.169.192.40]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HG0HIK01.FPG; Thu, 5 Jun 2003 06:59:08 -0700 Message-ID: <3EDF4CA6.9050208@netscape.com> Date: Thu, 05 Jun 2003 09:59:02 -0400 From: mcs@netscape.com (Mark C Smith) Organization: Netscape Communications Corp. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030428 Netscape/7.02+ X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonghyuk Choi CC: hardie@qualcomm.com, ietf-ldup@imc.org, "Kurt D. Zeilenga" Subject: Re: Is this really an LCUP show stopper? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit First, a logistical comment: Rich Megginson is currently enjoying a long awaited sabbatical and is probably not reading email right now. I am sure he would have a lot to say if he was available, but I think he will be out for the next month or so. Jonghyuk Choi wrote: > > Because even a single omission of delete / modify in history can make > it impossible to recreate the previous sync result the cookie of a sync > request refers to, it looks more like a matter of how long the full > history information is maintained rather than how complete the history > information is. LCUP does not require that the server be able to "recreate the previous sync result." It requires that the server be able to, based on the cookie supplied by the client, generate a set of Sync Update messages that allow the client to synchronize with the server. This is a subtle difference, but important in some scenarios. > That is, as to the completeness of history, it is a binary > decision, not a wide range of variations. How long the full history is > maintained for sync purpose would give a tradeoff. But it still requires > maintaining full history in order to benefit even a small from the > tradeoff. > It in fact assumes an implementation option and gives tradeoffs only > within that option. If a server implementor wants to minimize the Sync Update message sent to clients and minimize the frequency of full resyncs and support all possible sync scenarios, then yes, quite a bit of state information must be maintained. But there are some tricks implementors can use to reduce the amount of state storage needed. For example, in most environments the search criteria used by all of the LCUP clients will involve a very small subset of the attribute types and values contained in the DIT. If my server only needs to support LCUP requests that use the search filter (objectClass=person) then I can reduce the amount of "extra" state storage down to a reasonably small amount. It will always be possible to come up with examples that make LCUP look bad from one perspective or another (wire traffic vs. server implementation burden), but I suspect the same is true of most synchronization protocols. > The concern here is that other mechanisms (full reload / sending excessive > entries) would be the norm for most cases. Perhaps your common use cases are different than the ones I have in mind. Or maybe you and Kurt are right. But I think we are mainly arguing about the validity of the engineering tradeoffs that were made in drafting and achieving consensus around draft-ietf-ldup-lcup-05.txt. Certainly this is a useful discussion; I hope more people will join in soon. -Mark Smith Netscape From owner-ietf-ldup@mail.imc.org Thu Jun 5 11:04:50 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29678 for ; Thu, 5 Jun 2003 11:04:49 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h55EqmAF026359 for ; Thu, 5 Jun 2003 07:52:48 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h55EqmNQ026358 for ietf-ldup-bks; Thu, 5 Jun 2003 07:52:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h55EqkAF026353 for ; Thu, 5 Jun 2003 07:52:46 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h55Eqhc6001898; Thu, 5 Jun 2003 14:52:43 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030605062026.01b32e78@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 05 Jun 2003 07:49:43 -0700 To: From: "Kurt D. Zeilenga" Subject: Applicability (Was: LDAP Client Update: consideration of alternative proposals) Cc: In-Reply-To: References: <5.2.0.9.0.20030603164026.02a87568@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Let's give consumers and users of the technology a question they care about. They don't care about implementation details, they care about whether or not the protocol is going to meet their application needs. In my opinion, applications need support for incremental synchronization capabilities. Hence, protocol should not only support incremental synchronization, the specification should say that servers are REQUIRED to support incremental synchronization in general cases. Otherwise, the protocol and its specification are for not. I prefer REQUIRE over RECOMMEND here as I view the behavior of generally forcing full synchronization when incremental synchronization was requested as being harmful. I believe RFC 2119 supports this view, it gives "limiting retransmisssions" as an example of harmful behavior. Kurt At 01:45 AM 6/5/2003, Chris Apple wrote: >One goal in writing applicability statements >is to define constraints on how a particular protocol >should be used. You are defining different types of >constraints below. You can call one thing applicability >and one thing a constraint, but with respect to a protocol >specification that references requirements in an informative, >rather than a normative way, they really do and should >have the same effect on the protocol: to describe the >scenario(s) in which its use is considered appropriate, >scalable, efficient, effective, etc. > >One type of constraint relates to the types of >applications for which LCUP's use is considered >appropriate. Another type might be related to >server design. There are many others... > >I do not dispute that you have an opinion which is >counter to those of the authors of LCUP about the >historical constraint present in their document. > >I do not see support for your arguments on the >mailing list that the LCUP draft's applicability >statement is flawed. > >To keep this local instance of IETF process open and >fair with respect to LCUP and other LDUP deliverables, >we should let the consumers/users of this technology >decide if they are willing to live with the constraints >in such an applicability statement during an IETF Last Call. > >And the Area Directors/IESG will have their say as well >before it gets there. > >Chris Apple - Principal Architect > >DSI Consulting, Inc. > >mailto:capple@dsi-consulting.net > >http://www.dsi-consulting.com > >-----Original Message----- >From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] >Sent: Tuesday, June 03, 2003 8:15 PM >To: capple@dsi-consulting.net >Cc: 'Ramsay, Ron'; ietf-ldup@imc.org >Subject: RE: LDAP Client Update: consideration of alternative proposals > > >At 08:37 AM 5/29/2003, Chris Apple wrote: >>Perhaps one source of difficulty in discussions >>related to this topic is that there is not >>agreement between yourself and the editors >>of LCUP as to how broad a range of applicability >>is appropriate for the LCUP deliverable? > >It's my opinion that LCUP deliverable should be generally >applicable to directory applications needing content >synchronization facilities. Both drafts seem to have the >same applicability in terms of directory applications they >apply to, how they differ significantly in the kinds of >constraints they place on their implementations. > >I use the term constraint here instead of requirement to >highlight the distinction of fulfilling a need of the >directory applications versus of fulfilling a need of the >design of a protocol. > >Our basic application requirement is that protocol provide >efficient and effective content synchronization, with modes >for polling for changes and listing for changes. Efficient >implies a need to manage protocol exchanges to minimize >traffic in most cases while generally avoiding "overly" >chatty behavior. Effective implies a need for a reasonable >level of data consistency. > >Applications could care less of whether their requirement >was met using a history based approach or using state >indicators based approach, that's an server implementation >detail to them. Hence, draft-ietf-ldup-lcup need for >servers to maintain and use history information is not an >application requirement but a design constraint. > >I consider the draft-ietf-ldup-lcup's history design >constraint unreasonable. This constraint certainly will >will have an impact on its wide adoption as a technical >solution to the general problem. > >Kurt From owner-ietf-ldup@mail.imc.org Thu Jun 5 12:55:14 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06174 for ; Thu, 5 Jun 2003 12:55:14 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h55GkSAF033675 for ; Thu, 5 Jun 2003 09:46:28 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h55GkSs8033674 for ietf-ldup-bks; Thu, 5 Jun 2003 09:46:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from biggar.caledonia.net (biggar.caledonia.net [207.40.197.236]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h55GkMAF033653 for ; Thu, 5 Jun 2003 09:46:25 -0700 (PDT) (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (dpvc-141-152-21-16.rich.east.verizon.net [141.152.21.16]) by biggar.caledonia.net; Thu, 05 Jun 2003 10:46:03 -0600 Reply-To: From: "Chris Apple" To: "'Kurt D. Zeilenga'" Cc: Subject: RE: Applicability (Was: LDAP Client Update: consideration of alternative proposals) Date: Thu, 5 Jun 2003 12:45:49 -0400 Organization: DSI-Consulting, Inc. Message-ID: <007701c32b81$f21565d0$3400000a@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <5.2.0.9.0.20030605062026.01b32e78@127.0.0.1> Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I define IT departments, managers, and staff as consumers of technology, more particularly, consumers of implementations and solutions based on technology; and they certainly care about the constraints placed on that technology. They will have to live with the impact of those constraints on the user community for whom they provide services and support. More savvy users, the one's who usually have some influence over purchasing decisions for such solutions, also care about constraints placed on technologies they use. They are more likely than any other users to push the edges of what is considered typical usage towards the boundary use cases associated with any particular constraint. So, it's a very relevant type of question to put forward. And I assert, one that gets asked implicitly each time a document is put through IETF Last Call. On the more technical points you make below, I'm watching the mailing list to see what others have to say in response to it. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Thursday, June 05, 2003 10:50 AM To: capple@dsi-consulting.net Cc: ietf-ldup@imc.org Subject: Applicability (Was: LDAP Client Update: consideration of alternative proposals) Let's give consumers and users of the technology a question they care about. They don't care about implementation details, they care about whether or not the protocol is going to meet their application needs. In my opinion, applications need support for incremental synchronization capabilities. Hence, protocol should not only support incremental synchronization, the specification should say that servers are REQUIRED to support incremental synchronization in general cases. Otherwise, the protocol and its specification are for not. I prefer REQUIRE over RECOMMEND here as I view the behavior of generally forcing full synchronization when incremental synchronization was requested as being harmful. I believe RFC 2119 supports this view, it gives "limiting retransmisssions" as an example of harmful behavior. Kurt At 01:45 AM 6/5/2003, Chris Apple wrote: >One goal in writing applicability statements >is to define constraints on how a particular protocol >should be used. You are defining different types of >constraints below. You can call one thing applicability >and one thing a constraint, but with respect to a protocol >specification that references requirements in an informative, >rather than a normative way, they really do and should >have the same effect on the protocol: to describe the >scenario(s) in which its use is considered appropriate, >scalable, efficient, effective, etc. > >One type of constraint relates to the types of >applications for which LCUP's use is considered >appropriate. Another type might be related to >server design. There are many others... > >I do not dispute that you have an opinion which is >counter to those of the authors of LCUP about the >historical constraint present in their document. > >I do not see support for your arguments on the >mailing list that the LCUP draft's applicability >statement is flawed. > >To keep this local instance of IETF process open and >fair with respect to LCUP and other LDUP deliverables, >we should let the consumers/users of this technology >decide if they are willing to live with the constraints >in such an applicability statement during an IETF Last Call. > >And the Area Directors/IESG will have their say as well >before it gets there. > >Chris Apple - Principal Architect > >DSI Consulting, Inc. > >mailto:capple@dsi-consulting.net > >http://www.dsi-consulting.com > >-----Original Message----- >From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] >Sent: Tuesday, June 03, 2003 8:15 PM >To: capple@dsi-consulting.net >Cc: 'Ramsay, Ron'; ietf-ldup@imc.org >Subject: RE: LDAP Client Update: consideration of alternative proposals > > >At 08:37 AM 5/29/2003, Chris Apple wrote: >>Perhaps one source of difficulty in discussions >>related to this topic is that there is not >>agreement between yourself and the editors >>of LCUP as to how broad a range of applicability >>is appropriate for the LCUP deliverable? > >It's my opinion that LCUP deliverable should be generally >applicable to directory applications needing content >synchronization facilities. Both drafts seem to have the >same applicability in terms of directory applications they >apply to, how they differ significantly in the kinds of >constraints they place on their implementations. > >I use the term constraint here instead of requirement to >highlight the distinction of fulfilling a need of the >directory applications versus of fulfilling a need of the >design of a protocol. > >Our basic application requirement is that protocol provide >efficient and effective content synchronization, with modes >for polling for changes and listing for changes. Efficient >implies a need to manage protocol exchanges to minimize >traffic in most cases while generally avoiding "overly" >chatty behavior. Effective implies a need for a reasonable >level of data consistency. > >Applications could care less of whether their requirement >was met using a history based approach or using state >indicators based approach, that's an server implementation >detail to them. Hence, draft-ietf-ldup-lcup need for >servers to maintain and use history information is not an >application requirement but a design constraint. > >I consider the draft-ietf-ldup-lcup's history design >constraint unreasonable. This constraint certainly will >will have an impact on its wide adoption as a technical >solution to the general problem. > >Kurt From owner-ietf-ldup@mail.imc.org Thu Jun 5 13:56:11 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08161 for ; Thu, 5 Jun 2003 13:56:11 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h55HjtAF036137 for ; Thu, 5 Jun 2003 10:45:55 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h55Hjt0x036136 for ietf-ldup-bks; Thu, 5 Jun 2003 10:45:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h55HjsAF036131 for ; Thu, 5 Jun 2003 10:45:54 -0700 (PDT) (envelope-from jeffparh@windows.microsoft.com) Received: from mail5.microsoft.com ([157.54.6.156]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 5 Jun 2003 10:45:48 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 5 Jun 2003 10:45:30 -0700 Received: from 157.54.5.25 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 05 Jun 2003 10:45:30 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 5 Jun 2003 10:45:30 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 5 Jun 2003 10:45:29 -0700 Received: from WIN-MSG-05.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.231]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Thu, 5 Jun 2003 10:45:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Applicability of LDAP Content Sync to loosely coupled replica sets Date: Thu, 5 Jun 2003 10:45:15 -0700 Message-ID: <6BA5A5D4255F564BBF4BF9E413BF53B80169CFFE@WIN-MSG-05.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Applicability of LDAP Content Sync to loosely coupled replica sets Thread-Index: AcMrijjOmgupqGHOR9u88MnHJ1y0pQ== From: "Jeff Parham" To: X-OriginalArrivalTime: 05 Jun 2003 17:45:16.0465 (UTC) FILETIME=[39611210:01C32B8A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h55HjsAF036132 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit As a server implementer, LDAP Content Sync has some very desirable properties. I lean heavily towards state-based designs myself, and the idea that one could design client sync based purely on server state and a small amount of client-persisted cookie information is attractive. However, I have a question about how the general model applies to highly available, loosely coupled replica sets: The requirement for high availability of writes encourages adoption of multi-master replication between DSAs, and geographic data distribution and other factors tend to encourage models in which these DSAs are loosely coupled - e.g., an update can be mastered on one DSA, even if other DSAs in the replica set can't be simultaneously contacted. This environment leads to "distribution of truth," where no single DSA can assert the complete, current state of the system - i.e., no single DSA necessarily holds the results of all updates previously committed to all DSAs. The multi-master replication in effect between DSAs in the replica set continually brings each DSA more up-to-date with respect to updates made on other replicas, but barring a cessation of updates, any given DSA can't be asserted to be completely up-to-date. High availability of DSAs from which clients can synchronize is very desirable in these environments: if the DSA that a client last synchronized from is unavailable, the client would like to synchronize from an alternate DSA. In doing so, the client very much wishes to avoid a full reload - to minimize client resource consumption, to maximize DSA scalability, and to minimize the latency of obtaining the incremental updates the client desires. Is LDAP Content Sync intended to be applicable in this case? Here it does not appear possible for any given DSA to guarantee that its notion of the "complete" set of objects matching some given criteria is identical to the set asserted by another DSA. Given LDAP Content Sync's method for declaring the set of objects currently matching the client's scope (by explicitly enumerating their entryUUIDs), might that then mean that a new object successfully synchronized from DSA1 could be removed in a subsequent incremental sync from DSA2, where DSA2 has not yet replicated the new object from DSA1, because DSA2 does not return the entryUUID for the new object? If so, how is the client ensured to eventually converge to a state in which it holds the new object? (E.g., what if the next sync sources from DSA1?) Does convergence require a (DSA-indicated) reload? How would DSA1 otherwise realize and repair the loss of client state caused by the client's communication with DSA2? LCUP appears to be immune to this phenomenon. Objects can be removed from the client only upon an LCUP full reload, which we believe will be exceedingly rare. Thanks, -J From owner-ietf-ldup@mail.imc.org Thu Jun 5 14:15:47 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09157 for ; Thu, 5 Jun 2003 14:15:46 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h55I6hAF036776 for ; Thu, 5 Jun 2003 11:06:43 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h55I6hSL036775 for ietf-ldup-bks; Thu, 5 Jun 2003 11:06:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h55I6gAF036768 for ; Thu, 5 Jun 2003 11:06:42 -0700 (PDT) (envelope-from jeffparh@windows.microsoft.com) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6659); Thu, 5 Jun 2003 11:06:38 -0700 Received: from 157.54.5.25 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 05 Jun 2003 11:06:38 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 5 Jun 2003 11:06:38 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 5 Jun 2003 11:06:36 -0700 Received: from WIN-MSG-05.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.231]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Thu, 5 Jun 2003 11:06:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Is this really an LCUP show stopper? Date: Thu, 5 Jun 2003 11:06:35 -0700 Message-ID: <6BA5A5D4255F564BBF4BF9E413BF53B80169D05B@WIN-MSG-05.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Is this really an LCUP show stopper? Thread-Index: AcMrbj/FkludRzN8R8yfdHyAReoMswAHV5cg From: "Jeff Parham" To: "Mark C Smith" , "Jonghyuk Choi" Cc: , , "Kurt D. Zeilenga" X-OriginalArrivalTime: 05 Jun 2003 18:06:36.0447 (UTC) FILETIME=[344ED2F0:01C32B8D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h55I6hAF036771 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit > Jonghyuk Choi wrote: > > > > Because even a single omission of delete / modify in history can make > > it impossible to recreate the previous sync result the cookie of a sync > > request refers to, it looks more like a matter of how long the full > > history information is maintained rather than how complete the history > > information is. > > LCUP does not require that the server be able to "recreate the previous > sync result." It requires that the server be able to, based on the > cookie supplied by the client, generate a set of Sync Update messages > that allow the client to synchronize with the server. This is a subtle > difference, but important in some scenarios. Mark is correct. It is not necessary that the server infer the exact state of the client, just a sufficiently close approximation to ensure it can send the necessary update messages to bring the client up to date. I believe it to be exceedingly rare in practice that strictly unnecessary transmissions (unnecessary if the server could infer the exact client state) will be present and consume any significant amount of resources compared to the strictly necessary transmissions. Eliminating all strictly unnecessary traffic is unrealistic given the "no server-side, per-client state" requirement -- at best, you can shift it around. For example, LDAP Content Sync's stream of entryUUIDs for entries already present on the client can be construed as "strictly unnecessary transmissions". -J From owner-ietf-ldup@mail.imc.org Thu Jun 5 16:17:23 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15355 for ; Thu, 5 Jun 2003 16:17:22 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h55K3iAF045387 for ; Thu, 5 Jun 2003 13:03:44 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h55K3iLF045386 for ietf-ldup-bks; Thu, 5 Jun 2003 13:03:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h55K3hAF045381 for ; Thu, 5 Jun 2003 13:03:43 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h55K3jc6004609; Thu, 5 Jun 2003 20:03:45 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030605124334.01b6f248@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 05 Jun 2003 13:00:44 -0700 To: "Jeff Parham" From: "Kurt D. Zeilenga" Subject: Re: Applicability of LDAP Content Sync to loosely coupled replica sets Cc: In-Reply-To: <6BA5A5D4255F564BBF4BF9E413BF53B80169CFFE@WIN-MSG-05.wingro up.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:45 AM 6/5/2003, Jeff Parham wrote: >Is LDAP Content Sync intended to be applicable in this [multi-master >replication] case? No, draft-zeilenga-ldup-sync-02.txt: Possible uses include: ... - Lightweight master-slave replication between heterogeneous directory servers. For example, the Sync operation can be used by a slave server to maintain a shadow copy of a DIT fragment. This use has the same basic content synchronization requirements as what draft-ietf-ldup-lcup-05.txt describes as: Applications intending to synchronize heterogeneous data stores. Kurt From owner-ietf-ldup@mail.imc.org Thu Jun 5 17:36:19 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18187 for ; Thu, 5 Jun 2003 17:36:19 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h55LQxAF047197 for ; Thu, 5 Jun 2003 14:26:59 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h55LQxMx047196 for ietf-ldup-bks; Thu, 5 Jun 2003 14:26:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h55LQwAF047190 for ; Thu, 5 Jun 2003 14:26:58 -0700 (PDT) (envelope-from jeffparh@windows.microsoft.com) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 5 Jun 2003 14:26:54 -0700 Received: from 157.54.8.155 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 05 Jun 2003 14:26:54 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 5 Jun 2003 14:26:53 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 5 Jun 2003 14:26:52 -0700 Received: from WIN-MSG-05.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.231]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Thu, 5 Jun 2003 14:26:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Applicability of LDAP Content Sync to loosely coupled replica sets Date: Thu, 5 Jun 2003 14:26:51 -0700 Message-ID: <6BA5A5D4255F564BBF4BF9E413BF53B801789450@WIN-MSG-05.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Applicability of LDAP Content Sync to loosely coupled replica sets Thread-Index: AcMrnZNNg73mIyKwRdW5ond9NTb4vwACurQg From: "Jeff Parham" To: "Kurt D. Zeilenga" Cc: X-OriginalArrivalTime: 05 Jun 2003 21:26:52.0725 (UTC) FILETIME=[2E915650:01C32BA9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h55LQwAF047191 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > > At 10:45 AM 6/5/2003, Jeff Parham wrote: > >Is LDAP Content Sync intended to be applicable in this [multi-master > >replication] case? > > No, draft-zeilenga-ldup-sync-02.txt: > Possible uses include: > ... > - Lightweight master-slave replication between heterogeneous > directory servers. For example, the Sync operation can > be used by a slave server to maintain a shadow copy of a > DIT fragment. My question isn't whether LDAP Content Sync can be used to perform multi-master replication, it's whether LDAP Content Sync can be used for a client to synchronize from a store where the store is made up of a set of nodes that perform multi-master replication amongst themselves. This cuts across the various usage scenarios -- e.g., a mail client may wish to synchronize an address book (as a slave) from a set of multi-mastered DSAs. -J From owner-ietf-ldup@mail.imc.org Thu Jun 5 19:12:24 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21872 for ; Thu, 5 Jun 2003 19:12:24 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h55N56AF051079 for ; Thu, 5 Jun 2003 16:05:06 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h55N56qi051078 for ietf-ldup-bks; Thu, 5 Jun 2003 16:05:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h55N54AF051073 for ; Thu, 5 Jun 2003 16:05:04 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h55N51c6006731; Thu, 5 Jun 2003 23:05:02 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030605150854.01b58388@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 05 Jun 2003 16:01:43 -0700 To: "Jeff Parham" From: "Kurt D. Zeilenga" Subject: Re: Applicability of LDAP Content Sync to loosely coupled replica sets Cc: In-Reply-To: <6BA5A5D4255F564BBF4BF9E413BF53B80169CFFE@WIN-MSG-05.wingro up.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeff Parham wrote: >My question isn't whether LDAP Content Sync can be used to perform >multi-master replication, it's whether LDAP Content Sync can be used for >a client to synchronize from a store where the store is made up of a set >of nodes that perform multi-master replication amongst themselves. Thanks for the clarification. We did consider impacts of replication, mostly looking at single-master environments as this is what we are most familiar with and what LDAP models currently supports. However, I believe that single-master environments have many of the same client update issues found in multi-master environments (when you consider issues between slaves which converge at different rates to their master). I do think it would be appropriate for each I-D to discuss replication issues. >Is LDAP Content Sync intended to be applicable in this case? Likely (but I'd have to think about it more). I note that since LDAP Sync supports both updates+present and update+delete incremental synchronization mechanisms, if LCUP is applicable then likely so is LDAP Sync. Kurt From owner-ietf-ldup@mail.imc.org Thu Jun 5 21:44:39 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24905 for ; Thu, 5 Jun 2003 21:44:38 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h561aVAF053761 for ; Thu, 5 Jun 2003 18:36:31 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h561aUYd053760 for ietf-ldup-bks; Thu, 5 Jun 2003 18:36:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h561aTAF053752 for ; Thu, 5 Jun 2003 18:36:29 -0700 (PDT) (envelope-from jeffparh@windows.microsoft.com) Received: from mail5.microsoft.com ([157.54.6.156]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 5 Jun 2003 18:36:26 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 5 Jun 2003 18:36:24 -0700 Received: from 157.54.8.109 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 05 Jun 2003 18:36:24 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 5 Jun 2003 18:36:24 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 5 Jun 2003 18:36:23 -0700 Received: from WIN-MSG-05.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.231]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Thu, 5 Jun 2003 18:36:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Applicability of LDAP Content Sync to loosely coupled replica sets Date: Thu, 5 Jun 2003 18:36:41 -0700 Message-ID: <6BA5A5D4255F564BBF4BF9E413BF53B8017895DA@WIN-MSG-05.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Applicability of LDAP Content Sync to loosely coupled replica sets Thread-Index: AcMrtulBQ6bxIb2OSCWkVZHZW7vTtgAEMKlA From: "Jeff Parham" To: "Kurt D. Zeilenga" Cc: X-OriginalArrivalTime: 06 Jun 2003 01:36:22.0963 (UTC) FILETIME=[09866030:01C32BCC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h561aUAF053756 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Kurt D. Zeilenga wrote: > We did consider impacts of replication, mostly looking at > single-master environments as this is what we are most familiar > with and what LDAP models currently supports. Maybe just a nit, but there do exist very widely deployed LDAP directories that support loosely coupled DSAs tied together with multi-master replication -- Active Directory and eDirectory, for two. I guess this issue has beaten into the ground on the list already, though. > However, I > believe that single-master environments have many of the same > client update issues found in multi-master environments (when > you consider issues between slaves which converge at different > rates to their master). Agreed -- I suppose I could have left the single- vs. multi-master part out of my question, and simply stuck with "loosely coupled". > >Is LDAP Content Sync intended to be applicable in this case? > > Likely (but I'd have to think about it more). I note that since > LDAP Sync supports both updates+present and update+delete > incremental synchronization mechanisms, if LCUP is applicable > then likely so is LDAP Sync. I'm not sure I agree there. The key difference between LCUP and LDAP Content Sync is the ability to assert the "member objects" without forcing a reload. The implication is that an incremental sync can force the client to drop previous knowledge, which seems to be the heart of the problematic example I illustrated. LCUP doesn't have such a mechanism; knowledge is lost only on a full reload. If it were determined that dropping knowledge on incremental LDAP Content Sync was too problematic (I don't know if this is true -- just hypothetical) and dropped from the draft, then it seems to me that the result would essentially be the same as LCUP. Is that an overly simplified viewpoint? Thanks, -J From owner-ietf-ldup@mail.imc.org Fri Jun 6 09:29:43 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22690 for ; Fri, 6 Jun 2003 09:29:42 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h56DDwAF010313 for ; Fri, 6 Jun 2003 06:13:58 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h56DDwlM010312 for ietf-ldup-bks; Fri, 6 Jun 2003 06:13:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h56DDtAF010306 for ; Fri, 6 Jun 2003 06:13:55 -0700 (PDT) (envelope-from jongchoi@us.ibm.com) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h56DDg9X115576; Fri, 6 Jun 2003 09:13:42 -0400 Received: from d01ml233.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h56DDenW236440; Fri, 6 Jun 2003 09:13:40 -0400 To: mcs@netscape.com (Mark C Smith) Cc: hardie@qualcomm.com, ietf-ldup@imc.org, "Kurt D. Zeilenga" MIME-Version: 1.0 Subject: Re: Is this really an LCUP show stopper? X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Jonghyuk Choi Date: Fri, 6 Jun 2003 09:13:38 -0400 X-MIMETrack: Serialize by Router on D01ML233/01/M/IBM(Release 6.0.1 [IBM]|June 3, 2003) at 06/06/2003 09:13:40, Serialize complete at 06/06/2003 09:13:40 Content-Type: multipart/alternative; boundary="=_alternative 0048A3CB85256D3D_=" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0048A3CB85256D3D_= Content-Type: text/plain; charset="us-ascii" Mark, >LCUP does not require that the server be able to "recreate the previous >sync result." It requires that the server be able to, based on the >cookie supplied by the client, generate a set of Sync Update messages >that allow the client to synchronize with the server. This is a subtle >difference, but important in some scenarios. No, LCUP doesn't. But an implementation needs to do for reasonablely incremental synchronization. >If a server implementor wants to minimize the Sync Update message sent >to clients and minimize the frequency of full resyncs and support all >possible sync scenarios, then yes, quite a bit of state information must >be maintained. But there are some tricks implementors can use to reduce >the amount of state storage needed. For example, in most environments >the search criteria used by all of the LCUP clients will involve a very >small subset of the attribute types and values contained in the DIT. If >my server only needs to support LCUP requests that use the search filter >(objectClass=person) then I can reduce the amount of "extra" state >storage down to a reasonably small amount. It will always be possible to >come up with examples that make LCUP look bad from one perspective or >another (wire traffic vs. server implementation burden), but I suspect >the same is true of most synchronization protocols. Let me take the LDAP Proxy cache as an example. It's an important application, even though it may just add another to the examples that make LCUP look bad. LDAP Proxy Cache caches LDAP results from LDAP servers based on client queries. If a query is answerable from the proxy cache, it returns LDAP result directly without contacting the server. If it's not, it fetches results from the LDAP server and returns them to the client. A client update protocol can be used to synchronize cached entries with the server. Clients can request various search criteria to the LDAP Proxy Cache which in turn will send LCUP requests with various search criteria to the server. A good protocol needs be scalable and consider a wide range of the current and also future applications. - Jong ------------------------ Jong Hyuk Choi IBM Thomas J. Watson Research Center - Enterprise Linux Group P. O. Box 218, Yorktown Heights, NY 10598 email: jongchoi@us.ibm.com (phone) 914-945-3979 (fax) 914-945-4425 TL: 862-3979 --=_alternative 0048A3CB85256D3D_= Content-Type: text/html; charset="us-ascii"
Mark,

>LCUP does not require that the server be able to "recreate the previous
>sync result." It requires that the server be able to, based on the
>cookie supplied by the client, generate a set of Sync Update messages
>that allow the client to synchronize with the server. This is a subtle
>difference, but important in some scenarios.

No, LCUP doesn't. But an implementation needs to do for reasonablely
incremental synchronization.

>If a server implementor wants to minimize the Sync Update message sent
>to clients and minimize the frequency of full resyncs and support all
>possible sync scenarios, then yes, quite a bit of state information must
>be maintained. But there are some tricks implementors can use to reduce
>the amount of state storage needed. For example, in most environments
>the search criteria used by all of the LCUP clients will involve a very
>small subset of the attribute types and values contained in the DIT. If
>my server only needs to support LCUP requests that use the search filter
>(objectClass=person) then I can reduce the amount of "extra" state
>storage down to a reasonably small amount. It will always be possible to
>come up with examples that make LCUP look bad from one perspective or
>another (wire traffic vs. server implementation burden), but I suspect
>the same is true of most synchronization protocols.

Let me take the LDAP Proxy cache as an example. It's an important
application, even though it may just add another to the examples that
make LCUP look bad. LDAP Proxy Cache caches LDAP results from LDAP servers
based on client queries. If a query is answerable from the proxy cache,
it returns LDAP result directly without contacting the server. If it's not,
it fetches results from the LDAP server and returns them to the client.
A client update protocol can be used to synchronize cached entries with
the server. Clients can request various search criteria to the LDAP Proxy Cache
which in turn will send LCUP requests with various search criteria to the server.
A good protocol needs be scalable and consider a wide range of the current
and also future applications.

- Jong

------------------------
Jong Hyuk Choi
IBM Thomas J. Watson Research Center - Enterprise Linux Group
P. O. Box 218, Yorktown Heights, NY 10598
email: jongchoi@us.ibm.com
(phone) 914-945-3979    (fax) 914-945-4425   TL: 862-3979 --=_alternative 0048A3CB85256D3D_=-- From owner-ietf-ldup@mail.imc.org Fri Jun 6 13:39:10 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03787 for ; Fri, 6 Jun 2003 13:39:07 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h56HWKAF024213 for ; Fri, 6 Jun 2003 10:32:20 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h56HWKRn024211 for ietf-ldup-bks; Fri, 6 Jun 2003 10:32:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h56HWJAF024202 for ; Fri, 6 Jun 2003 10:32:19 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h56HWKc6015098; Fri, 6 Jun 2003 17:32:20 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030606100102.01ca6eb8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 06 Jun 2003 10:29:19 -0700 To: "Jeff Parham" From: "Kurt D. Zeilenga" Subject: RE: Applicability of LDAP Content Sync to loosely coupled replica sets Cc: In-Reply-To: <6BA5A5D4255F564BBF4BF9E413BF53B8017895DA@WIN-MSG-05.wingro up.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 06:36 PM 6/5/2003, Jeff Parham wrote: >> >Is LDAP Content Sync intended to be applicable in this case? >> >> Likely (but I'd have to think about it more). I note that since >> LDAP Sync supports both updates+present and update+delete >> incremental synchronization mechanisms, if LCUP is applicable >> then likely so is LDAP Sync. > >I'm not sure I agree there. The key difference between LCUP and LDAP >Content Sync is the ability to assert the "member objects" without >forcing a reload. The implication is that an incremental sync can force >the client to drop previous knowledge, which seems to be the heart of >the problematic example I illustrated. LCUP doesn't have such a >mechanism; knowledge is lost only on a full reload. LCUP not only support an incremental sync mechanism (updates+deletes) to drop previous knowledge, servers are to use those mechanism to ensure eventual convergence. If they cannot ensure eventual convergence, they are to force a reload. LDAP Sync provides two incremental sync mechanisms (updates+deletes and update+present), but has the same eventual convergence requirements. >If it were determined that dropping knowledge on incremental LDAP >Content Sync was too problematic (I don't know if this is true -- just >hypothetical) and dropped from the draft, then it seems to me that the >result would essentially be the same as LCUP. Is that an overly >simplified viewpoint? I think the WG long ago determined that not providing eventual convergence was problematic. To provide eventual convergence, you not only need mechanism(s) to drop that knowledge, you need guarantees that the mechanism(s) will be used appropriately to ensure inconsistencies that might occur are transient. Kurt From owner-ietf-ldup@mail.imc.org Fri Jun 6 15:43:58 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09866 for ; Fri, 6 Jun 2003 15:43:58 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h56JbAAF031918 for ; Fri, 6 Jun 2003 12:37:10 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h56Jb9Hf031917 for ietf-ldup-bks; Fri, 6 Jun 2003 12:37:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h56Jb8AF031908 for ; Fri, 6 Jun 2003 12:37:08 -0700 (PDT) (envelope-from jmcmeek@us.ibm.com) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h56Jb5xr154664 for ; Fri, 6 Jun 2003 15:37:05 -0400 Received: from d27ml001.rchland.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h56Jb3nW049478 for ; Fri, 6 Jun 2003 15:37:03 -0400 Subject: Re: Is this really an LCUP show stopper? To: ietf-ldup@imc.org X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: John McMeeking Date: Fri, 6 Jun 2003 14:37:01 -0500 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Build V602_05052003|May 05, 2003) at 06/06/2003 14:37:04 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: My two bits worth: I favor the LDAP Sync approach over LCUP. This is largely because changes to LDAP Sync appear to make LCUP a valid implementation of LDAP Sync, and it doesn't appear that LDAP sync would be significantly harder to implement, from either the server or client perspective. I think either one is likely to be adequate for a large number of uses/users. Specific comments on the two drafts are being submitted separately. =========== As I understand it, this discussion basically boils down to how a client finds out that an entry has left the result set and whether that imposes undo requirements on an implementation or results in excessive network traffic. The choices being: 1. Server sends "entry deleted" messages -- LCUP or LDAP Sync -- server must maintain history 2. Server sends "entry present" messages for all entries in result set, client determines what is gone -- LDAP Sync -- no history required 3. Reload required -- LCUP or LDAP Sync -- server doesn't have the necessary history, or changes are "too big" It seems to me that all these will all result in the client having the same content, so I don't see an issue with either approach not working. I think the notion of maintaining a history so that a server can send "entry deleted" messages is important. Synchronizing a 100,000 entry directory with no (or limited) changes by sending 1000,000 entry present messages seems like poor behavior. I believe that change to LDAP Sync was needed. It seems that LCUP could be implemented using LDAP Sync extended ops and controls. A server implementation could always choose between options 1 and 3. And I think that would be a valid implementation of LDAP Sync. The client, of course, would have to work properly with option 2, which might make testing the client problematic if the client and server vendors are the same. Similarly, a server implementation could choose to always use options 2 and 3. I don't think that either LDAP Sync or LCUP will be significantly harder to implement (either server or client side) if one accepts the notion that some history is desirable. As stated earlier, I think that history is necessary to a well-behaved synchronization mechanism. I have not been able to come to any firm position on the need (or lack thereof) for the "entry present" mechanism. It is clear that if the data being synchronized is "large", and a change to entries and / or meta-data results in a situation where the server knows that the content of entries visible to the client has not changed, and a large number of entries has potentially left the result set (without any equally large number of entries entering the result set), that sending "entry present" results will take less bandwidth than resending entire entries. It is far from clear to me how likely such scenarios are. One case where the "entry present" mechanism does work well is when a client synchronizes infrequently with resect to the deleted/moved entry history maintained by the server. I suspect either method will be sensitive to certain classes of changes (most likely access control or group membership) that will result in some clients being reloaded even though the net content change on the client is small -- just too hard to figure out the delta. John McMeeking From owner-ietf-ldup@mail.imc.org Fri Jun 6 15:58:36 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10232 for ; Fri, 6 Jun 2003 15:58:35 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h56JqFAF032371 for ; Fri, 6 Jun 2003 12:52:15 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h56JqFhM032370 for ietf-ldup-bks; Fri, 6 Jun 2003 12:52:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h56JqEAF032363 for ; Fri, 6 Jun 2003 12:52:14 -0700 (PDT) (envelope-from jeffparh@windows.microsoft.com) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Fri, 6 Jun 2003 12:52:10 -0700 Received: from 157.54.8.109 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 06 Jun 2003 12:52:10 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 6 Jun 2003 12:52:10 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 6 Jun 2003 12:52:09 -0700 Received: from WIN-MSG-05.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.231]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Fri, 6 Jun 2003 12:52:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Applicability of LDAP Content Sync to loosely coupled replica sets Date: Fri, 6 Jun 2003 12:52:08 -0700 Message-ID: <6BA5A5D4255F564BBF4BF9E413BF53B801789812@WIN-MSG-05.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Applicability of LDAP Content Sync to loosely coupled replica sets Thread-Index: AcMsUazbFb/LwU36SYqQ4nesHPN0SAAAg+Og From: "Jeff Parham" To: "Kurt D. Zeilenga" Cc: X-OriginalArrivalTime: 06 Jun 2003 19:52:09.0276 (UTC) FILETIME=[1D6197C0:01C32C65] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h56JqEAF032366 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Friday, June 06, 2003 10:29 AM > To: Jeff Parham > Cc: ietf-ldup@imc.org > Subject: RE: Applicability of LDAP Content Sync to loosely coupled replica > sets > > At 06:36 PM 6/5/2003, Jeff Parham wrote: > >> >Is LDAP Content Sync intended to be applicable in this case? > >> > >> Likely (but I'd have to think about it more). I note that since > >> LDAP Sync supports both updates+present and update+delete > >> incremental synchronization mechanisms, if LCUP is applicable > >> then likely so is LDAP Sync. > > > >I'm not sure I agree there. The key difference between LCUP and LDAP > >Content Sync is the ability to assert the "member objects" without > >forcing a reload. The implication is that an incremental sync can force > >the client to drop previous knowledge, which seems to be the heart of > >the problematic example I illustrated. LCUP doesn't have such a > >mechanism; knowledge is lost only on a full reload. > > LCUP not only support an incremental sync mechanism (updates+deletes) > to drop previous knowledge, servers are to use those mechanism to ensure > eventual convergence. If they cannot ensure eventual convergence, they > are to force a reload. > > LDAP Sync provides two incremental sync mechanisms (updates+deletes > and update+present), but has the same eventual convergence requirements. By "lost knowledge", I'm referring to knowledge the client did have and should have in the future, but now does not. In the example in http://www.imc.org/ietf-ldup/mail-archive/msg01792.html, a client that should in the fullness of time have a copy of the new object created on DSA1 first gets that object from DSA1, then is forced to drop it after performing an LDAP Content Sync against DSA2. This is what I refer to as "lost knowledge", as opposed to the case where synchronization indicates to the client that an object that the client synced in the past e.g. has moved out of the subtree being synchronized by the client. How does LDAP Content Sync detect and recover from this lost knowledge phenomenon? If it does so by discouraging or eliminating the mechanism that diffs the full set of objects by entryUUID, then LDAP Content Sync essentially becomes the same proposal as LCUP. In short, I would love to see a solution that requires little or no history information on the DSA and simultaneously guarantees convergence, but I'm having trouble seeing how the differences in LDAP Content Sync over LCUP actually enable this in loosely coupled deployments. Thanks, -J From owner-ietf-ldup@mail.imc.org Fri Jun 6 16:05:49 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10468 for ; Fri, 6 Jun 2003 16:05:48 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h56K0lAF032583 for ; Fri, 6 Jun 2003 13:00:47 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h56K0lp2032582 for ietf-ldup-bks; Fri, 6 Jun 2003 13:00:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h56K0jAF032573 for ; Fri, 6 Jun 2003 13:00:46 -0700 (PDT) (envelope-from jmcmeek@us.ibm.com) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h56K0gxr140774 for ; Fri, 6 Jun 2003 16:00:42 -0400 Received: from d27ml001.rchland.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h56K0enW031372 for ; Fri, 6 Jun 2003 16:00:41 -0400 Subject: Comments on lcup-05 To: ietf-ldup@imc.org X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: John McMeeking Date: Fri, 6 Jun 2003 15:00:38 -0500 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Build V602_05052003|May 05, 2003) at 06/06/2003 15:00:40 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Here's some comments on draft-ietf-ldup-lcup-05.txt: 1. Overview - paragraph on state information. I would resatate this something like: "... the server does not need to maintain state information specific to individual clients. The server may need to maintain additional state information about deleted or moved/renamed entries." 3.5 (all controls). All these controls have a significant number of optional fields. I think we should add tags to simplify proper decoding of the control data. Also, given recent discussions about ASN.1 tagging, it would be appropriate to state that implicit tagging is used (if it is). 4.2.7 Result for Entries that have left the result set. There are two "An entry SHOULD be returned as having left...." clauses. It appears the second one is left over from a rewrite, as it repeats information in 4.2.5. This would make it more consistent with 4.2.6. 4.3.4/4.3.5. I think the server should be given the option of rejecting a LCUP search that includes virtual or collective attributes. If a server would normally return these attributes, it must either properly synchronize these attributes or reject the search request. Maybe a new "lcupInvalidAttribute" or "unwillingToPerform" resultCode would be appropriate. 4.4.1 Server Initiated Termination. This para references a lcupClientDisconnected resultCode. I didn't see that resultCode defined. 4.5 This can probably be deleted, though it might be helpful earlier to explain what the synchronize and persist phases do and the sequence of requests/controls. John McMeeking From owner-ietf-ldup@mail.imc.org Fri Jun 6 17:11:44 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13225 for ; Fri, 6 Jun 2003 17:11:43 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h56KukAF033958 for ; Fri, 6 Jun 2003 13:56:46 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h56Kukff033957 for ietf-ldup-bks; Fri, 6 Jun 2003 13:56:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h56KujAF033952 for ; Fri, 6 Jun 2003 13:56:45 -0700 (PDT) (envelope-from jmcmeek@us.ibm.com) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h56Kufxr081358 for ; Fri, 6 Jun 2003 16:56:41 -0400 Received: from d27ml001.rchland.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h56KuenW191896 for ; Fri, 6 Jun 2003 16:56:40 -0400 Subject: Comments on ldup-sync-02 To: ietf-ldup@imc.org X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: John McMeeking Date: Fri, 6 Jun 2003 15:56:38 -0500 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Build V602_05052003|May 05, 2003) at 06/06/2003 15:56:40 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: A few comments on draft-zeilenga-ldup-sync-2.txt: 1.1 Background - para on state information. It might be more correct to state that LDAP Sync does not require the server to maintain state information beyond that already required by the LDAP v3 RFCs. I think information like modifyTimestamp is state information. 2. Elements of the Sync Operation. This section ought to state that implicit tagging is used. 2.1.2 syncCookie (also Security Considerations). Does the mention of a digital signature belong here? I don't see that tampering with a cookie would be any worse than tampering with anything else in the protocol. I don't see how a malformed cookie could give you access to data you aren't authorized to. At worst, it could cause the client to miss changes or get redundant changes. Any result returned should be subject to the server's access control mechanisms. 4.2 Operational Attributes - delete last sentence: "Synchronization of operational attributes is discussed in Section 4.1." John McMeeking From owner-ietf-ldup@mail.imc.org Fri Jun 6 18:08:16 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15890 for ; Fri, 6 Jun 2003 18:08:16 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h56M0aAF036515 for ; Fri, 6 Jun 2003 15:00:36 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h56M0axa036514 for ietf-ldup-bks; Fri, 6 Jun 2003 15:00:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h56M0ZAF036509 for ; Fri, 6 Jun 2003 15:00:35 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h56M0bc6017013; Fri, 6 Jun 2003 22:00:37 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030606142100.01d3bbe0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 06 Jun 2003 14:57:35 -0700 To: John McMeeking From: "Kurt D. Zeilenga" Subject: Re: Comments on ldup-sync-02 Cc: ietf-ldup@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 01:56 PM 6/6/2003, John McMeeking wrote: >A few comments on draft-zeilenga-ldup-sync-2.txt: Thanks. I largely concur with your comments and hence limit my comments to the one issue I think needs further discussion. >2.1.2 syncCookie (also Security Considerations). Does the mention of a >digital signature belong here? I don't see that tampering with a cookie >would be any worse than tampering with anything else in the protocol. I >don't see how a malformed cookie could give you access to data you aren't >authorized to. At worst, it could cause the client to miss changes or get >redundant changes. Any result returned should be subject to the server's >access control mechanisms. I think the short of it is that servers have to be prepared to deal with cookies which have been tampered with. Depending on the information held in the cookie, it may be difficult for server implementors to ensure that all possible cookie values are safe. And, as we know, implementors don't always think of every possible attack. So, use of a digital signature to detect tampering may be reasonable protective measure. An easy way to include a digital signature is to include some secret information in the hash suggested in 2.1.2. I suggest it only be mentioned in Security Considerations section. Implementors should take precautions against malicious cookie content, including malformed cookies or valid cookies used with different security associations and/or protections in attempt to obtain unauthorized access to information. Servers may include a digital signature in the cookie to detect tampering. as there is no need to imply that this would be done generally. Would this be reasonable? From owner-ietf-ldup@mail.imc.org Fri Jun 6 18:14:51 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16567 for ; Fri, 6 Jun 2003 18:14:51 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h56M8oAF036651 for ; Fri, 6 Jun 2003 15:08:50 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h56M8o5B036650 for ietf-ldup-bks; Fri, 6 Jun 2003 15:08:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h56M8mAF036645 for ; Fri, 6 Jun 2003 15:08:49 -0700 (PDT) (envelope-from jmcmeek@us.ibm.com) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h56M8jtd193904; Fri, 6 Jun 2003 18:08:45 -0400 Received: from d27ml001.rchland.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h56M8inW161062; Fri, 6 Jun 2003 18:08:44 -0400 Subject: Re: Comments on ldup-sync-02 To: "Kurt D. Zeilenga" Cc: ietf-ldup@imc.org X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: John McMeeking Date: Fri, 6 Jun 2003 17:08:43 -0500 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Build V602_05052003|May 05, 2003) at 06/06/2003 17:08:44 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: That's finem, though it seems like this is stating the obviuous -- though we have all been known to miss the obvious on occasion ;-( John McMeeking "Kurt D. Zeilenga" To: John McMeeking/Rochester/IBM@IBMUS Subject: Re: Comments on ldup-sync-02 06/06/2003 04:57 PM At 01:56 PM 6/6/2003, John McMeeking wrote: >A few comments on draft-zeilenga-ldup-sync-2.txt: Thanks. I largely concur with your comments and hence limit my comments to the one issue I think needs further discussion. >2.1.2 syncCookie (also Security Considerations). Does the mention of a >digital signature belong here? I don't see that tampering with a cookie >would be any worse than tampering with anything else in the protocol. I >don't see how a malformed cookie could give you access to data you aren't >authorized to. At worst, it could cause the client to miss changes or get >redundant changes. Any result returned should be subject to the server's >access control mechanisms. I think the short of it is that servers have to be prepared to deal with cookies which have been tampered with. Depending on the information held in the cookie, it may be difficult for server implementors to ensure that all possible cookie values are safe. And, as we know, implementors don't always think of every possible attack. So, use of a digital signature to detect tampering may be reasonable protective measure. An easy way to include a digital signature is to include some secret information in the hash suggested in 2.1.2. I suggest it only be mentioned in Security Considerations section. Implementors should take precautions against malicious cookie content, including malformed cookies or valid cookies used with different security associations and/or protections in attempt to obtain unauthorized access to information. Servers may include a digital signature in the cookie to detect tampering. as there is no need to imply that this would be done generally. Would this be reasonable? From owner-ietf-ldup@mail.imc.org Sat Jun 7 07:45:00 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11447 for ; Sat, 7 Jun 2003 07:44:59 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h57Bc7AF094225 for ; Sat, 7 Jun 2003 04:38:07 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h57Bc7Ts094223 for ietf-ldup-bks; Sat, 7 Jun 2003 04:38:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h57Bc5AF094214 for ; Sat, 7 Jun 2003 04:38:06 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h57Bc5c6023943; Sat, 7 Jun 2003 11:38:06 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030607040930.01c77860@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sat, 07 Jun 2003 04:35:03 -0700 To: "Jeff Parham" From: "Kurt D. Zeilenga" Subject: RE: Applicability of LDAP Content Sync to loosely coupled replica sets Cc: In-Reply-To: <6BA5A5D4255F564BBF4BF9E413BF53B801789812@WIN-MSG-05.wingro up.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeff, An LCUP server, in the case you describe, likely has to require a full reload. The problem is that the entry in question may, after changes are reconciled between the DSAs, be no longer in the result set and that reconciliation may be done in manner to which DSA2 never knows the entry was ever in the result set and, hence, never is able to send the necessary delete message for the entry. For example, the entry could have been deleted from DSA1 shortly the client disconnected from DSA1 and yet before the entry's creation was replicated to DSA2. I don't see how LDAP-Sync is any worse off here. Kurt At 12:52 PM 6/6/2003, Jeff Parham wrote: >> -----Original Message----- >> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] >> Sent: Friday, June 06, 2003 10:29 AM >> To: Jeff Parham >> Cc: ietf-ldup@imc.org >> Subject: RE: Applicability of LDAP Content Sync to loosely coupled >replica >> sets >> >> At 06:36 PM 6/5/2003, Jeff Parham wrote: >> >> >Is LDAP Content Sync intended to be applicable in this case? >> >> >> >> Likely (but I'd have to think about it more). I note that since >> >> LDAP Sync supports both updates+present and update+delete >> >> incremental synchronization mechanisms, if LCUP is applicable >> >> then likely so is LDAP Sync. >> > >> >I'm not sure I agree there. The key difference between LCUP and LDAP >> >Content Sync is the ability to assert the "member objects" without >> >forcing a reload. The implication is that an incremental sync can >force >> >the client to drop previous knowledge, which seems to be the heart of >> >the problematic example I illustrated. LCUP doesn't have such a >> >mechanism; knowledge is lost only on a full reload. >> >> LCUP not only support an incremental sync mechanism (updates+deletes) >> to drop previous knowledge, servers are to use those mechanism to >ensure >> eventual convergence. If they cannot ensure eventual convergence, >they >> are to force a reload. >> >> LDAP Sync provides two incremental sync mechanisms (updates+deletes >> and update+present), but has the same eventual convergence >requirements. > >By "lost knowledge", I'm referring to knowledge the client did have and >should have in the future, but now does not. In the example in >http://www.imc.org/ietf-ldup/mail-archive/msg01792.html, a client that >should in the fullness of time have a copy of the new object created on >DSA1 first gets that object from DSA1, then is forced to drop it after >performing an LDAP Content Sync against DSA2. This is what I refer to >as "lost knowledge", as opposed to the case where synchronization >indicates to the client that an object that the client synced in the >past e.g. has moved out of the subtree being synchronized by the client. > >How does LDAP Content Sync detect and recover from this lost knowledge >phenomenon? If it does so by discouraging or eliminating the mechanism >that diffs the full set of objects by entryUUID, then LDAP Content Sync >essentially becomes the same proposal as LCUP. > >In short, I would love to see a solution that requires little or no >history information on the DSA and simultaneously guarantees >convergence, but I'm having trouble seeing how the differences in LDAP >Content Sync over LCUP actually enable this in loosely coupled >deployments. > >Thanks, >-J From owner-ietf-ldup@mail.imc.org Sat Jun 7 12:14:14 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16216 for ; Sat, 7 Jun 2003 12:14:13 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h57G6vAF008831 for ; Sat, 7 Jun 2003 09:06:57 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h57G6vqB008830 for ietf-ldup-bks; Sat, 7 Jun 2003 09:06:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h57G6uAF008823 for ; Sat, 7 Jun 2003 09:06:56 -0700 (PDT) (envelope-from jeffparh@windows.microsoft.com) Received: from mail5.microsoft.com ([157.54.6.156]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Sat, 7 Jun 2003 09:06:49 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Sat, 7 Jun 2003 09:06:49 -0700 Received: from 157.54.8.23 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 07 Jun 2003 09:06:49 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 7 Jun 2003 09:06:49 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 7 Jun 2003 09:06:48 -0700 Received: from WIN-MSG-05.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.231]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Sat, 7 Jun 2003 09:06:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Applicability of LDAP Content Sync to loosely coupled replica sets Date: Sat, 7 Jun 2003 09:07:06 -0700 Message-ID: <6BA5A5D4255F564BBF4BF9E413BF53B801789A28@WIN-MSG-05.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Applicability of LDAP Content Sync to loosely coupled replica sets Thread-Index: AcMs6UT09gLHPyZiQCu49N0wGSCnGgAH2gsg From: "Jeff Parham" To: "Kurt D. Zeilenga" Cc: X-OriginalArrivalTime: 07 Jun 2003 16:06:47.0905 (UTC) FILETIME=[CC6DDD10:01C32D0E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h57G6uAF008826 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Thanks for your responses, Kurt -- I think this is a very valuable thread. > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Saturday, June 07, 2003 4:35 AM > To: Jeff Parham > Cc: ietf-ldup@imc.org > Subject: RE: Applicability of LDAP Content Sync to loosely coupled replica > sets > > Jeff, > > An LCUP server, in the case you describe, likely has to require > a full reload. The problem is that the entry in question may, > after changes are reconciled between the DSAs, be no longer in > the result set and that reconciliation may be done in manner to > which DSA2 never knows the entry was ever in the result set > and, hence, never is able to send the necessary delete message > for the entry. For example, the entry could have been deleted > from DSA1 shortly the client disconnected from DSA1 and yet > before the entry's creation was replicated to DSA2. Sufficient replicated history information could rectify that without requiring a reload. Or if the DSA wasn't sure if the client had previously synced the object, it could send the deletion anyway. Or it might choose to force a reload. LCUP leaves this design decision in the hands of implementers. > I don't see how LDAP-Sync is any worse off here. If LDAP Sync employs the set-diff by entryUUID method, it always requires a reload in this case. How does the DSA know to force a reload? Apparently any time the client's last sync was from a different source DSA from the replica set. That would seem to make LDAP Sync (or an LCUP implementation that always requires reloads in such a case) unsuitable for loosely coupled environments in which high availability is achieved through replication -- environments in which a client may frequently choose alternate DSAs to sync from. If LDAP Sync does not employ the set-diff by entryUUID method, then you're right: LDAP Sync is no worse than LCUP, but it's also no better -- they're essentially the same. What I'm getting at here is the ultimate viability of set-diff by entryUUID. If it's not viable in this common scenario -- and unfortunately I don't believe it is (I very much liked its promise of "no history required") -- then there's really only one proposal for client synchronization on the table. Thanks, -J From owner-ietf-ldup@mail.imc.org Sat Jun 7 21:43:25 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28419 for ; Sat, 7 Jun 2003 21:43:25 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h581V2AF039423 for ; Sat, 7 Jun 2003 18:31:02 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h581V2uS039422 for ietf-ldup-bks; Sat, 7 Jun 2003 18:31:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h581V0AF039413 for ; Sat, 7 Jun 2003 18:31:01 -0700 (PDT) (envelope-from jmcmeek@us.ibm.com) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e3.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h581UuE2119420; Sat, 7 Jun 2003 21:30:57 -0400 Received: from d27ml001.rchland.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h581Ut11156076; Sat, 7 Jun 2003 21:30:55 -0400 Subject: RE: Applicability of LDAP Content Sync to loosely coupled replica sets To: "Jeff Parham" Cc: ietf-ldup@imc.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: John McMeeking Date: Sat, 7 Jun 2003 20:30:53 -0500 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Build V602_05052003|May 05, 2003) at 06/07/2003 20:30:55 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think either of the sync proposals could be made to work with loosely coupled replicas if: 1) the replication mechanism supports something like LDUP's "update vector" -- something that indicates the latest information a replica has seen from other replicas, AND 2) the cookie contains the equivalent of an update vector, AND 3) there is a defined cookie format that is understood by the DSAs the client syncs with (possibly requested by the client) This is already described in the back of LCUP, but it applies to both sync proposals. Or did I misinterpret this discussion? [BTW - (3) is something else that is missing from draft-zeilenga-ldup-sync, but I'm almost convinced it isn't needed. Read on.] The question, then, becomes whether a given replication implementation has the information necessary to support this. I haven't thought through how either approach would handle a reload (or LDAP Sync's "entry present" messages) if the current DSA was known to be out of date with respect to the state of the original DSA at the time the client last synched with it. That might require the client know more about the replication mechanism -- server sends its update vector, client keeps any information it has that is newer than the current DSA's update vector. That starts to sound a whole lot like multi-master replication, and I don't think we want to take LCUP there. Maybe we just need the DSA to recognize that the client has more current knowledge than the DSA, and not send any updates until the DSA has caught up with the client. We may want some mechanism to tell the client the current DSA is out of date, but I don't know what the client would do about it. It doesn't hurt to provide the information, even if the client choses not to do anything with it. With multiple masters it could get more complicated - the DSA may have more current information for information updated through it (or another DSA), but be out of date with respect to changes originating at the original DSA. This seems unlikely to me, as it would seem to require that the client be syncing with differnt DSAs more frequently than replication occurs. Maybe we just accept that the client might go backwards briefly until the DSA catches up. For the DSA to not send updates until it has caught up with the client doesn't require any changes to either sync proposal. It just requires that servers provide a multi-DSA capable sync implementation. It may require that the client be able to request a particular cookie format, but I think it just requires that the DSA use a cookie format defined for the particular replication mechanism it is using. There might be one defined for LDUP, and there might be others defined by vendors for their replication implementations. John McMeeking From owner-ietf-ldup@mail.imc.org Sat Jun 7 22:16:00 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28943 for ; Sat, 7 Jun 2003 22:16:00 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h581xTAF039954 for ; Sat, 7 Jun 2003 18:59:29 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h581xTBb039953 for ietf-ldup-bks; Sat, 7 Jun 2003 18:59:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h581xSAF039948 for ; Sat, 7 Jun 2003 18:59:28 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h581xUc6028578; Sun, 8 Jun 2003 01:59:30 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030607183703.01bac888@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sat, 07 Jun 2003 18:56:28 -0700 To: "Jeff Parham" From: "Kurt D. Zeilenga" Subject: RE: Applicability of LDAP Content Sync to loosely coupled replica sets Cc: In-Reply-To: <6BA5A5D4255F564BBF4BF9E413BF53B8017895DA@WIN-MSG-05.wingro up.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: (Before responding to your latest post on with thread, I'd like to discuss this point just a bit more because it seems to be part of reason why we're disagreeing.) At 06:36 PM 6/5/2003, Jeff Parham wrote: >The key difference between LCUP and LDAP >Content Sync is the ability to assert the "member objects" without >forcing a reload. The implication is that an incremental sync can force >the client to drop previous knowledge, which seems to be the heart of >the problematic example I illustrated. LCUP doesn't have such a >mechanism; knowledge is lost only on a full reload. And previously you said: >Objects can be removed from the client only upon an LCUP full reload... These statement surprises mean because I believe LCUP because supports such a mechanism to remove objects during incremental update. However, I was re-reading the draft-ietf-ldup-lcup's appendix of features left out of LCUP and came across this statement: The leftSet feature is particularly useful because it indicates to the client that an entry is no longer within the client's search specification and the client can remove the associated data from its data store. Ironically, this feature is the hardest to implement on the server because the server does not keep track of the client's state and has no easy way of telling which entries moved out of scope between synchronization sessions with the client. A compromise could be reached by only providing this feature for the operations that occur while the client is connected to the servers. That is, this appendix implies that LCUP's entryLeftSet feature is only available during persist mode. That seems consistent with your recent comments in this thread. However, this seems quite counter to Section 4.2.7 which implies that entryLeftSet is used during incremental synchronization and the convergence guarantee implies that the server is to use this to advise the client to drop knowledge as needed. Please clarify. Kurt From owner-ietf-ldup@mail.imc.org Mon Jun 9 10:10:21 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05813 for ; Mon, 9 Jun 2003 10:10:21 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h59E1RAF080732 for ; Mon, 9 Jun 2003 07:01:27 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h59E1RgB080731 for ietf-ldup-bks; Mon, 9 Jun 2003 07:01:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from netscape.com (c3po.aoltw.net [64.236.137.25]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h59E1PAF080713 for ; Mon, 9 Jun 2003 07:01:25 -0700 (PDT) (envelope-from mcs@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h59E1Kn26128 for ; Mon, 9 Jun 2003 07:01:21 -0700 (PDT) Received: from netscape.com ([10.169.192.55]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HG7WA501.PA4; Mon, 9 Jun 2003 07:01:17 -0700 Message-ID: <3EE4932E.1090404@netscape.com> Date: Mon, 09 Jun 2003 10:01:18 -0400 From: mcs@netscape.com (Mark C Smith) Organization: Netscape Communications Corp. User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.3) Gecko/20030314 X-Accept-Language: English/United States [en-US],English [en] MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Jeff Parham , ietf-ldup@imc.org Subject: Re: Applicability of LDAP Content Sync to loosely coupled replica sets References: <5.2.0.9.0.20030607183703.01bac888@127.0.0.1> In-Reply-To: <5.2.0.9.0.20030607183703.01bac888@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: > ... However, I was re-reading the draft-ietf-ldup-lcup's > appendix of features left out of LCUP and came across this statement: > > The leftSet feature is particularly useful because it indicates to > the client that an entry is no longer within the client's search > specification and the client can remove the associated data from its > data store. Ironically, this feature is the hardest to implement on > the server because the server does not keep track of the client's > state and has no easy way of telling which entries moved out of scope > between synchronization sessions with the client. A compromise could > be reached by only providing this feature for the operations that > occur while the client is connected to the servers. > > That is, this appendix implies that LCUP's entryLeftSet feature is > only available during persist mode. That seems consistent with your > recent comments in this thread. > > However, this seems quite counter to Section 4.2.7 which implies > that entryLeftSet is used during incremental synchronization > and the convergence guarantee implies that the server is to use > this to advise the client to drop knowledge as needed. > > Please clarify. If I remember correctly, the entryLeftSet feature was not in the original LCUP proposal but was added later due to popular demand. The appendix is just out of date. At least I am pretty sure it is. I have a vague memory of asking Rich Megginson to remove some of the material from that appendix; maybe I missed this one. Note that the entryLeftSet BOOLEAN is not optional, so servers must supply a value regardless of what sync mode is in use. -Mark From owner-ietf-ldup@mail.imc.org Mon Jun 9 10:24:15 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06559 for ; Mon, 9 Jun 2003 10:24:15 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h59EIHAF083751 for ; Mon, 9 Jun 2003 07:18:17 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h59EIHnZ083750 for ietf-ldup-bks; Mon, 9 Jun 2003 07:18:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h59EIGAF083730 for ; Mon, 9 Jun 2003 07:18:16 -0700 (PDT) (envelope-from mcs@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h59EI7E03233 for ; Mon, 9 Jun 2003 07:18:07 -0700 (PDT) Received: from netscape.com ([10.169.192.55]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HG7X2803.5A4; Mon, 9 Jun 2003 07:18:08 -0700 Message-ID: <3EE49721.3080501@netscape.com> Date: Mon, 09 Jun 2003 10:18:09 -0400 From: mcs@netscape.com (Mark C Smith) Organization: Netscape Communications Corp. User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.3) Gecko/20030314 X-Accept-Language: English/United States [en-US],English [en] MIME-Version: 1.0 To: John McMeeking CC: Jeff Parham , ietf-ldup@imc.org Subject: Re: Applicability of LDAP Content Sync to loosely coupled replica sets References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John McMeeking wrote: > > > > > I think either of the sync proposals could be made to work with loosely > coupled replicas if: > 1) the replication mechanism supports something like LDUP's "update vector" > -- something that indicates the latest information a replica has seen from > other replicas, AND > 2) the cookie contains the equivalent of an update vector, AND > 3) there is a defined cookie format that is understood by the DSAs the > client syncs with (possibly requested by the client) > > This is already described in the back of LCUP, but it applies to both sync > proposals. > > Or did I misinterpret this discussion? > > [BTW - (3) is something else that is missing from draft-zeilenga-ldup-sync, > but I'm almost convinced it isn't needed. Read on.] In the past, there were very strong feelings expressed by several LDUP WG members that a defined cookie format IS needed. Assume Server A was written by Vendor A and Server B by Vendor B. Without a well defined cookie format, an LCUP client will not be able synchronize with Server A today and with Server B tomorrow without doing a full reload. While I think we are some distance away from being ready to define a standard cookie format, I do agree we will want to do so eventually. Hence the cookie scheme identifier (OID) contained in the LCUP working group deliverable. Because I interpreted the recent charge from the WG chairs and ADs as "focus on whether draft-ietf-ldup-lcup-05 has any show stopper problems" I have avoided diving into a detailed discussion of draft-zeilenga-ldup-sync. But one comment related to this cookie issue: the text in draft-zeilenga-ldup-sync leads me to believe that its "Synchronization Sessions" not only can't occur across different vendor implementations, but are restricted to one particular server instance as well. That limitation might be OK if your primary goal is to provide server to server replication, but it is unacceptable in many other scenarios. For example, I want to provide a distributed set of LDAP replicas that email clients may use to maintain offline copies of the corporate addressbook. -Mark From owner-ietf-ldup@mail.imc.org Mon Jun 9 10:29:04 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06608 for ; Mon, 9 Jun 2003 10:29:03 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h59ENhAF084140 for ; Mon, 9 Jun 2003 07:23:43 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h59ENhSh084139 for ietf-ldup-bks; Mon, 9 Jun 2003 07:23:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h59ENgAF084131 for ; Mon, 9 Jun 2003 07:23:42 -0700 (PDT) (envelope-from mcs@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h59ENWE03903 for ; Mon, 9 Jun 2003 07:23:32 -0700 (PDT) Received: from netscape.com ([10.169.192.55]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HG7XBA01.SAK; Mon, 9 Jun 2003 07:23:34 -0700 Message-ID: <3EE49867.5050305@netscape.com> Date: Mon, 09 Jun 2003 10:23:35 -0400 From: mcs@netscape.com (Mark C Smith) Organization: Netscape Communications Corp. User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.3) Gecko/20030314 X-Accept-Language: English/United States [en-US],English [en] MIME-Version: 1.0 To: Jonghyuk Choi CC: hardie@qualcomm.com, ietf-ldup@imc.org, "Kurt D. Zeilenga" Subject: Re: Is this really an LCUP show stopper? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jonghyuk Choi wrote: > > Let me take the LDAP Proxy cache as an example. It's an important > application, even though it may just add another to the examples that > make LCUP look bad. LDAP Proxy Cache caches LDAP results from LDAP servers > based on client queries. If a query is answerable from the proxy cache, > it returns LDAP result directly without contacting the server. If it's not, > it fetches results from the LDAP server and returns them to the client. > A client update protocol can be used to synchronize cached entries with > the server. Clients can request various search criteria to the LDAP > Proxy Cache > which in turn will send LCUP requests with various search criteria to > the server. > A good protocol needs be scalable and consider a wide range of the current > and also future applications. Agreed, and the proxy is a good example where flexibility is needed and where implementors will do what they do best: figure out a way to achieve their performance and scalability goals while living within the contraints of an IETF-defined protocol. My real point is that different LDAP implementators have different needs, and we need to give implementors sufficient flexibility to make appropriate engineering tradeoffs. I think draft-ietf-ldup-lcup-05 strikes a very good balance amoing a large set of competing needs; you and a Kurt at least disagree. -- Mark Smith Netscape Directory Product Development My words are my own, not my employer's. From owner-ietf-ldup@mail.imc.org Mon Jun 9 10:51:20 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07468 for ; Mon, 9 Jun 2003 10:51:20 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h59EiIAF084615 for ; Mon, 9 Jun 2003 07:44:18 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h59EiIFO084614 for ietf-ldup-bks; Mon, 9 Jun 2003 07:44:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from netscape.com (c3po.aoltw.net [64.236.137.25]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h59EiHAF084609 for ; Mon, 9 Jun 2003 07:44:17 -0700 (PDT) (envelope-from mcs@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h59EiDn01264 for ; Mon, 9 Jun 2003 07:44:13 -0700 (PDT) Received: from netscape.com ([10.169.192.55]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HG7Y9M00.AA5; Mon, 9 Jun 2003 07:44:10 -0700 Message-ID: <3EE49D3B.5010802@netscape.com> Date: Mon, 09 Jun 2003 10:44:11 -0400 From: mcs@netscape.com (Mark C Smith) Organization: Netscape Communications Corp. User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.3) Gecko/20030314 X-Accept-Language: English/United States [en-US],English [en] MIME-Version: 1.0 To: John McMeeking CC: ietf-ldup@imc.org Subject: Re: Is this really an LCUP show stopper? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John McMeeking wrote: > > > > > My two bits worth: > > I favor the LDAP Sync approach over LCUP. This is largely because changes > to LDAP Sync appear to make LCUP a valid implementation of LDAP Sync, and > it doesn't appear that LDAP sync would be significantly harder to > implement, from either the server or client perspective. I think a very careful reading of the two drafts does expose some important differences (and I admit I need to spend some more time carefully reading draft-zeilenga-ldup-sync-02.txt). But I generally agree that LDAP Sync includes much of what makes LCUP a good proposal. > As I understand it, this discussion basically boils down to how a client > finds out that an entry has left the result set and whether that imposes > undo requirements on an implementation or results in excessive network > traffic. The choices being: > > 1. Server sends "entry deleted" messages -- LCUP or LDAP Sync -- server > must maintain history > > 2. Server sends "entry present" messages for all entries in result set, > client determines what is gone -- LDAP Sync -- no history required > > 3. Reload required -- LCUP or LDAP Sync -- server doesn't have the > necessary history, or changes are "too big" > > It seems to me that all these will all result in the client having the same > content, so I don't see an issue with either approach not working. Agreed, for some value of "working." As the recent discussions have shown, different approaches may work better in different situations (most involve a tradeoff between implementation complexity and performance or wire traffic). > I think the notion of maintaining a history so that a server can send > "entry deleted" messages is important. Synchronizing a 100,000 entry > directory with no (or limited) changes by sending 1000,000 entry present > messages seems like poor behavior. I believe that change to LDAP Sync was > needed. > > It seems that LCUP could be implemented using LDAP Sync extended ops and > controls. A server implementation could always choose between options 1 > and 3. And I think that would be a valid implementation of LDAP Sync. The > client, of course, would have to work properly with option 2, which might > make testing the client problematic if the client and server vendors are > the same. Similarly, a server implementation could choose to always use > options 2 and 3. This is where we need to be careful. I am not convinced that option 2 is a good idea, at least not for the kinds of applications I have in mind. My guess -- and I admit this is only a guess -- is that the real thinking behind the addition of the refreshDeletes option in draft-zeilenga-ldup-sync-02.txt was to try to position LDAP Sync as a superset of LCUP, with the hope being that those who support LCUP will also support LDAP Sync. But I am not convinced we should shift implementation complexity to the client, and increase the on the wire traffic, by allowing server implementors to ignore the option 1 you describe above. It will simply be too easy for them to provide a really poor implementation of "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." And then the protocol will not be widely adopted by client implementors, and then we will have solved no important problems. > I don't think that either LDAP Sync or LCUP will be significantly harder to > implement (either server or client side) if one accepts the notion that > some history is desirable. As stated earlier, I think that history is > necessary to a well-behaved synchronization mechanism. Which is why I for one have no problem (and believe it may in fact be a good idea) to encourage reasonable implementations to store some history. > I have not been able to come to any firm position on the need (or lack > thereof) for the "entry present" mechanism. It is clear that if the data > being synchronized is "large", and a change to entries and / or meta-data > results in a situation where the server knows that the content of entries > visible to the client has not changed, and a large number of entries has > potentially left the result set (without any equally large number of > entries entering the result set), that sending "entry present" results will > take less bandwidth than resending entire entries. It is far from clear to > me how likely such scenarios are. One case where the "entry present" > mechanism does work well is when a client synchronizes infrequently with > resect to the deleted/moved entry history maintained by the server. > > I suspect either method will be sensitive to certain classes of changes > (most likely access control or group membership) that will result in some > clients being reloaded even though the net content change on the client is > small -- just too hard to figure out the delta. Fair comments. It is certainly possible we are overthinking things in this entire area. Implementation experience has already been fed back into LCUP, and more of that will happen in the future. -- Mark Smith Netscape Directory Product Development My words are my own, not my employer's. From owner-ietf-ldup@mail.imc.org Mon Jun 9 10:58:35 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07714 for ; Mon, 9 Jun 2003 10:58:35 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h59EqOAF084765 for ; Mon, 9 Jun 2003 07:52:24 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h59EqOam084764 for ietf-ldup-bks; Mon, 9 Jun 2003 07:52:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h59EqMAF084758 for ; Mon, 9 Jun 2003 07:52:23 -0700 (PDT) (envelope-from jongchoi@us.ibm.com) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e4.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h59EqHsZ150488; Mon, 9 Jun 2003 10:52:17 -0400 Received: from d01ml233.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h59EqGNM109044; Mon, 9 Jun 2003 10:52:16 -0400 To: "Jeff Parham" Cc: ietf-ldup@imc.org, "Kurt D. Zeilenga" MIME-Version: 1.0 Subject: RE: Applicability of LDAP Content Sync to loosely coupled replica sets X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Jonghyuk Choi Date: Mon, 9 Jun 2003 10:52:12 -0400 X-MIMETrack: Serialize by Router on D01ML233/01/M/IBM(Release 6.0.1 [IBM]|June 3, 2003) at 06/09/2003 10:52:16, Serialize complete at 06/09/2003 10:52:16 Content-Type: multipart/alternative; boundary="=_alternative 0051AA6085256D40_=" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0051AA6085256D40_= Content-Type: text/plain; charset="us-ascii" Jeff, >Sufficient replicated history information could rectify that without >requiring a reload. Or if the DSA wasn't sure if the client had >previously synced the object, it could send the deletion anyway. Or it >might choose to force a reload. LCUP leaves this design decision in the >hands of implementers. When full reload is chosen, LCUP has the same problem. The client sees the entry added to DSA1 when it synced with DSA1, but will not see the entry after it syncs with DSA2 via full reload. If it is not allowed to lose forward progress in consistency, a possible approach would be to not remove entries previously not seen from a DSA when a client syncs with the DSA. For example, the client does not delete the newly added entry in DSA1 when it syncs with DSA2, because it never received the entry from DSA2. This can be used both for LDAP-Sync and for LCUP in the full reload mode. - Jong "Jeff Parham" Sent by: owner-ietf-ldup@mail.imc.org 06/07/2003 12:07 PM To: "Kurt D. Zeilenga" cc: Subject: RE: Applicability of LDAP Content Sync to loosely coupled replica sets Thanks for your responses, Kurt -- I think this is a very valuable thread. > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Saturday, June 07, 2003 4:35 AM > To: Jeff Parham > Cc: ietf-ldup@imc.org > Subject: RE: Applicability of LDAP Content Sync to loosely coupled replica > sets > > Jeff, > > An LCUP server, in the case you describe, likely has to require > a full reload. The problem is that the entry in question may, > after changes are reconciled between the DSAs, be no longer in > the result set and that reconciliation may be done in manner to > which DSA2 never knows the entry was ever in the result set > and, hence, never is able to send the necessary delete message > for the entry. For example, the entry could have been deleted > from DSA1 shortly the client disconnected from DSA1 and yet > before the entry's creation was replicated to DSA2. Sufficient replicated history information could rectify that without requiring a reload. Or if the DSA wasn't sure if the client had previously synced the object, it could send the deletion anyway. Or it might choose to force a reload. LCUP leaves this design decision in the hands of implementers. > I don't see how LDAP-Sync is any worse off here. If LDAP Sync employs the set-diff by entryUUID method, it always requires a reload in this case. How does the DSA know to force a reload? Apparently any time the client's last sync was from a different source DSA from the replica set. That would seem to make LDAP Sync (or an LCUP implementation that always requires reloads in such a case) unsuitable for loosely coupled environments in which high availability is achieved through replication -- environments in which a client may frequently choose alternate DSAs to sync from. If LDAP Sync does not employ the set-diff by entryUUID method, then you're right: LDAP Sync is no worse than LCUP, but it's also no better -- they're essentially the same. What I'm getting at here is the ultimate viability of set-diff by entryUUID. If it's not viable in this common scenario -- and unfortunately I don't believe it is (I very much liked its promise of "no history required") -- then there's really only one proposal for client synchronization on the table. Thanks, -J --=_alternative 0051AA6085256D40_= Content-Type: text/html; charset="us-ascii"
Jeff,

>Sufficient replicated history information could rectify that without
>requiring a reload.  Or if the DSA wasn't sure if the client had
>previously synced the object, it could send the deletion anyway.  Or it
>might choose to force a reload.  LCUP leaves this design decision in the
>hands of implementers.

When full reload is chosen, LCUP has the same problem.
The client sees the entry added to DSA1 when it synced with DSA1,
but will not see the entry after it syncs with DSA2 via full reload.

If it is not allowed to lose forward progress in consistency,
a possible approach would be to not remove entries previously
not seen from a DSA when a client syncs with the DSA.
For example, the client does not delete the newly added entry in DSA1
when it syncs with DSA2, because it never received the entry from DSA2.

This can be used both for LDAP-Sync and for LCUP in the full reload mode.

- Jong



"Jeff Parham" <jeffparh@windows.microsoft.com>
Sent by: owner-ietf-ldup@mail.imc.org

06/07/2003 12:07 PM

       
        To:        "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
        cc:        <ietf-ldup@imc.org>
        Subject:        RE: Applicability of LDAP Content Sync to loosely coupled    replica sets




Thanks for your responses, Kurt -- I think this is a very valuable
thread.

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
> Sent: Saturday, June 07, 2003 4:35 AM
> To: Jeff Parham
> Cc: ietf-ldup@imc.org
> Subject: RE: Applicability of LDAP Content Sync to loosely coupled
replica
> sets
>
> Jeff,
>
> An LCUP server, in the case you describe, likely has to require
> a full reload.  The problem is that the entry in question may,
> after changes are reconciled between the DSAs, be no longer in
> the result set and that reconciliation may be done in manner to
> which DSA2 never knows the entry was ever in the result set
> and, hence, never is able to send the necessary delete message
> for the entry.  For example, the entry could have been deleted
> from DSA1 shortly the client disconnected from DSA1 and yet
> before the entry's creation was replicated to DSA2.

Sufficient replicated history information could rectify that without
requiring a reload.  Or if the DSA wasn't sure if the client had
previously synced the object, it could send the deletion anyway.  Or it
might choose to force a reload.  LCUP leaves this design decision in the
hands of implementers.

> I don't see how LDAP-Sync is any worse off here.

If LDAP Sync employs the set-diff by entryUUID method, it always
requires a reload in this case.  How does the DSA know to force a
reload?  Apparently any time the client's last sync was from a different
source DSA from the replica set.  That would seem to make LDAP Sync (or
an LCUP implementation that always requires reloads in such a case)
unsuitable for loosely coupled environments in which high availability
is achieved through replication -- environments in which a client may
frequently choose alternate DSAs to sync from.

If LDAP Sync does not employ the set-diff by entryUUID method, then
you're right: LDAP Sync is no worse than LCUP, but it's also no better
-- they're essentially the same.

What I'm getting at here is the ultimate viability of set-diff by
entryUUID.  If it's not viable in this common scenario -- and
unfortunately I don't believe it is (I very much liked its promise of
"no history required") -- then there's really only one proposal for
client synchronization on the table.

Thanks,
-J

--=_alternative 0051AA6085256D40_=-- From owner-ietf-ldup@mail.imc.org Mon Jun 9 11:01:45 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07897 for ; Mon, 9 Jun 2003 11:01:44 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h59EsxAF084821 for ; Mon, 9 Jun 2003 07:54:59 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h59Esx8x084820 for ietf-ldup-bks; Mon, 9 Jun 2003 07:54:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from netscape.com (c3po.aoltw.net [64.236.137.25]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h59EswAF084813 for ; Mon, 9 Jun 2003 07:54:58 -0700 (PDT) (envelope-from mcs@netscape.com) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h59Esrn02695 for ; Mon, 9 Jun 2003 07:54:54 -0700 (PDT) Received: from netscape.com ([10.169.192.55]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HG7YRF00.MAA; Mon, 9 Jun 2003 07:54:51 -0700 Message-ID: <3EE49FBC.50603@netscape.com> Date: Mon, 09 Jun 2003 10:54:52 -0400 From: mcs@netscape.com (Mark C Smith) Organization: Netscape Communications Corp. User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.3) Gecko/20030314 X-Accept-Language: English/United States [en-US],English [en] MIME-Version: 1.0 To: John McMeeking CC: ietf-ldup@imc.org Subject: Re: Comments on lcup-05 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John McMeeking wrote: > > Here's some comments on draft-ietf-ldup-lcup-05.txt: > > 1. Overview - paragraph on state information. I would resatate this > something like: "... the server does not need to maintain state information > specific to individual clients. The server may need to maintain additional > state information about deleted or moved/renamed entries." That sounds like an improvement to me. > 3.5 (all controls). All these controls have a significant number of > optional fields. I think we should add tags to simplify proper decoding of > the control data. Also, given recent discussions about ASN.1 tagging, it > would be appropriate to state that implicit tagging is used (if it is). I don't have a problem with adding tags, although whether that really simplifies decoding of optional elements might depend on what kind of BER decoder you have... having tags might make things more bulletproof though. > 4.2.7 Result for Entries that have left the result set. There are two "An > entry SHOULD be returned as having left...." clauses. It appears the > second one is left over from a rewrite, as it repeats information in 4.2.5. > This would make it more consistent with 4.2.6. Good catch. > 4.3.4/4.3.5. I think the server should be given the option of rejecting a > LCUP search that includes virtual or collective attributes. If a server > would normally return these attributes, it must either properly synchronize > these attributes or reject the search request. Maybe a new > "lcupInvalidAttribute" or "unwillingToPerform" resultCode would be > appropriate. It is important to encourage server implementors to support synchronization of virtual attributes. The problem I see is that if we allow servers to reject such requests, clients will be completely out of luck. I think this change requires more discussion. > 4.4.1 Server Initiated Termination. This para references a > lcupClientDisconnected resultCode. I didn't see that resultCode defined. I think that should be replaced with the canceled response code from zeilenga-ldap-cancel. > 4.5 This can probably be deleted, > though it might be helpful earlier to explain what the synchronize and > persist phases do and the sequence of requests/controls. Agreed. I think I advised Rich to remove section 4.5. Not sure why that did not happen... an oversight I suspect. Thanks for your detailed comments! -Mark From owner-ietf-ldup@mail.imc.org Thu Jun 12 18:32:17 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00085 for ; Thu, 12 Jun 2003 18:32:17 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CMNLrb084264 for ; Thu, 12 Jun 2003 15:23:21 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5CMNLss084263 for ietf-ldup-bks; Thu, 12 Jun 2003 15:23:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from echt.caledonia.net (echt.caledonia.net [207.40.197.226]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CMNGrb084255 for ; Thu, 12 Jun 2003 15:23:18 -0700 (PDT) (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (dpvc-141-152-21-16.rich.east.verizon.net [141.152.21.16]) by echt.caledonia.net; Thu, 12 Jun 2003 16:22:33 -0600 Reply-To: From: "Chris Apple" To: , , Cc: "'Kurt D. Zeilenga'" , "'John Strassner'" , Subject: RE: Request to Reschedule LCUP WG Last Call Milestone Date: Thu, 12 Jun 2003 18:22:04 -0400 Organization: DSI-Consulting, Inc. Message-ID: <00ce01c33131$1d539000$3d00000a@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <00cd01c326e8$799630a0$6500a8c0@D7ST2111> Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I have been largely out of e-mail contact for the past few days due to a POP3 server failure during a migration of my company's e-mail system. John and I will issue the statement of consensus on this matter on Friday, May 13, 2003. Keeping with the durations below, this would mean that the Next step (either proceeding with WG Last Call or requesting More time to evaluate both proposals thoroughly from a technical Perspective) will take place on Monday, June 16, 2003. I apologize to all for this delay. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] On Behalf Of Chris Apple Sent: Friday, May 30, 2003 4:17 PM To: ietf-ldup@imc.org; hardie@qualcomm.com Cc: 'Kurt D. Zeilenga'; 'John Strassner'; ned.freed@mrochek.com Subject: RE: Request to Reschedule LCUP WG Last Call Milestone Ted, Thanks for the response. WG Members, Per Ted's response below, the WG Last Call for LCUP is now rescheduled to take place on Jun 12, 2003. With regard to Kurt's proposal, the discussion period on considering it will extend through 1700 US ET on June 10, 2003. Please also take note of the point Ted makes in his response about identifying showstopper issues with the existing LCUP document. If you believe any exist, you should describe them in plain language on the mailing list. John and I will issue a summary statement of WG consensus established during this discussion period on June 11, 2003. The next step will either be to proceed with WG Last Call for LCUP as previously planned or to request additional milestone and possibly charter text changes based on the consensus to accommodate an alternate course of direction such as that described in Kurt's proposal. Specifically how we will proceed as a WG depends on the discussion posted to the mailing list through the deadline established above. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: hardie@qualcomm.com [mailto:hardie@qualcomm.com] Sent: Friday, May 30, 2003 1:26 PM To: capple@dsi-consulting.net; ned.freed@mrochek.com Cc: ietf-ldup@imc.org; 'Kurt D. Zeilenga'; John Strassner Subject: Re: Request to Reschedule LCUP WG Last Call Milestone Folks, While I appreciate the efforts of all involved to make this an open process, I am concerned about this slip in dates. LDUP has already been on this track a long, long time. I will agree to the date for initiation of working group last call moving from "May 2003" to a date 2 weeks from May 27, 2003, when the Chairs issued the call to the working group asking for explicit comments on Kurt's proposal to reconsider. Since this is the period of a usual last call, this seems to me to give adequate time to raise issues (even if not to resolve them). If there has been substantial comment by that time indicating either 1) the working group has come to consensus that it should reconsider its current decision or 2) there are "show-stopper" class problems with the existing specification, then further delay can be discussed. Without either of those being present, though, a delay which would push the initiation of working group last call past the Vienna meeting seems unwarranted. I am particularly concerned that this means any drafts responding to issues raised during last call will have to be distributed informally, rather than via the i-d directories, and I urge the chairs to take advantage of the ability to pre-populate meeting materials as a way of limiting this disadvantage. If a further delay is needed, a concise description of the technical issues which led to reconsideration of working group consensus or which stopped the show on the existing draft should be composed by the working group as a note to the IESG on the delay. I would expect those proposing the delay (Kurt, in this case, and those supporting his view) would take the lead in providing that text. regards, Ted Hardie At 12:12 PM -0400 5/29/03, Chris Apple wrote: >Ted & Ned, > >John and I are requesting that the milestone date for >LDUP's WG Last Call for the LCUP deliverable be rescheduled >to accommodate consideration of Kurt's recent proposal >to the WG. > >Here is a link to the original posting made by Kurt: > >http://www.imc.org/ietf-ldup/mail-archive/msg01754.html > >Here is a link to a reply from Kurt indicating his >agreement with a summarized version of his request >posted by myself to the WG mailing list: > >http://www.imc.org/ietf-ldup/mail-archive/msg01771.html > >My best guess for how long it will take us to establish >consensus on proceeding as Kurt suggests, as the current >charter indicates, or on some other way of proceeding >would be near the end of June 2003. > >If consensus is established for supporting Kurt's proposal >and the WG needs to compare, contrast, and discuss the merits >of either approach to emerge with one document, I estimate >that this might take an additional 2 - 3 months putting the >WG Last Call for LCUP somewhere in the Sep-2003 or Oct-2003 >time frame. > >If consensus is re-established for staying with the course >that the WG has included in its charter, we should be >able to initiate WG Last Call no later than July-2003. > >I do not know what to say about consensus for some other >course of action because the only other one that's been >suggested on the mailing list to date is that neither >proposal should be progressed if there is insufficient >interest expressed in them. So far no one else has >agreed with that position. > >So, I think the most prudent action would be to slip >the WG Last Call date for LCUP to July 2003 to enable >us to consider Kurt's proposal. If consensus is >established on following it, we could request another >milestone date change to accommodate the amount of work >we believe there is going to be in evaluating the two >proposals and settling on one. > > >Chris Apple - Principal Architect > >DSI Consulting, Inc. > >mailto:capple@dsi-consulting.net > >http://www.dsi-consulting.com From owner-ietf-ldup@mail.imc.org Fri Jun 13 16:04:11 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21443 for ; Fri, 13 Jun 2003 16:04:09 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5DJmCrb070109 for ; Fri, 13 Jun 2003 12:48:12 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5DJmCCw070108 for ietf-ldup-bks; Fri, 13 Jun 2003 12:48:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from tconl91223.tconl.com (tconl91223.tconl.com [204.26.91.223]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5DJm9rb070085 for ; Fri, 13 Jun 2003 12:48:10 -0700 (PDT) (envelope-from jayhawk@tconl91223.tconl.com) Received: (from jayhawk@localhost) by tconl91223.tconl.com (8.11.6/8.11.0) id h5DJm4B04330 for ietf-ldup@imc.org; Fri, 13 Jun 2003 14:48:04 -0500 Date: Fri, 13 Jun 2003 14:48:04 -0500 From: Ryan Moats To: ietf-ldup@imc.org Subject: interim infomod draft and some technical questions for the mailing list Message-ID: <20030613144804.D3926@privateer.local.windrose.omaha.ne.us> Reply-To: rmoats@lemurnetworks.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Having had my cage rattled, I'm attaching an *interim* draft of infomod. The authors are still working on it, but two rather large questions have come up that I'd like to bring to the list and reach consensus on: 1) Who has client implementations use root DSE attributes? There are several root DSE attributes that seem redundant, but before axing, let's make sure there aren't existing implementations that plan on using them. 2) This interim draft also has changes in it to explicitly allow multiple replicas at the same DN. This is a definite shift and this is to let the working group reach consensus. Ryan (for the authors) ============== Internet Draft Richard Huber Document: draft-ietf-ldup-infomod-07.txt AT&T Laboratories Expires: December 2003 John McMeeking IBM Ryan Moats Lemur Networks June 2003 LDUP Replication Information Model draft-ietf-ldup-infomod-07c.txt 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft expires March, 2002. 2. Abstract [LDUP Model] describes the architectural approach to replication of LDAP directory contents. This document describes the information model and schema elements which support LDAP Replication Services which conform to [LDUP Model]. Directory schema is extended to provide object classes, subentries, and attributes to describe areas of the namespace which are under common administrative authority, units of replication (i.e., subtrees, or partitions of the namespace, which are replicated), servers which hold replicas of various types for the various partitions of the namespace, which namespaces are held on given servers, and the progress of various namespace management and replication operations. Among other things, this knowledge of LDUP Information Model where directory content is located will provide the basis for dynamic generation of LDAP referrals for clients who can follow them. The controlling framework by which the relationships, types, and health of replicas of the directory content will be defined so that, as much as possible, directory content is itself used to monitor and control the environment. Security information, including access control policy identifiers and information will be treated as directory content by the replication protocols when specified by the LDAPEXT group. The information model will describe required and optional house- keeping duties for compliant systems to implement, such as garbage collection of deleted objects, reconciliation of moved and renamed objects, update sequencing and transaction bracketing of changes, etc. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. The sections below reiterate these definitions and include some additional ones. LDUP Information Model 3. Table of Contents 1. Status of this Memo ...........................................1 2. Abstract ......................................................1 3. Table of Contents .............................................3 4. Recent document changes .......................................6 5. Introduction ..................................................8 5.1. Scope ......................................................8 5.2. Terms and Definitions ......................................8 6. Data design ...................................................8 7. Directory Knowledge ...........................................8 8. Schema ........................................................9 8.1. Data Structure Definitions .................................9 8.1.1. LdapChangeSequenceNumber ................................10 8.2. Attribute Definitions .....................................11 8.2.1. supportedReplicationProtocols ...........................11 8.2.2. replicaSubentries .......................................12 8.2.3. attributeExclusionFilter ................................12 8.2.4. attributeInclusionFilter ................................13 8.2.5. replicaURI ..............................................13 8.2.6. replicationStatus .......................................14 8.2.7. replicaType .............................................15 8.2.8. updateVector ............................................16 8.2.9. replicaSecondaryURI .....................................16 8.2.10. lostAndFoundEntryDN .....................................16 8.2.11. replicaOnline ...........................................16 8.2.12. replicaDN ...............................................17 8.2.13. replicationMechanismOID .................................17 8.2.14. replicationCredentialsDN ................................17 8.2.15. replicationScheduleDN ...................................18 8.2.16. updateVectorTrigger .....................................18 8.2.17. secondsToWaitDefault ....................................19 8.2.18. secondsToWait1 ..........................................19 8.2.19. attrReplicationGroup1 ...................................19 8.2.20. secondsToWait2 ..........................................20 8.2.21. attrReplicationGroup2 ...................................20 8.2.22. scheduleTimePeriod ......................................20 8.2.23. scheduleMonthOfYearMask .................................21 8.2.24. scheduleDayOfMonthMask ..................................21 8.2.25. scheduleDayOfWeekMask ...................................21 8.2.26. scheduleTimeOfDayMask ...................................21 8.2.27. scheduleLocalOrUtcTime ..................................22 8.3. Class Definitions .........................................22 8.3.1. ReplicationContext ......................................22 8.3.2. replicaSubentry .........................................22 8.3.3. replicaAgreement ........................................24 LDUP Information Model 8.3.4. replicaEventSchedule ....................................25 8.3.5. replicaTimeSchedule .....................................26 9. Semantics of the information model ...........................27 10. Object Identifier Assignments ..............................30 11. Security Considerations ....................................32 12. Copyright Notice ...........................................33 13. Acknowledgements ...........................................34 14. Authors' Addresses .........................................34 LDUP Information Model 4. Recent document changes Changes in this version - Explicitly change replicaAgreement to not be a subentry. - Explicitly allow multiple replicaSubentries per replicaContext - Added replicaDN to examples. Changes made to previous versions - Fixed OID values to have correct prefix: 2.16.840.1.113719.1.142 - Fixed formatting to avoid strange single quote characters in text formatted file - Changed name of attrs1 and attrs2 to attrReplicationGroup1 and attrReplicationGroup2 - Made obsolete timeScheduledSubentry and eventScheduledSubentry - Re-based replicaSubEntry and other object classes on subentry schema from draft-zeilenga-ldap-subentry-00.txt - Clarified that root DSE attribute replicaSubentries should be automatically updated on both add and delete of these entries - Made obsolete replicaSubEntry and replicaAgreementSubentry object classes - Defined replacement object classes replicaSubEntry2 and replicaAgreementSubentry2 - Defined replicaEventSchedule and replicaTimeSchedule object classes and associated attributes - Defined attributes that must appear in the server's root DSE entry as part of the LDUP information model - Many editorial fixes - Clarified the notion that the updateVector is a replicated attribute and thus, itself, has CSN information for its attribute values - Introduced the notion that replicaAgreementSubentry entries represent constraints to what is, by default, "immediate" replication session initiation - LDAP Schedule Subentry definition is defined. - LDAP Access Point removed in favor of just using the DN of the server holding the replica (so a new syntax isn't required). - LDAP Change Sequence Number syntax eliminated in favor of just calling it a CaseIgnoreString, so new comparison rules aren't required. - Deleted ldapSearchFilter definition from here. Sparse replicas is deferred. Might sparse be supported for single- master configurations (read-only, of course). - Fractional are okay in multi-master configurations, but again, only on read-only replicas. - Changed the naming convention upper-lower case usage to look less weird. - Consistency discussion - Schema document must clearly indicate that clients can and should inspect the replica subentries to understand the LDUP Information Model single-master/multi-master nature of the naming context to which they're talking. - The paradigm change, to distributed data, needs to be exhaustively discussed in the profile documents. How old applications which assume single-master behave or misbehave in a multi-master environment is critical to make clear. Draw examples from SMP pre-emptive programming practices, from DNS vs. host file models, etc. - To do: - verify LDUP OID number(s) with Novell - verify all OIDs assigned - verify all OIDs documented at the end of the document LDUP Information Model 5. Introduction 5.1. Scope This document describes schema for information used to control replication. Management and status schema elements are defined. Semantic interpretation of schema elements, including any special handling expectations are to be provided here. 5.2. Terms and Definitions Definitions are provided in [LDUP Requirements]. 6. Data design As described in [LDUP Model], knowledge of replicated portions of the directory information tree (DIT) is stored in the directory itself. An auxiliary class is defined to designate containers, or nodes, in the DIT which are the root-most, or base, of replication contexts. Directory subentries [LDAP Subentry] are used to hold information about replicas and replica agreements. In defining the replication agreement data model, describing the constraints under which replication between two replicas will occur, this document describes only the least set of information necessary to ensure interoperability between implementations. The current document defines data elements sufficient to describe most common replication needs. The specification of complex replication agreements and constraints is better served by usage of the emerging "policy model" [Policy schema]. 7. Directory Knowledge Information about what replicas exist, what they contain, their types, where they are stored, and how they may be contacted inevitably provides the basis for distributed directory knowledge. As namespaces from stand-alone servers are inter-connected with one another, this replica information can and will be used by name resolution operations to locate servers holding copies of specific objects, and to optimize distributed searches which span multiple Naming Contexts. However, the focus of this document is NOT to fully enable such distributed directory uses. Instead, we are focused on how portions of the namespace (Directory Information Tree - DIT) may be LDUP Information Model replicated, and how those replicas are configured and related to one another via Replication Agreements. As such, the following high level description (from [LDUP Model]) of the information model envisioned is provided as reference for the reader before presenting the detailed specifications. Generally, the DSE Naming Context attribute of an LDAPv3 server names the Naming Contexts for which there are replicas on that server. The Replication Context Auxiliary Class (replicationContext) is added to container objects which may have separately defined replication policy. Immediately subordinate to a Replication Context object are the Replica Subentry containers which identify where the identified replica resides (i.e., its LDAP Access Point), its type (Primary, Updateable, ReadOnly), if it is sparse, the LDAP search filter which defines what object classes it holds, and if it is fractional, the attributes it does or does not hold. Immediately subordinate in the namespace to a Replica Subentry are Replication Agreement leaf entries which each identify another Replica, the scheduling policy for replication operations (including times when replication is to be performed, when it is not to be performed, or the policies governing event-driven replication initiation). These Replication Agreements are used to specify constraints on when the replica will supply what changes to the "pointed to" other replica, as either the replication initiator or responder. Replication Agreements are not defined to cover the following advanced policy characteristics: - when a replica would allow consumers to request a replication session - when a replica would allow suppliers to start a replication session - when a replica would request a replication session from a supplier. These advanced policy specifications imply the specification of complex replication agreements and constraints. This is better served by usage of the emerging "policy model" [Policy schema]. Interoperable policies for replication agreements is left as a follow-on work effort. 8. Schema 8.1. Data Structure Definitions LDUP Information Model For the purposes of defining the encoding rules for attribute structures, the BNF definitions in section 4.1 of [RFC2252] will be used. They are based on the BNF styles of [RFC822]. To avoid requiring new syntax support to be added unnecessarily to existing LDAPv3 directory service implementations (and the accompanying matching rules, etc. they would entail), a string encoding is defined for ldapChangeSequenceNumber which can use CaseIgnoreString matching rules for ordering and equality. 8.1.1. LdapChangeSequenceNumber ( 1.3.6.1.4.1.1466.115.121.1.TBD DESC 'LDAP Change Sequence Number' ) Values in this syntax are encoded according to the following BNF. Note there MUST NOT be any white space separators, unless they are in replicaID, which must be encoded according to the instructions below. This encoding is specified so that the CaseIgnoreString equality and ordering rules will work correctly when replicaNumber is used. When replicaID is used, CaseIgnoreString comparison rules will not work unless each replicaID is exactly the same length with no padded white spaces (because CaseIgnoreString suppresses duplicate adjacent white space when it compares two strings). LDAPChangeSequenceNumber = GeneralizedZTime "#" \ S1 "#" replicaID "#" S2 GeneralizedZTime = yyyy | mm | dd | hh | mi | ss | "Z" yyyy = dddd mm = dd dd = dd hh = dd mi = dd ss = dd replicaID = dstring S1, S2 = numericstring The GeneralizedTime is used as described (cf. [X680] section 39.3 case b) without separators or white space, and representing a coordinated universal time (i.e., Greenwich Mean Time, or GMT). All times referenced by this syntax MUST be normalized to GMT - no local times, nor time zone offsets are permitted. To simplify LDUP Information Model comparisons of two CSNs, the "Z" MUST be the UTF-8 capital-Z character. The ReplicaID represents the specific Replica of this Naming Context where the event associated with this LDAPChangeSequenceNumber occurred. Note that in actual transfer, the replicaID MAY be represented by a number which is associated with the entryUUID of the replicaSubEntry associated with the replica (see the specification of the replicaIDTable in [LDUP Update Protocol]). When associated with an item of information within a replica, the replicaID should be traceable to the entryUUID of the replicaSubEntry associated with the replica on which the modification was made. This allows for compressed internal storage of change sequence numbers while still ensuring that change sequence numbers will be universally unique regardless of the replication context from which they were first produced. S1 and S2 are sequence numbers which are used to order two events with the same Generalized Time and replicaID. In order to use string matching rules for equality and ordering with values with this encoding, the length of each field must be consistent. Thus, all instances of S1 MUST be represented with the same number of digits, using leading zeros as necessary. The same with S2 and replicaID. 8.2. Attribute Definitions 8.2.1. supportedReplicationProtocols ( 2.16.840.1.113719.1.142.4.x NAME 'supportedReplicationProtocols' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 EQUALITY caseIgnoreMatch DESC 'set of OIDs which represent the (set of) protocols supported by this server' ) This attribute is added to the root DSE entry of servers which support replication as defined by [LDUP Model]. {THIS IS NOT TRUE SINCE WE ALLOW MULTIPLE REPLICAS ROOTED AT THE SAME REPLICATION CONTEXT. DO WE JUST REMOVE THIS PARAGRAPH, OR DO WE REQUIRE THAT JOHN - RYAN AND RICK CAN'T SEE ANY REASON TO KEEP THIS; IT DOESN'T THE SERVER CHECK (HOW?) SOME SORT OF _REFERENCE SEEM USEFUL SINC COUNT_ AND DELETE A GIVEN CONTECT FROM REPLICACONTEXTROOTS ONLY E YOU CAN ALWAYS FIND REPLICA ROOTS BY SEARCHING FOR replicaSubentry AS AN OBJECTCLASS. IS THIS REQUIRED FOR X.500 WHEN ALL REPLICAS WITH THAT ROOT CONTEXT HAVE BEEN REMOVED? OR SOMETHING?} 8.2.2. replicaSubentries ( 2.16.840.1.113719.1.142.4.x NAME 'replicaSubentries' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch DESC 'names of all replicaSubEntry entries that correspond to the replicas on this server. This is contrasted with the replicaContextRoots which notes the replication LDUP Information Model contexts, but not the replicaSubEntry sub-entries for this server within the replication context' ) This attribute in the root DSE entry names the replicaSubentry entries that correspond to the replicas that are held on "this" server. This is slightly different than the replicaContextRoots root DSE entry attribute which lists the replication contexts held on this server. The replicaSubentries attribute indicates "this" server's replicaSubentry entry within each replication context. When replicas are defined on the server, servers MUST add the name of the replicaSubentry representing "this" server to this root DSE attribute. When replicas are removed from the server, servers MUST remove the name from this root DSE attribute if a value exists in this root DSE attribute. {IS THIS CONSISTENT WITH MRM? THIS SAYS THAT THE SERVER MUST MANAGE THIS ENTRY. IS THIS REALLY USEFUL?? SHOULD WE DELETE?} 8.2.3. attributeExclusionFilter ( 2.16.840.1.113719.1.142.4.1 NAME 'attributeExclusionFilter' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE USAGE dSAOperation ) The attributeExclusionFilter is intended to contain a list of attributes in the form of an AttributeDescriptionList as described in section 4.5.1 Search Request of [RFC2251] with the following interpretation: an empty attributeExclusionFilter means that no attributes are excluded; the special values "*" and "1.1" mean that ALL attributes are excluded. A non-empty attributeExclusionFilter attribute on a replica subentry describes the attributes NOT PRESENT on entries held by that replica. Replicas MUST NOT accept changes for attributes they're not permitted to hold, per the attributeInclusionFilter and attributeExclusionFilter attributes on their replica subentry. A non-empty attributeExclusionFilter attribute on a replication agreement subentry describes which additional attributes are to be excluded from the updates to be sent from the supplier replica to the consumer replica. 8.2.4. attributeInclusionFilter ( 2.16.840.1.113719.1.142.4.2 NAME 'attributeInclusionFilter' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE USAGE dSAOperation ) The attributeInclusionFilter is intended to contain a list of attributes in the form of an AttributeDescriptionList as described LDUP Information Model in section 4.5.1 Search Request of [RFC2251] with the following interpretation: an empty attributeInclusionFilter means that all attributes are included; the special value "*" means that ALL attributes are included; the special value "1.1" is meaningless and is ignored in this usage. A non-empty attributeInclusionFilter attribute on a replica subentry describes the attributes that may be PRESENT on entries held by that replica. Replicas MUST NOT accept changes for attributes they're not permitted to hold, per the attributeInclusionFilter and attributeExclusionFilter attributes on their replica subentry. It is an error to specify both an attributeExclusionFilter and an attributInclusionFilter in the same replicaSubentry. 8.2.5. replicaURI ( 2.16.840.1.113719.1.142.4.x NAME 'replicaURI' DESC 'LDAP URLs which indicate how to connect to this replica' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 EQUALITY caseExactMatch USAGE dSAOperation ) The replicaURI attribute is a multi-valued attribute used to list the set of LDAP URLs that should be used to contact the replica for replication sessions. If all URLs in the replicaURL attribute are not contactable, the replicaSecondaryURL attribute values should be used to establish a replication session with the replica. The replicaURI MUST be an LDAP URL as specified in RFC 2255. The replicaURI SHOULD specify only the host name (or IP address) of the destination replica and possibly a port number. Filters, base DN, and other LDAP URL components MUST be ignored if they are supplied. 8.2.6. replicationStatus (2.16.840.1.113719.1.142.4.3 NAME 'replicationStatus' DESC 'human readable status of last replication attempt' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) The replicationStatus attribute MAY be used to hold a human readable message describing the most recent replication session attempt for a replication agreement. For example, such a messages might include 1) 9980805162203Z # Success # 2) 19980805162322Z # Failure # Server too busy, try again LDUP Information Model 3) 19980805170215Z # Failure # Unable to connect to DSA 4) 19980806002301Z # Failure # Authentication failed 5) 19980806003201Z # Failure # lost connection, reset by peer It is suggested, but not required, that the time of a replication attempt (completion, if successful or failure, if not), the result of the attempt, and any additional information about a failure be included in the string message. It is suggested, but not required, that the messages be stored with language tags (English, French, German, Japanese, Chinese, per [RFC2596]) particularly if multiple translations of the error messages are available to the DSA implementers. Sequences of status entries SHOULD be written to log files or other persistent storage, or in multi-valued replication history attributes, but are not specified here. 8.2.7. replicaType (2.16.840.1.113719.1.142.4.4 NAME 'replicaType' DESC 'Enum: 0-reserved, 1-Primary, 2-Updateable, 3-ReadOnly, all others reserved' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 EQUALITY integerMatch SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) ReplicaType is a simple enumeration, used to identify what kind of replica is being described in a Replica object entry. A ReadOnly replica only accepts LDAP Search operations (to Read entries, list containers, and search for entries). Because no updates ever originate from ReadOnly replicas, they never have changes to send to another replica. However, a ReadOnly replica may be designated a supplier DSA in a replica agreement, if it is simply passing along information it receives from Updateable replicas about entries and their changes. ReadOnly replicas may be partial replicas. An Updateable replica may accept both LDAP Search operations (to read, list, or search entries), as well as modification operations (to add, modify, or delete entries). The consequences of having partial updateable replicas are not fully understood. LDAP DSAs MAY require updateable replicas to be complete replicas. LDUP Information Model A Primary replica is an Updateable replica, but it is "more special" than other Updateable replicas. When LDAP application want to direct their operations to a single replica, so that the application can be sure that all application LDAP modification (add, delete, modify) operations will be immediately visible to application readers, the Primary replica is a good choice. Such a use would be consistent with High Confidence DAP option [X518]. One such application might be a management application which creates new naming contexts or joins two naming contexts into a single naming context. Another application might be one which creates new replicas, or replication agreements. There SHOULD be only one Primary replica defined for a naming context at any time. If applications, expecting there to be a Primary replica discover, by search or inspection of ReplicaType attributes of the defined Replicas of a naming context, find more than one _ they should realize that something is wrong. There MAY be NO primary replica defined for a naming context. Primary replicas MAY NOT be partial replicas. The way in which replicas change their type, as from ReadOnly to Updateable, or Updateable to Primary is outside the scope of this document. Section 5.1 "Replica Type" of [LDUP MODEL] details the permissible combinations of replica types and sparse/fractional replicas. 8.2.8. updateVector ( 2.16.840.1.113719.1.142.4.6 NAME 'updateVector' SYNTAX 1.3.6.1.4.1.1466.115.121.1.TBD EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch NO-USER-MODIFICATION USAGE dSAOperation ) The attribute updateVector is a multi-valued attribute which contains information for a replica describing the latest changes received by the replica from other replicas. There may be only one ldapChangeSequenceNumber entry from each replica in the updateVector. That is to say, there is a unique value constraint on the ReplicaID component of entries in the list. 8.2.9. replicaSecondaryURI ( 2.16.840.1.113719.1.142.4.x NAME 'replicaSecondaryURI' DESC 'LDAP URLs which indicate how to connect to this replica' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 EQUALITY caseExactMatch USAGE dSAOperation ) LDUP Information Model The replicaSecondaryURI attribute is a multi-valued attribute used to list the set of LDAP URLs that should be used to contact the replica for replication sessions if all LDAP URLs in the replicaURL attribute are not contactable. 8.2.10. lostAndFoundEntryDN ( 2.16.840.1.113719.1.142.4.x NAME 'lostAndFoundEntryDN' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch SINGLE-VALUE DESC 'name of the entry under which orphaned entries will be moved during replication update processing by this replica.' ) This attribute indicates the location under which the replica will move orphaned entries that are encountered while performing replication updates. The attribute is single-valued and is specific to each replica. 8.2.11. replicaOnline ( 2.16.840.1.113719.1.142.4.x NAME 'replicaOnline' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 EQUALITY booleanMatch SINGLE-VALUE DESC 'indicates whether or not the replica will will initiate and/or respond to replication session start requests.' ) This attribute indicates whether the replica is ready and willing to participate in replication sessions with other replicas that are defined as holding the replication context. 8.2.12. replicaDN ( 2.16.840.1.113719.1.142.4.x NAME 'replicaDN' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch SINGLE-VALUE DESC 'name of the consumer replicaSubentry entry that the replicaAgreement links to.' ) This attribute is used to link a replicaAgreement entry (associated with a supplier of replication update information) to the consumer replica that will be contacted by replication sessions constrained by the replicaAgreement. 8.2.13. replicationMechanismOID ( 2.16.840.1.113719.1.142.4.x NAME 'replicationMechanismOID' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 EQUALITY caseIgnoreMatch SINGLE-VALUE LDUP Information Model DESC 'the OID which represents the specific replication protocol used for replication sessions between the identified supplier and consumer replicas.' ) This attribute identifies the specific replication protocol used for replication sessions between the supplier and consumer replicas associated by the replicaAgreement entry. This attribute must be a value that is within the set of attribute values for the supportedReplicationProtocols attribute in the root DSE entry. 8.2.14. replicationCredentialsDN ( 2.16.840.1.113719.1.142.4.x NAME 'replicationCredentialsDN' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch SINGLE-VALUE DESC 'name of a separate entry in the directory tree which contains the credentials information used in identifying the supplier replica to the consumer replica when initiating a replication session.' ) This attribute is used to establish a separate entry in the directory tree that will hold the credentials information that is used to establish the supplier's identity at the consumer when starting a replication session. By placing credentials information in a separate entry, "pointed to" with this attribute, credentials information can be placed in a portion of the directory tree that is not replicated across multiple replicas. It can also be _shared_ by several replication contexts. 8.2.15. replicationScheduleDN ( 2.16.840.1.113719.1.142.4.x NAME 'replicationScheduleDN' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch SINGLE-VALUE DESC 'name of an entry which contains the specific information used to establish when replication sessions will be initiated by this replica supplier.' ) This attribute is used to "point to" either a replicaEventSchedule or replicaTimeSchedule entry which describes when replication sessions should be initiated by a replica supplier. If not specified, a default schedule is assumed. See the section describing the replicaAgreement for more details. 8.2.16. updateVectorTrigger ( 2.16.840.1.113719.1.142.4.x NAME 'updateVectorTrigger' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 EQUALITY booleanMatch SINGLE-VALUE LDUP Information Model DESC 'indicates whether or not updates made to the replicas updateVector should be treated as updates that cause the secondsToWaitDefault attribute value to be used in determining when to initiate a replication session.' ) This attribute is used to indicate whether or not changes to the replica's updateVector should be included as updates that cause the secondsToWaitDefault attribute value to be used when determining when to initiate replication sessions. If updateVectorTrigger is set to FALSE, then secondsToWaitDefault will not be used when the replica's updateVector is updated. This implies that some other update will need to be performed to the replica before the updated updateVector will be sent via a replication session. If upateVectorTrigger is set to TRUE, then updates to the updateVector will be used in determining when replication sessions should be initiated. Note that setting secondsToWaitDefault to 0 coupled with updateVectorTrigger to TRUE would cause replication sessions to continually "chase themselves", potentially clogging networks with an infinite loop of replication sessions. This combination SHOULD be prevented in implementations. If not specified, the value for updateVectorTrigger is assumed to be FALSE. 8.2.17. secondsToWaitDefault (2.16.840.1.113719.1.142.4.x NAME 'secondsToWaitDefault' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 EQUALITY integerMatch SINGLE-VALUE DESC 'The number of seconds to wait after an update is made to the replica before initiating a replication session.' USAGE dSAOperation ) This attribute indicates the number of seconds that a replica should wait after an update is made to the replica before initiating a replication session. If not specified, the value is assumed to be 0. This attribute value is used for updates to all attributes that are NOT specified by either the attrs1 or attrs2 attributes. This attribute is always used for updates made to the replica's updateVector if the updateVectorTrigger attribute is set to TRUE. 8.2.18. secondsToWait1 LDUP Information Model (2.16.840.1.113719.1.142.4.x NAME 'secondsToWait1' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 EQUALITY integerMatch SINGLE-VALUE DESC 'The number of seconds to wait after an update is made to any attributes named in the attrs1 attribute before initiating a replication session.' USAGE dSAOperation ) This attribute is similar to the secondsToWaitDefault attribute in how it is used. This attribute, however, is used to apply only to the attributes listed in the attrs1 attribute. This allows updates to different attributes to cause replication sessions to be initiated either sooner or later than updates made to other attributes. 8.2.19. attrReplicationGroup1 ( 2.16.840.1.113719.1.142.4.x NAME 'attrReplicationGroup1' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 EQUALITY caseIgnoreMatch DESC 'the set of attributes that are associated with the secondsToWait1 attribute. When updates are made to any of these attributes on the replica, a replication session will be delayed until after secondsToWait1 seconds have passed.' ) This attribute identifies a set of attributes that are associated with the secondsToWait1 attribute. When secondsToWait1 seconds have passed since an update to any attribute identified in the attrs1 attribute, a replication session will be initiated. 8.2.20. secondsToWait2 (2.16.840.1.113719.1.142.4.x NAME 'secondsToWait2' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 EQUALITY integerMatch SINGLE-VALUE DESC 'The number of seconds to wait after an update is made to any attributes named in the attrs2 attribute before initiating a replication session.' USAGE dSAOperation ) This attribute is similar to the secondsToWaitDefault attribute in how it is used. This attribute, however, is used to apply only to the attributes listed in the attrs2 attribute. This allows updates to different attributes to cause replication sessions to be initiated either sooner or later than updates made to other attributes. LDUP Information Model 8.2.21. attrReplicationGroup2 ( 2.16.840.1.113719.1.142.4.x NAME 'attrReplicationGroup2' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 EQUALITY caseIgnoreMatch DESC 'the set of attributes that are associated with the secondsToWait2 attribute. When updates are made to any of these attributes on the replica, a replication session will be delayed until after secondsToWait2 seconds have passed.' ) This attribute identifies a set of attributes that are associated with the secondsToWait2 attribute. When secondsToWait2 seconds have passed since an update to any attribute identified in the attrs2 attribute, a replication session will be initiated. 8.2.22. scheduleTimePeriod ( 2.16.840.1.113719.1.142.4.x NAME 'scheduleTimePeriod' SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 EQUALITY caseIgnoreMatch SINGLE-VALUE DESC 'the absolute time range over which this time specification is valid.' ) This attribute is patterned after the TimePeriod property identified in RFC 3060 [RFC3060] and [Policy Schema]. Refer to these references for details on the format and interpretation of this attribute. 8.2.23. scheduleMonthOfYearMask ( 2.16.840.1.113719.1.142.4.x NAME 'scheduleMonthOfYearMask' SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 SINGLE-VALUE DESC 'mask identifying the months of the year during which replication sessions should be performed.' ) This attribute is patterned after the MonthOfYearMask property identified in RFC 3060 [RFC3060] and [Policy Schema]. Refer to these references for details on the format and interpretation of this attribute. 8.2.24. scheduleDayOfMonthMask ( 2.16.840.1.113719.1.142.4.x NAME 'scheduleDayOfMonthMask' SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 SINGLE-VALUE DESC 'mask identifying the days of the month during which replication sessions should be performed.' ) This attribute is patterned after the DayOfMonthMask property identified in RFC 3060 [RFC3060] and [Policy Schema]. Refer to LDUP Information Model these references for details on the format and interpretation of this attribute. 8.2.25. scheduleDayOfWeekMask ( 2.16.840.1.113719.1.142.4.x NAME 'scheduleDayOfWeekMask' SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 SINGLE-VALUE DESC 'mask identifying the days of the week during which replication sessions should be performed.' ) This attribute is patterned after the DayOfWeekMask property identified in RFC 3060 [RFC3060] and [Policy Schema]. Refer to these references for details on the format and interpretation of this attribute. 8.2.26. scheduleTimeOfDayMask ( 2.16.840.1.113719.1.142.4.x NAME 'scheduleTimeOfDayMask' SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 EQUALITY caseIgnoreMatch DESC 'mask identifying the times during the day when replication sessions should be initiated.' ) This attribute is patterned after the TimeOfDayMask property identified in RFC 3060 [RFC3060] and [Policy Schema]. Refer to these references for details on the format and interpretation of this attribute. 8.2.27. scheduleLocalOrUtcTime ( 2.16.840.1.113719.1.142.4.x NAME 'scheduleLocalOrUtcTime' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 EQUALITY integerMatch SINGLE-VALUE DESC 'flag indicating whether or not times in the scheduleTimeOfDayMask are in UTC time or local time.' ) This attribute is patterned after the LocaOrUtcTime property identified in RFC 3060 [RFC3060] and [Policy Schema]. Refer to these references for details on the format and interpretation of this attribute. 8.3. Class Definitions 8.3.1. ReplicationContext ( 2.16.840.1.113719.1.142.6.2.2 NAME 'replicationContext' SUP top AUXILIARY ) The replicationContext auxiliary class, when present on an object, indicates the beginning, or root, of a naming context. The naming LDUP Information Model context is said to be rooted at the entry with the replicationContext auxiliary class in its list of object classes. The root-most entry of a naming context is the entry with the replicationContext auxiliary class in its list of object classes. Characteristics of the replication topology of a naming context are defined in the replicaSubentry sub-entries associated with the naming context. The attribute accessControlPolicyOID has been removed from here, and should be published as an subentry subordinate to the replicationContext, instead. The attribute nameContextCreationTimestamp used here in previous drafts has been eliminated as redundant. The ldapChangeSequenceNumber associated with the replicationContext value in the list of objectclass attribute values serves the same purpose. 8.3.2. replicaSubentry ( 2.16.840.1.113719.1.142.6.3.2 NAME 'replicaSubentry-2' SUP subentry STRUCTURAL MUST ( cn $ replicaURI $ replicaType $ lostAndFoundEntryDN $ replicaOnline ) MAY ( attributeExclusionFilter $ attributeInclusionFilter $ replicaSecondaryURI $ description $ updateVector ) ) Entries of type replicaSubentry MUST be named by their cn attribute as defined in [LDAP Subentry]. A replicationContext may have more than one replicaSubentry. The attributes attributeExclusionFilter and attributeInclusionFilter, if present, govern which entries and attributes from the local naming context are to be sent (or not sent) to the replica named in replicaDN of replica agreements for this replica. The attributeExclusionFilter names attributes which SHOULD NOT be sent. The attributeInclusionFilter names attributes which SHOULD be sent. The attribute replicaURI contains information in ldapURI format that can be used to contact (i.e., open a connection to) this replica. The replicaSecondaryURI contains the set of ldapURI format addresses that can be used as backup addresses if the replicaURI values cannot be used. LDUP Information Model The lostAndFoundEntryDN attribute is single-valued attribute that contains the distinguished name of the lost and found entry under which orphaned entries are placed. The replicaOnline attribute is a Boolean attribute which indicates whether or not this replica will supply and/or accept replication sessions. This attribute can be used to prevent replication sessions from being started before replicaAgreement entries have been defined. The attribute description contains a human-readable description of the sub-entry. The attribute updateVector contains a set of ldapChangeSequenceNumbers, one for each of the other replicas for this naming context, which records, from this replicas perspective, the last change event received from the other indicated replica. The subtreespecification attribute of the subentry superior object class is used to define the scope of the replication context. Use of the subtreespecification value SHOULD be limited to the base and components of ChopSpecification portions of this attribute. 8.3.3. replicaAgreement ( ?? NAME 'replicaAgreement' SUP subentry STRUCTURAL MUST ( cn ) MAY ( description $ replicaDN $ replicationMechanismOID $ replicationStatus $ replicationCredentialsDN $ replicationScheduleDN ) ) Entries of this type MUST be placed just below replicaSubentry entries in the directory tree. Name subordination is used to associate a replicaAgreement with the replicaSubentry representing the supplier of changes for all subordinate replication agreements. Processing of allowable changes to be sent is as follows: LDUP Information Model 1) the attributeInclusionFilter from the replica subentry defines a set of attributes which SHOULD be sent, less exclusions; 2) the union of attributes excluded by the attributeExclusionFilter from the replicaSubentry and the attributeExclusionFilter from the replicaAgreement defines a set of attributes which SHOULD NOT be sent; 3) the subtraction of attributes which SHOULD NOT be sent by (2) from the attributes which SHOULD be sent by (1) constitute the set of attributes for which changes MAY be sent. The attribute description contains a human-readable description of the sub-entry. The attribute replicaDN of syntax distinguishedName names another sub-entry of type replicaSubentry to whom changes are to be sent. If there is no value for the replicaDN attribute on a replicaAgreement, the replicaAgreement is ignored. Absence of a value may occur briefly when replicas and replica agreements are first being created, or when the replica to which a replica agreement applies is being deleted. The attribute replicationMechanismOID is used to indicate the type of replication protocol that is used between the supplier and consumer. If not specified, the default replication protocol defined in [LDUP Update Replication Protocol] is assumed. The attribute replicationStatus MAY be used to record the most recent result of an attempt to send changes to the replica named in replicaDN, whether success, or if failure, the nature of the problem encountered. The attribute replicationCredentialsDN, if present, names an entry which contains information used to initialize authenticated the LDAP connection between the supplier and consumer. Separating the credentials information from the replicaAgreement itself allows for this information to be placed outside of the replication context. The attribute replicationScheduleDN, if present, names an entry which governs the schedule for replication attempts. If not present, replication MUST be attempted when there are changes to be sent (i.e. a default replica schedule of type replicaEventSchedule is assumed with secondsToWaitDefault=0 and updateVectorTrigger=FALSE). See Section on replicaEventSchedule for more information about these attributes and their meaning. The subtreespecification attribute of the subentry superior object class is ignored. LDUP Information Model 8.3.4. replicaEventSchedule ( 2.16.840.1.113719.1.142.6.x.1 NAME 'replicaEventSchedule' SUP subentry STRUCTURAL MUST ( cn ) MAY ( description $ updateVectorTrigger $ secondsToWaitDefault $ secondsToWait1 $ attrs1 $ secondsToWait2 $ attrs2 ) ) The replicaEventSchedule object class is used to specify when to initiate replication sessions in terms of the time to wait after an update is made to the supplier replica. The attribute cn is used as the naming attribute for the replicaEventSchedule object class. It is thought that replicaEventSchedule entries would be placed below replicaAgreement entries but this is not required. The attribute description contains a human-readable description of the sub-entry. The attribute updateVectorTrigger is a Boolean attribute which indicates whether or not the update of the supplier's updateVector attribute should, itself, be used to trigger replication sessions. Since the updateVector is, itself, an attribute, it has CSNs associated with each of its values. Note that these CSNs may be different from the CSNs that are in the attribute values themselves. Thus, it is possible that the update to the updateVector would, itself, need to be treated as an update to be replicated. Indeed, this is necessary in order for "transitive replication" to work. The secondsToWaitDefault attribute is a non-negative integer value. This value indicates the number of seconds to wait after an update is made before starting a replication session. This value is used for all attributes other than those noted in the attrs1 and attrs2 attributes. The secondsToWait1 attribute is similar to the secondsToWaitDefault attribute. This non-negative integer value is used whenever any attribute listed in the attrs1 attribute is updated. The secondsToWait2 attribute is similar to the secondsToWait1 attribute but is associated with the attrs2 attribute. Note that whenever any of these seconds-to-wait time periods has expired, a replication session should be initiated and the full set of information that needs to be replicated should be sent to the consumer replica. This implies that some information would be LDUP Information Model replicated before its associated seconds-to-wait time period had expired. The subtreespecification attribute of the subentry superior object class is ignored. 8.3.5. replicaTimeSchedule ( 2.16.840.1.113719.1.142.6.x.1 NAME 'replicaTimeSchedule' SUP subentry STRUCTURAL MUST ( cn ) MAY ( description $ scheduleTimePeriod $ scheduleMonthOfYearMask $ scheduleDayOfMonthMask $ scheduleDayOfWeekMask $ scheduleTimeOfDayMask $ scheduleLocalOrUtcTime ) ) The replicaTimeSchedule object class is used to specify when to initiate replication sessions based on a scheduled time basis rather than in relation to when updates are made to the supplier replica. The attribute cn is used as the naming attribute for the replicaTimechedule object class. It is thought that replicaTimeSchedule entries would be placed below replicaAgreement entries but this is not required. The attribute description contains a human-readable description of the sub-entry. The remaining attributes in this object class are patterned after the attributes defined for the policyTimePeriodCondition construct defined in the Policy Core Information Model [RFC3060]. Because the LDAP schema mapping for this portion of the CIM model is not complete at this time, these attributes are defined specifically for this LDUP-related object class. Refer to RFC 3060 for details of the formats for the scheduleTimePeriod, scheduleMonthOfYearMask, scheduleDayOfMonthMask, scheduleDayOfWeekMask, scheduleTimeOfDayMask, and scheduleLocalOrUtcTime attributes. The subtreespecification attribute of the subentry superior object class is ignored. 9. Semantics of the information model The intent of this information model is to allow for useful and expected operation while requiring a minimum amount of data to be specified. In this spirit, replicaAgreement entries are treated as "constraints" on when to initiate replication sessions, not "requirements" on being able to initiate replication sessions. LDUP Information Model To clarify this concept, two examples are provided in this section. The first example shows the minimal set of information required to get replication going between three replicas: dn: ou=accounting, o=your company objectclass: organizationalUnit objectclass: replicationContext ou: accounting dn: cn=replica1, ou=accounting, o=your company objectclass: subentry objectclass: replicaSubentry-2 cn: replica1 subtreespecification: {} description: replica in location 1 replicaURI: ldap://sys1.yourcompany.com replicaType: 2 lostAndFoundEntryDN: cn=lostAndFound1, o=your company replicaOnline: TRUE dn: cn=replica2, ou=accounting, o=your company objectclass: subentry objectclass: replicaSubentry-2 cn: replica2 subtreespecification: {} description: replica in location 2 replicaURI: ldap://sys2.yourcompany.com replicaType: 2 lostAndFoundEntryDN: cn=lostAndFound2, o=your company replicaOnline: TRUE dn: cn=replica3, ou=accounting, o=your company objectclass: subentry objectclass: replicaSubentry-2 cn: replica3 subtreespecification: {} description: replica in location 3 replicaURI: ldap://sys2.yourcompany.com replicaType: 2 lostAndFoundEntryDN: cn=lostAndFound3, o=your company replicaOnline: TRUE With replicaSubentry entries defined as shown in this first example, replication sessions will be initiated by all replicas whenever an update is made to any attribute within any entries in the replicationContext. The default event schedule will be used which indicates that a replication session is initiated immediately after an update is made to a replica. Further, replication sessions would be initiated to ALL OTHER replicas. As this shows, maximal replication is defined using a minimal amount of configuration. LDUP Information Model The second example shows how replication sessions can be constrained by replicaAgreement entries. This example builds on the data shown in the first example. Assume that the following entries are added to the entries defined in the first example: dn: cn=agreement1->2, cn=replica1, ou=accounting, o=your company objectclass: subentry objectclass: replicaAgreement cn: agreement1->2 subtreespecification: {} description: Replica agreement constraining replication sessions from replica 1 to replica 2. replicationScheduleDN: cn=schedule1, cn=replica1, ou=accounting, o=your company replicaDN: cn=replica2, ou=accounting, o=your company dn: cn=agreement1->3, cn=replica1, ou=accounting, o=your company objectclass: subentry objectclass: replicaAgreement cn: agreement1->3 subtreespecification: {} description: Replica agreement constraining replication sessions from replica 1 to replica 3. replicationScheduleDN: cn=schedule1, cn=replica1, ou=accounting, o=your company replicaDN: cn=replica3, ou=accounting, o=your company dn: cn=schedule1, cn=replica1, ou=accounting, o=your company objectclass: subentry objectclass: replicaEventSchedule cn: schedule1 subtreespecification: {} description: schedule that initiates replication one minute after any update (including to the updateVector) is made to the replica. secondsToWaitDefault: 60 updateVectorTrigger: TRUE dn: cn=agreement2->1, cn=replica2, ou=accounting, o=your company objectclass: subentry objectclass: replicaAgreement cn: agreement2->1 subtreespecification: {} description: Replica agreement constraining replication sessions from replica 2 to replica 1. replicationScheduleDN: cn=schedule2, cn=replica2, ou=accounting, o=your company replicaDN: cn=replica1, ou=accounting, o=your company dn: cn=agreement2->3, cn=replica2, ou=accounting, o=your company objectclass: subentry objectclass: replicaAgreement cn: agreement2->3 LDUP Information Model subtreespecification: {} description: Replica agreement constraining replication sessions from replica 2 to replica 3. replicationScheduleDN: cn=schedule2, cn=replica2, ou=accounting, o=your company replicaDN: cn=replica2, ou=accounting, o=your company dn: cn=schedule2, cn=replica2, ou=accounting, o=your company objectclass: subentry objectclass: replicaEventSchedule cn: schedule2 subtreespecification: {} description: schedule that initiates replication two minutes after any update (including to the updateVector) is made to the replica. secondsToWaitDefault: 120 updateVectorTrigger: TRUE dn: cn=agreement3->1, cn=replica3, ou=accounting, o=your company objectclass: subentry objectclass: replicaAgreement cn: agreement3->1 subtreespecification: {} description: Replica agreement constraining replication sessions from replica 3 to replica 1. replicationScheduleDN: cn=schedule3, cn=replica3, ou=accounting, o=your company replicaDN: cn=replica1, ou=accounting, o=your company dn: cn=agreement3->2, cn=replica3, ou=accounting, o=your company objectclass: subentry objectclass: replicaAgreement cn: agreement3->2 subtreespecification: {} description: Replica agreement constraining replication sessions from replica 3 to replica 2. replicationScheduleDN: cn=schedule3, cn=replica3, ou=accounting, o=your company replicaDN: cn=replica2, ou=accounting, o=your company dn: cn=schedule3, cn=replica3, ou=accounting, o=your company objectclass: subentry objectclass: replicaEventSchedule cn: schedule3 subtreespecification: {} description: schedule that initiates replication one minute after any update (including to the updateVector) is made to the replica. secondsToWaitDefault: 60 updateVectorTrigger: TRUE In this example, replication sessions are limited such that they will begin one or two minutes after an update is made to any one replica, depending on the replica on which the update was made. LDUP Information Model This "constrains" the replication session initiation from the default of "immediate replication" of updates. There are many ways in which the constraints around when to initiate and/or accept replication sessions between two replicas. The information model defined here provides a small set of options. More elaborate policies can be defined and this is left as a future exercise. It is hoped that the work from the Policy workgroup can offer schema that would support the creation of these complex policies. 10. Object Identifier Assignments The LDUP OID prefix is ID ::= OBJECT IDENTIFIER ldup ID ::= { joint-iso-ccitt(2) country(16) us(840) organization(1) novell(113719) novell-internal- OIDS(1) ldup(142) } The OID assignments defined in this document are: Attributes: attributeExclusionFilter ID ::= 2.16.840.1.113719.1.142.4.1 attributeInclusionFilter ID ::= 2.16.840.1.113719.1.142.4.2 replicationStatus ID ::= 2.16.840.1.113719.1.142.4.3 replicaType ID ::= 2.16.840.1.113719.1.142.4.4 secToWaitClass1 ID ::= 2.16.840.1.113719.1.142.4.5.1 - OBSOLETE secToWaitClass2 ID ::= 2.16.840.1.113719.1.142.4.5.2 - OBSOLETE secToWaitClass3 ID ::= 2.16.840.1.113719.1.142.4.5.3 - OBSOLETE secToWaitClass4 ID ::= 2.16.840.1.113719.1.142.4.5.4 - OBSOLETE secToWaitClass5 ID ::= 2.16.840.1.113719.1.142.4.5.5 - OBSOLETE updateVector ID ::= 2.16.840.1.113719.1.142.4.6 replicaURI ID ::= 2.16.840.1.113719.1.142.4.x replicaSecondaryURI ID ::= 2.16.840.1.113719.1.142.4.x lostAndFoundEntryDN ID ::= 2.16.840.1.113719.1.142.4.x replicaOnline ID ::= 2.16.840.1.113719.1.142.4.x replicaDN ID ::= 2.16.840.1.113719.1.142.4.x replicationMechanismOID ID ::= 2.16.840.1.113719.1.142.4.x replicationCredentialsDN ID ::= 2.16.840.1.113719.1.142.4.x replicationScheduleDN ID ::= 2.16.840.1.113719.1.142.4.x updateVectorTrigger ID ::= 2.16.840.1.113719.1.142.4.x secondsToWaitDefault ID ::= 2.16.840.1.113719.1.142.4.x secondsToWait1 ID ::= 2.16.840.1.113719.1.142.4.x attrReplicationGroup1 ID ::= 2.16.840.1.113719.1.142.4.x secondsToWait2 ID ::= 2.16.840.1.113719.1.142.4.x LDUP Information Model attrReplicationGroup2 ID ::= 2.16.840.1.113719.1.142.4.x scheduleTimePeriod ID ::= 2.16.840.1.113719.1.142.4.x scheduleMonthOfYearMask ID ::= 2.16.840.1.113719.1.142.4.x scheduleDayOfMonthMask ID ::= 2.16.840.1.113719.1.142.4.x scheduleDayOfWeekMask ID ::= 2.16.840.1.113719.1.142.4.x scheduleTimeOfDayMask ID ::= 2.16.840.1.113719.1.142.4.x scheduleLocalOrUtcTime ID ::= 2.16.840.1.113719.1.142.4.x supportedReplicationProtocols ID ::= 2.16.840.1.113719.1.142.4.x replicaContextRoots ID ::= 2.16.840.1.113719.1.142.4.x replicaSubentries ID ::= 2.16.840.1.113719.1.142.4.x Object Classes: eventScheduledSubentry ID ::= 2.16.840.1.113719.1.142.6.1 - OBSOLETE nameContext ID ::= 2.16.840.1.113719.1.142.6.2.1 - OBSOLETE replicaSubentry ID ::= 2.16.840.1.113719.1.142.6.3.1 - OBSOLETE replicaAgreementSubentry ID ::= 2.16.840.1.113719.1.142.6.4.1 _ OBSOLETE replicationContext ID ::= 2.16.840.1.113719.1.142.6.2.2 replicaSubEntry-2 ID ::= 2.16.840.1.113719.1.142.6.3.2 replicaAgreementSubEntry-2 ID ::= 2.16.840.1.113719.1.142.6.4.2 - OBSOLETE eventScheduledSubentry ID ::= 2.16.840.1.113719.1.142.6.1 - OBSOLETE replicaEventSchedule ID ::= 2.16.840.1.113719.1.142.6.x.1 replicaTimeSchedule ID ::= 2.16.840.1.113719.1.142.6.x.1 replicaAgreement ID ::= TBD Note: Object Class OIDs have version numbers, Attribute OIDs don't. 11. Security Considerations Many of the attributes and object classes described in this document should be considered "security sensitive", and protected from unintended modification by LDAP servers. Generally, creating Naming Contexts, Replicas and Replica Agreement entries should only be allowed by directory administrators who are authorized to do so. The values of attributes defined here are intended to control the behavior of the directory service agents, themselves. Unintended modification of their values may result in incomplete replication of data (if ldapSearchFilter or attributeExclusionFilter are changed), inappropriate disclosure of information (if attributeInclusionFilter is changed), or updates may be lost (if updateVector is changed). To avoid depending to much on the ldapAccessPoint values for other replicas, connections between LDAP servers for the purpose of replication MUST ALWAYS be authenticated using an authentication LDUP Information Model mechanism appropriate for the nature of information to be exchanged. References [LDUP Model] - J. Merrells, E. Reed, U. Srinivisan, "An Abstract Model of LDAP Replication", Internet draft, draft-ietf-ldup-model- 08.txt, March 2003. [LDUP Requirements] - E. Stokes, R. Weiser, R. Moats, R. Huber, "Lightweight Directory Access Protocol (version 3) Replication Requirements", RFC 3384, October 2002. [LDAP Subentry] _ K. Zeilenga, Stephen Legg, "Subentries in LDAP", Internet draft, draft-zeilenga ldap - -subentry-07.txt, August 2002. [LDUP Update Protocol] _ J. McMeeking, "The LDUP Replication Update Protocol", Internet Draft, draft-ietf-ldup-protocol-04.txt, March 2003. [Policy Schema] - J. Strassner, B. Moore, R. Moats, E. Ellesson, "Policy Core LDAP Schema", Internet draft, draft-ietf-policy-core- schema-16.txt, October 2002. [RFC822] _ D. Crocker, "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES", August 1982, RFC 822 [RFC2251] _ M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3)", December 1997, RFC 2251 [RFC2252] _ M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", December 1997, RFC 2252 [RFC2255] _ T. Howes, M. Smith, _The LDAP URL Format_, December 1997, RFC 2255. [RFC2596] - 2596 M. Wahl, T. Howes, _Use of Language Codes in LDAP_, May 1999, RFC2596. [RFC3060] _ B. Moore, E. Ellesson, J. Strassner, A. Westerinen, "Policy Core Information Model _ Version 1 Specification", February 2001, RFC 3060 [X518] - ITU-T Recommendation X.518 (1997) | ISO/IEC 9594-4:1998, Information Technology _ Open Systems Interconnection _ The Directory: Procedures for Distributed Operation LDUP Information Model [X680] - ITU-T Recommendation X.680 (1994) | ISO/IEC 8824-1:1995, Information technology _ Abstract Syntax Notation One (ASN.1): Specification of Basic Notation 12. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 13. Acknowledgements The authors would like to thank Ed Reed and Tim Han, the authors of the original infomod draft, for all their work. The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice LDUP Information Model this standard. Please address the information to the IETF Executive Director. 14. Authors' Addresses Richard Huber AT&T Laboratories Email: rvh@att.com John McMeeking IBM Email: jmcmeek@us.ibm.com Ryan Moats Lemur Networks, Inc. Email: rmoats@lemurnetworks.net LDUP Mailing List: ietf-ldup@idc.org From owner-ietf-ldup@mail.imc.org Fri Jun 13 20:41:40 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00018 for ; Fri, 13 Jun 2003 20:41:40 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5E0UHrb078855 for ; Fri, 13 Jun 2003 17:30:17 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5E0UHwM078854 for ietf-ldup-bks; Fri, 13 Jun 2003 17:30:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from echt.caledonia.net (echt.caledonia.net [207.40.197.226]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5E0UErb078849 for ; Fri, 13 Jun 2003 17:30:15 -0700 (PDT) (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (dpvc-141-152-21-16.rich.east.verizon.net [141.152.21.16]) by echt.caledonia.net; Fri, 13 Jun 2003 18:29:57 -0600 Reply-To: From: "Chris Apple" To: "'Kurt D. Zeilenga'" , Cc: "'John Strassner'" , "Ted Hardie" , Subject: RE: LDAP Client Update: consideration of alternative proposals Date: Fri, 13 Jun 2003 20:29:44 -0400 Organization: DSI-Consulting, Inc. Message-ID: <003401c3320c$1107b520$3d00000a@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <005301c32482$fea069e0$6500a8c0@D7ST2111> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Based on an evaluation of the discussion relating to this thread, WG Consensus has been established that we should stay with our presently chartered course of action. This is reflected as item 4b) below. To be more explicit, there is not sufficient support in the WG to proceed according to the proposal made by Kurt to evaluate both the existing WG deliverable and his individual submission as alternatives prior to WG Last Call for LCUP. We will post the LCUP WG Last Call announcement on Monday, June 16, 2003. This WG Last Call announcement will only reference the WG Deliverable. There are *no* restrictions on referencing parts of Kurt's individual submission during the WG Last Call (or any other document) as long as those references are intended to provide examples of clarifying text, rationale for particular arguments, etc., in support of improving the quality of the existing WG LCUP Deliverable. Discussion about and suggestions/proposals to delay or retract the WG Last Call in favor of initiating a technical comparative analysis of the two drafts are will be out of scope after the WG Last Call posting has been made. The LCUP WG Last Call posting will be made late in the day US ET on Monday, June 16, 2003. Most likely sometime that evening. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: Chris Apple [mailto:capple@dsi-consulting.net] Sent: Tuesday, May 27, 2003 3:05 PM To: capple@dsi-consulting.net; 'Kurt D. Zeilenga'; ietf-ldup@imc.org Cc: 'John Strassner' Subject: RE: LDAP Client Update: consideration of alternative proposals As WG Co-Chair, I want to be clear with WG Members about the status of Kurt's request: 1) The WG needs to establish a consensus of support for proceeding as Kurt suggests in order for John and I to endorse it and make any requests for changes to milestone dates or other charter changes to our ADs. 2) It is an open topic for discussion. Specifically, John and I need to see comments (preferably with rationale) about the value (or lack thereof) of proceeding as Kurt suggests. Do not wait for further communication from either John, Kurt, or I to start this discussion. John and I don't want to have to resort to interpreting silence on this issue in one way or another. Make your opinions known NOW! This applies to you even if you are an author of one of the drafts covered by Kurt's request. 3) The milestone date for the WG Last Call for the LCUP deliverable is still May 2003 and requires approval of our ADs to slip intentionally. 4) John and I will await confirmation/clarification of our understanding of Kurt's request from Kurt before making the request to our ADs to slip the milestone date to give us enough time to consider whether the WG wishes to: a) proceed as Kurt suggests b) stay with our presently chartered course of action, albeit with some slippage c) take another path completely different from those Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] On Behalf Of Chris Apple Sent: Tuesday, May 27, 2003 8:25 AM To: 'Kurt D. Zeilenga'; ietf-ldup@imc.org Cc: 'John Strassner' Subject: RE: LDAP Client Update: consideration of alternative proposals WG Members should review the request Kurt has made. John and I will respond to the list on the procedure we'll use in considering Kurt's request, and if appropriate, acting on it. Kurt, There are a few major points I'd like to be sure I'm summarizing correctly before John and I respond on the procedural issue. You are requesting the following: 1) that the WG formally consider your individual contribution as an alternative to the existing WG deliverable for LDAPv3 Client Update Protocol. 2) that the WG evaluate both documents based on technical merit. 3) that the WG emerge from that evaluation process with a single document that will be processed through a WG Last Call and submitted to the Ads as the WG deliverable for LDAPv3 Client Update Protocol. 4) that the WG Last Call milestone for LCUP be rescheduled further out in time to accommodate the above. Did I miss any key points in your request? Do any of them need clarification? Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Monday, May 26, 2003 11:11 AM To: ietf-ldup@imc.org Cc: Chris Apple; John Strassner Subject: LDAP Client Update: consideration of alternative proposals The LDUP WG is chartered to deliver: 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. Over the last few years, the WG has engineering a technical solution for this deliverable. This solution is specified in the I-D draft-ietf-ldup-lcup. Over the last 9 months or so, Jong and I, acting on an individual basis, engineered a technical solution for this deliverable. This solution is specified in the I-D draft-zeilenga-ldup-sync. Each of these technical solutions are intended to fulfill this deliverable. I also believe both sets of authors believe that their approach best fulfills this deliverable. It is also likely many members of this WG have formed opinions as to which technical solution best fulfills this deliverable. However, it is unclear to me whether both I-D, in particular the most recent revisions of each, have been thoroughly considered by the WG. WG I-Ds are implicitly viewed as being under WG consideration and it hoped that significant number of WG members review the I-D as it evolves. Individual I-Ds are not necessarily viewed as being under WG consideration unless submitted to the WG for consideration by their authors. They generally are reviewed by few WG members until consideration is specifically requested. I now submit the draft-zeilenga-ldup-sync to the LDUP WG for consideration as a technical solution to its "LDAP Client Update" deliverable. I believe the latest revision, draft-zeilenga-ldup-sync-02.txt, is suitable for progression. I ask the WG to view draft-ietf-ldup-lcup and draft-zeilenga-ldup-sync as technical alternatives and give thorough consideration to both. It is up to the WG to decide which solution is technically superior. As it is the function of the WG Chairs to manage the group process, I defer procedural questions and issues to Chris and John. As the differences between the approaches is fundamental in their design, it will be difficult to compare them without some basis to which can be measured against. It may be appropriate for the WG to examine what kinds of applications it intends its deliverable to be applicable to, what the requirements of these applications are, and how each of the technical alternatives measures up to these requirements. The WG should also consider broader issues, such as chattiness and security considerations. The WG should consider the appropriateness of the design and other constraints each places upon implementations. In regards to the WG milestone: May 03 LDAPv3 Client Update Protocol I-D goes to WG Last Call as Proposed Standard I would like the WG to defer this WG Last Call until it has thoroughly consider both technical alternatives and reached a consensus as to which alternative it would like to pursue. Then that alternative should be prepared of WG Last Call as the WG's "LDAPv3 Client Update Protocol I-D". I believe it necessary to defer the WG Last Call as the WG first needs to thoroughly consider both alternatives. I'd like to say a key design difference which is a major factor in I considering draft-zeilenga-ldup-sync technically superior to draft-ietf-ldup-lcup. In attempting to implement draft-ietf-ldup-lcup, we found that requires server implementations to maintain complete history information in order to provide eventually convergent incremental refreshes. We found that where the server only maintains simple state indicators such as timestamps, it cannot generally provide eventually convergent incremental refreshes. If the server maintains partial histories, the server will be limited in cases where it can provide eventually convergent incremental refreshes. In October 2002, the WG consensus was declared on an alternative approach (but later recanted). We implemented this approach and found that it allowed all of the above implementation variants to provide eventually convergent incremental refreshes. This was document in documented in early revisions of draft-zeilenga-ldup-sync. As a result of WG discussions about this approach, it was noted that this approach didn't allow servers to take advantage of histories they maintained. In our latest revision, we adopted a hybrid approach which allows servers to take advantage of histories they maintained. Hence, I believe draft-zeilenga-ldup-sync is technical superior in that it does not place significant implementation constraints in order to support eventually convergent incremental refreshes while allowing implementations take advantage of histories they maintain. There are, of course, many other factors in my consideration and I am quite willing to elaborate on these in subsequent discussions. Before doing so, I will await direction from the chairs on how to proceed with the consideration of the alternatives. Comments? Regards, Kurt From owner-ietf-ldup@mail.imc.org Sun Jun 15 11:10:50 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04302 for ; Sun, 15 Jun 2003 11:10:49 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5FF2vrb020960 for ; Sun, 15 Jun 2003 08:02:57 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5FF2uA2020959 for ietf-ldup-bks; Sun, 15 Jun 2003 08:02:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5FF2srb020953 for ; Sun, 15 Jun 2003 08:02:54 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h5FF2pc6097163; Sun, 15 Jun 2003 15:02:51 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030615075622.01be7560@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sun, 15 Jun 2003 07:59:40 -0700 To: From: "Kurt D. Zeilenga" Subject: RE: LDAP Client Update: consideration of alternative proposals Cc: , "'John Strassner'" , "Ted Hardie" , In-Reply-To: <003401c3320c$1107b520$3d00000a@D7ST2111> References: <005301c32482$fea069e0$6500a8c0@D7ST2111> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Is the opinion of the chairs that the WG has thoroughly considered the technical alternative (draft-zeilenga-ldup-sync) offered to the LDUP WG for consideration for its "LDAPv3 Client Update" deliverable? Kurt At 05:29 PM 6/13/2003, Chris Apple wrote: >Based on an evaluation of the discussion relating to this thread, >WG Consensus has been established that we should stay with our >presently chartered course of action. This is reflected as item 4b) >below. To be more explicit, there is not sufficient support in the >WG to proceed according to the proposal made by Kurt to evaluate >both the existing WG deliverable and his individual submission >as alternatives prior to WG Last Call for LCUP. > >We will post the LCUP WG Last Call announcement on Monday, June 16, 2003. >This WG Last Call announcement will only reference the WG Deliverable. > >There are *no* restrictions on referencing parts of Kurt's individual >submission during the WG Last Call (or any other document) as long as >those references are intended to provide examples of clarifying text, >rationale for particular arguments, etc., in support of improving the >quality of the existing WG LCUP Deliverable. > >Discussion about and suggestions/proposals to delay or retract >the WG Last Call in favor of initiating a technical comparative >analysis of the two drafts are will be out of scope after the >WG Last Call posting has been made. > >The LCUP WG Last Call posting will be made late in the day US ET >on Monday, June 16, 2003. Most likely sometime that evening. > >Chris Apple - Principal Architect > >DSI Consulting, Inc. > >mailto:capple@dsi-consulting.net > >http://www.dsi-consulting.com > >-----Original Message----- >From: Chris Apple [mailto:capple@dsi-consulting.net] >Sent: Tuesday, May 27, 2003 3:05 PM >To: capple@dsi-consulting.net; 'Kurt D. Zeilenga'; ietf-ldup@imc.org >Cc: 'John Strassner' >Subject: RE: LDAP Client Update: consideration of alternative proposals > > >As WG Co-Chair, I want to be clear with WG Members about >the status of Kurt's request: > >1) The WG needs to establish a consensus of support for > proceeding as Kurt suggests in order for John and I > to endorse it and make any requests for changes to > milestone dates or other charter changes to our ADs. > >2) It is an open topic for discussion. Specifically, John > and I need to see comments (preferably with rationale) > about the value (or lack thereof) of proceeding as > Kurt suggests. Do not wait for further communication > from either John, Kurt, or I to start this discussion. > John and I don't want to have to resort to interpreting > silence on this issue in one way or another. > > Make your opinions known NOW! This applies to you even > if you are an author of one of the drafts covered by > Kurt's request. > >3) The milestone date for the WG Last Call for the LCUP > deliverable is still May 2003 and requires approval > of our ADs to slip intentionally. > >4) John and I will await confirmation/clarification of our > understanding of Kurt's request from Kurt before making > the request to our ADs to slip the milestone date to give > us enough time to consider whether the WG wishes to: > > a) proceed as Kurt suggests > b) stay with our presently chartered course of action, > albeit with some slippage > c) take another path completely different from those > >Chris Apple - Principal Architect > >DSI Consulting, Inc. > >mailto:capple@dsi-consulting.net > >http://www.dsi-consulting.com > >-----Original Message----- >From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] On >Behalf Of Chris Apple >Sent: Tuesday, May 27, 2003 8:25 AM >To: 'Kurt D. Zeilenga'; ietf-ldup@imc.org >Cc: 'John Strassner' >Subject: RE: LDAP Client Update: consideration of alternative proposals > > > >WG Members should review the request Kurt has made. > >John and I will respond to the list on the procedure >we'll use in considering Kurt's request, and if appropriate, >acting on it. > >Kurt, > >There are a few major points I'd like to be sure I'm >summarizing correctly before John and I respond on the >procedural issue. You are requesting the following: > >1) that the WG formally consider your individual > contribution as an alternative to the existing > WG deliverable for LDAPv3 Client Update Protocol. > >2) that the WG evaluate both documents based on > technical merit. > >3) that the WG emerge from that evaluation process > with a single document that will be processed > through a WG Last Call and submitted to the Ads > as the WG deliverable for LDAPv3 Client Update > Protocol. > >4) that the WG Last Call milestone for LCUP be > rescheduled further out in time to accommodate > the above. > >Did I miss any key points in your request? > >Do any of them need clarification? > >Chris Apple - Principal Architect > >DSI Consulting, Inc. > >mailto:capple@dsi-consulting.net > >http://www.dsi-consulting.com > >-----Original Message----- >From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] >Sent: Monday, May 26, 2003 11:11 AM >To: ietf-ldup@imc.org >Cc: Chris Apple; John Strassner >Subject: LDAP Client Update: consideration of alternative proposals > > >The LDUP WG is chartered to deliver: > 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. > >Over the last few years, the WG has engineering a technical >solution for this deliverable. This solution is specified >in the I-D draft-ietf-ldup-lcup. Over the last 9 months or >so, Jong and I, acting on an individual basis, engineered >a technical solution for this deliverable. This solution is >specified in the I-D draft-zeilenga-ldup-sync. > >Each of these technical solutions are intended to fulfill >this deliverable. I also believe both sets of authors >believe that their approach best fulfills this deliverable. >It is also likely many members of this WG have formed opinions >as to which technical solution best fulfills this deliverable. >However, it is unclear to me whether both I-D, in particular >the most recent revisions of each, have been thoroughly >considered by the WG. > >WG I-Ds are implicitly viewed as being under WG consideration >and it hoped that significant number of WG members review the >I-D as it evolves. Individual I-Ds are not necessarily viewed >as being under WG consideration unless submitted to the WG for >consideration by their authors. They generally are reviewed by >few WG members until consideration is specifically requested. > >I now submit the draft-zeilenga-ldup-sync to the LDUP WG >for consideration as a technical solution to its "LDAP Client >Update" deliverable. I believe the latest revision, >draft-zeilenga-ldup-sync-02.txt, is suitable for progression. > >I ask the WG to view draft-ietf-ldup-lcup and draft-zeilenga-ldup-sync >as technical alternatives and give thorough consideration to both. >It is up to the WG to decide which solution is technically >superior. As it is the function of the WG Chairs to manage the >group process, I defer procedural questions and issues to Chris >and John. > >As the differences between the approaches is fundamental in >their design, it will be difficult to compare them without some >basis to which can be measured against. It may be appropriate >for the WG to examine what kinds of applications it intends its >deliverable to be applicable to, what the requirements of these >applications are, and how each of the technical alternatives >measures up to these requirements. The WG should also consider >broader issues, such as chattiness and security considerations. >The WG should consider the appropriateness of the design and >other constraints each places upon implementations. > >In regards to the WG milestone: > > May 03 LDAPv3 Client Update Protocol I-D goes > to WG Last Call as Proposed Standard > >I would like the WG to defer this WG Last Call until it has >thoroughly consider both technical alternatives and reached a >consensus as to which alternative it would like to pursue. >Then that alternative should be prepared of WG Last Call as >the WG's "LDAPv3 Client Update Protocol I-D". I believe it >necessary to defer the WG Last Call as the WG first needs to >thoroughly consider both alternatives. > >I'd like to say a key design difference which is a major factor >in I considering draft-zeilenga-ldup-sync technically superior >to draft-ietf-ldup-lcup. In attempting to implement >draft-ietf-ldup-lcup, we found that requires server implementations >to maintain complete history information in order to provide >eventually convergent incremental refreshes. We found that >where the server only maintains simple state indicators such as >timestamps, it cannot generally provide eventually convergent >incremental refreshes. If the server maintains partial histories, >the server will be limited in cases where it can provide >eventually convergent incremental refreshes. In October 2002, >the WG consensus was declared on an alternative approach (but >later recanted). We implemented this approach and found that it >allowed all of the above implementation variants to provide >eventually convergent incremental refreshes. This was document >in documented in early revisions of draft-zeilenga-ldup-sync. >As a result of WG discussions about this approach, it was noted >that this approach didn't allow servers to take advantage of >histories they maintained. In our latest revision, we adopted >a hybrid approach which allows servers to take advantage of >histories they maintained. Hence, I believe draft-zeilenga-ldup-sync >is technical superior in that it does not place significant >implementation constraints in order to support eventually >convergent incremental refreshes while allowing implementations >take advantage of histories they maintain. There are, of course, >many other factors in my consideration and I am quite willing to >elaborate on these in subsequent discussions. Before doing so, >I will await direction from the chairs on how to proceed with >the consideration of the alternatives. > >Comments? > >Regards, Kurt From owner-ietf-ldup@mail.imc.org Sun Jun 15 11:49:09 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04833 for ; Sun, 15 Jun 2003 11:49:08 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5FFherb021811 for ; Sun, 15 Jun 2003 08:43:40 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5FFhdlf021810 for ietf-ldup-bks; Sun, 15 Jun 2003 08:43:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from echt.caledonia.net (echt.caledonia.net [207.40.197.226]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5FFharb021804 for ; Sun, 15 Jun 2003 08:43:37 -0700 (PDT) (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (pool-151-204-208-252.pskn.east.verizon.net [151.204.208.252]) by echt.caledonia.net; Sun, 15 Jun 2003 09:43:03 -0600 Reply-To: From: "Chris Apple" To: "'Kurt D. Zeilenga'" Cc: , "'John Strassner'" , "'Ted Hardie'" , Subject: RE: LDAP Client Update: consideration of alternative proposals Date: Sun, 15 Jun 2003 11:42:42 -0400 Organization: DSI-Consulting, Inc. Message-ID: <000901c33354$c5f93960$6500a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <5.2.0.9.0.20030615075622.01be7560@127.0.0.1> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h5FFhdrb021806 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit It is my conclusion as a Co-Chair that the WG has thoroughly considered the technical issues relating to its LCUP deliverable. The WG has known of draft-zeilenga-ldup-sync since it was first published. In particular the editors of draft-ldup-lcup have known of it and considered it during their more recent revisions of draft-ldup-lcup. The WG was asked to achieve a consensus on either deferring the WG Last Call in favor of a detailed comparative study of the two drafts of alternatives (your proposal), pursuing its chartered course of action as close to the original schedule as possible without engaging in that comparative study, or doing something else altogether different. The WG was not asked to engage in a formal, detailed comparative study of the two drafts because they are not charted to do so. Asking the WG do that would require first asking that the WG achieve consensus on doing the new work. This is what your proposal documented, new work. One WG member identified it as such in his response to your posting. The WG Co-Chairs also view this proposal as new work. No other WG members have challenged that position. If there were a significant number of WG participants expressing the view that this doesn't constitute new work, John and I would of course be obligated to ask our ADs to consider allowing us to slip our milestones to accommodate it. When John and I requested that the WG Milestone be slipped to accommodate the process of establishing a consensus on whether or not to pursue your proposal, Ted added that he'd like to have showstopper issues raised during this period of discussion as well. There was a potential showstopper issue raised by you and echoed by Jong. I did not see support on the mailing list for the status of this issue being declared a showstopper to be addressed by the WG. The WG has a achieved a consensus that it should not pursue your proposal of a detailed comparative study of the two drafts. As a co-chair, I believe that the WG members achieved the consensus which they did because *they* are of the opinion that the technical alternative of draft-zeilenga-ldup-sync has been thoroughly considered by themselves over the past several months. The WG Last Call for LCUP will proceed on Monday, June 16, 2003. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Sunday, June 15, 2003 11:00 AM To: capple@dsi-consulting.net Cc: ietf-ldup@imc.org; 'John Strassner'; Ted Hardie; ned.freed@mrochek.com Subject: RE: LDAP Client Update: consideration of alternative proposals Is the opinion of the chairs that the WG has thoroughly considered the technical alternative (draft-zeilenga-ldup-sync) offered to the LDUP WG for consideration for its "LDAPv3 Client Update" deliverable? Kurt At 05:29 PM 6/13/2003, Chris Apple wrote: >Based on an evaluation of the discussion relating to this thread, >WG Consensus has been established that we should stay with our >presently chartered course of action. This is reflected as item 4b) >below. To be more explicit, there is not sufficient support in the >WG to proceed according to the proposal made by Kurt to evaluate >both the existing WG deliverable and his individual submission >as alternatives prior to WG Last Call for LCUP. > >We will post the LCUP WG Last Call announcement on Monday, June 16, 2003. >This WG Last Call announcement will only reference the WG Deliverable. > >There are *no* restrictions on referencing parts of Kurt's individual >submission during the WG Last Call (or any other document) as long as >those references are intended to provide examples of clarifying text, >rationale for particular arguments, etc., in support of improving the >quality of the existing WG LCUP Deliverable. > >Discussion about and suggestions/proposals to delay or retract >the WG Last Call in favor of initiating a technical comparative >analysis of the two drafts are will be out of scope after the >WG Last Call posting has been made. > >The LCUP WG Last Call posting will be made late in the day US ET >on Monday, June 16, 2003. Most likely sometime that evening. > >Chris Apple - Principal Architect > >DSI Consulting, Inc. > >mailto:capple@dsi-consulting.net > >http://www.dsi-consulting.com > >-----Original Message----- >From: Chris Apple [mailto:capple@dsi-consulting.net] >Sent: Tuesday, May 27, 2003 3:05 PM >To: capple@dsi-consulting.net; 'Kurt D. Zeilenga'; ietf-ldup@imc.org >Cc: 'John Strassner' >Subject: RE: LDAP Client Update: consideration of alternative proposals > > >As WG Co-Chair, I want to be clear with WG Members about >the status of Kurt's request: > >1) The WG needs to establish a consensus of support for > proceeding as Kurt suggests in order for John and I > to endorse it and make any requests for changes to > milestone dates or other charter changes to our ADs. > >2) It is an open topic for discussion. Specifically, John > and I need to see comments (preferably with rationale) > about the value (or lack thereof) of proceeding as > Kurt suggests. Do not wait for further communication > from either John, Kurt, or I to start this discussion. > John and I don't want to have to resort to interpreting > silence on this issue in one way or another. > > Make your opinions known NOW! This applies to you even > if you are an author of one of the drafts covered by > Kurt's request. > >3) The milestone date for the WG Last Call for the LCUP > deliverable is still May 2003 and requires approval > of our ADs to slip intentionally. > >4) John and I will await confirmation/clarification of our > understanding of Kurt's request from Kurt before making > the request to our ADs to slip the milestone date to give > us enough time to consider whether the WG wishes to: > > a) proceed as Kurt suggests > b) stay with our presently chartered course of action, > albeit with some slippage > c) take another path completely different from those > >Chris Apple - Principal Architect > >DSI Consulting, Inc. > >mailto:capple@dsi-consulting.net > >http://www.dsi-consulting.com > >-----Original Message----- >From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] On >Behalf Of Chris Apple >Sent: Tuesday, May 27, 2003 8:25 AM >To: 'Kurt D. Zeilenga'; ietf-ldup@imc.org >Cc: 'John Strassner' >Subject: RE: LDAP Client Update: consideration of alternative proposals > > > >WG Members should review the request Kurt has made. > >John and I will respond to the list on the procedure >we'll use in considering Kurt's request, and if appropriate, >acting on it. > >Kurt, > >There are a few major points I'd like to be sure I'm >summarizing correctly before John and I respond on the >procedural issue. You are requesting the following: > >1) that the WG formally consider your individual > contribution as an alternative to the existing > WG deliverable for LDAPv3 Client Update Protocol. > >2) that the WG evaluate both documents based on > technical merit. > >3) that the WG emerge from that evaluation process > with a single document that will be processed > through a WG Last Call and submitted to the Ads > as the WG deliverable for LDAPv3 Client Update > Protocol. > >4) that the WG Last Call milestone for LCUP be > rescheduled further out in time to accommodate > the above. > >Did I miss any key points in your request? > >Do any of them need clarification? > >Chris Apple - Principal Architect > >DSI Consulting, Inc. > >mailto:capple@dsi-consulting.net > >http://www.dsi-consulting.com > >-----Original Message----- >From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] >Sent: Monday, May 26, 2003 11:11 AM >To: ietf-ldup@imc.org >Cc: Chris Apple; John Strassner >Subject: LDAP Client Update: consideration of alternative proposals > > >The LDUP WG is chartered to deliver: > 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. > >Over the last few years, the WG has engineering a technical >solution for this deliverable. This solution is specified >in the I-D draft-ietf-ldup-lcup. Over the last 9 months or >so, Jong and I, acting on an individual basis, engineered >a technical solution for this deliverable. This solution is >specified in the I-D draft-zeilenga-ldup-sync. > >Each of these technical solutions are intended to fulfill >this deliverable. I also believe both sets of authors >believe that their approach best fulfills this deliverable. >It is also likely many members of this WG have formed opinions >as to which technical solution best fulfills this deliverable. >However, it is unclear to me whether both I-D, in particular >the most recent revisions of each, have been thoroughly >considered by the WG. > >WG I-Ds are implicitly viewed as being under WG consideration >and it hoped that significant number of WG members review the >I-D as it evolves. Individual I-Ds are not necessarily viewed >as being under WG consideration unless submitted to the WG for >consideration by their authors. They generally are reviewed by >few WG members until consideration is specifically requested. > >I now submit the draft-zeilenga-ldup-sync to the LDUP WG >for consideration as a technical solution to its "LDAP Client >Update" deliverable. I believe the latest revision, >draft-zeilenga-ldup-sync-02.txt, is suitable for progression. > >I ask the WG to view draft-ietf-ldup-lcup and draft-zeilenga-ldup-sync >as technical alternatives and give thorough consideration to both. >It is up to the WG to decide which solution is technically >superior. As it is the function of the WG Chairs to manage the >group process, I defer procedural questions and issues to Chris >and John. > >As the differences between the approaches is fundamental in >their design, it will be difficult to compare them without some >basis to which can be measured against. It may be appropriate >for the WG to examine what kinds of applications it intends its >deliverable to be applicable to, what the requirements of these >applications are, and how each of the technical alternatives >measures up to these requirements. The WG should also consider >broader issues, such as chattiness and security considerations. >The WG should consider the appropriateness of the design and >other constraints each places upon implementations. > >In regards to the WG milestone: > > May 03 LDAPv3 Client Update Protocol I-D goes > to WG Last Call as Proposed Standard > >I would like the WG to defer this WG Last Call until it has >thoroughly consider both technical alternatives and reached a >consensus as to which alternative it would like to pursue. >Then that alternative should be prepared of WG Last Call as >the WG's "LDAPv3 Client Update Protocol I-D". I believe it >necessary to defer the WG Last Call as the WG first needs to >thoroughly consider both alternatives. > >I'd like to say a key design difference which is a major factor >in I considering draft-zeilenga-ldup-sync technically superior >to draft-ietf-ldup-lcup. In attempting to implement >draft-ietf-ldup-lcup, we found that requires server implementations >to maintain complete history information in order to provide >eventually convergent incremental refreshes. We found that >where the server only maintains simple state indicators such as >timestamps, it cannot generally provide eventually convergent >incremental refreshes. If the server maintains partial histories, >the server will be limited in cases where it can provide >eventually convergent incremental refreshes. In October 2002, >the WG consensus was declared on an alternative approach (but >later recanted). We implemented this approach and found that it >allowed all of the above implementation variants to provide >eventually convergent incremental refreshes. This was document >in documented in early revisions of draft-zeilenga-ldup-sync. >As a result of WG discussions about this approach, it was noted >that this approach didn't allow servers to take advantage of >histories they maintained. In our latest revision, we adopted >a hybrid approach which allows servers to take advantage of >histories they maintained. Hence, I believe draft-zeilenga-ldup-sync >is technical superior in that it does not place significant >implementation constraints in order to support eventually >convergent incremental refreshes while allowing implementations >take advantage of histories they maintain. There are, of course, >many other factors in my consideration and I am quite willing to >elaborate on these in subsequent discussions. Before doing so, >I will await direction from the chairs on how to proceed with >the consideration of the alternatives. > >Comments? > >Regards, Kurt From owner-ietf-ldup@mail.imc.org Sun Jun 15 13:42:43 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06303 for ; Sun, 15 Jun 2003 13:42:43 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5FHZnrb028095 for ; Sun, 15 Jun 2003 10:35:49 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5FHZncs028094 for ietf-ldup-bks; Sun, 15 Jun 2003 10:35:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5FHZmrb028089 for ; Sun, 15 Jun 2003 10:35:48 -0700 (PDT) (envelope-from Kurt@OpenLDAP.org) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h5FHZlc6097823; Sun, 15 Jun 2003 17:35:47 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030615094149.01bfda60@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sun, 15 Jun 2003 10:32:36 -0700 To: From: "Kurt D. Zeilenga" Subject: RE: LDAP Client Update: consideration of alternative proposals Cc: , "'John Strassner'" , "'Ted Hardie'" , In-Reply-To: <000901c33354$c5f93960$6500a8c0@D7ST2111> References: <5.2.0.9.0.20030615075622.01be7560@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 08:42 AM 6/15/2003, Chris Apple wrote: >It is my conclusion as a Co-Chair that the WG has thoroughly >considered the technical issues relating to its LCUP deliverable. Thank you for this clarification. I would like to thank the WG for its consideration of the technical alternative (draft-zeilenga-ldup-sync) Jong and I have offered to the WG. It is our intent to pursue on an individual basis the publication of our draft as a non-Standard Track RFC. We continue to welcome any technical or editorial comment WG members (or others) might choose to offer. I also note that not only do we have no objection to the WG members referencing parts of our document in their future discussions regarding their deliverable, we have no objection to the WG borrowing text from our document as the WG deems appropriate. Jong and I will likely continue to participate in these discussions, however, since we are not interested in the technical approach being taken by the WG, that participation will likely be limited. We, of course, reserve the right to raise our concerns regarding the general suitability of the technical approach the WG is taken, as well as other comments, at IETF Last Call. Kurt From owner-ietf-ldup@mail.imc.org Mon Jun 16 19:40:48 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08763 for ; Mon, 16 Jun 2003 19:40:47 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5GNWQrb027502 for ; Mon, 16 Jun 2003 16:32:26 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5GNWQbi027501 for ietf-ldup-bks; Mon, 16 Jun 2003 16:32:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from echt.caledonia.net (echt.caledonia.net [207.40.197.226]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5GNWOrb027491 for ; Mon, 16 Jun 2003 16:32:25 -0700 (PDT) (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (dpvc-141-152-21-16.rich.east.verizon.net [141.152.21.16]) by echt.caledonia.net; Mon, 16 Jun 2003 17:31:47 -0600 Reply-To: From: "Chris Apple" To: Cc: "John Strassner" Subject: LDUP WG Last Call: LCUP Deliverable Date: Mon, 16 Jun 2003 19:31:30 -0400 Organization: DSI-Consulting, Inc. Message-ID: <000a01c3345f$6d389cb0$3d00000a@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit The purpose of this message is to initiate the LDUP working group last call on the LDAP Client Update Protocol draft. WHAT DOCUMENT? The document in last call is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-05.txt WHAT IS A LAST CALL FOR? The purpose of the working group last call is to ensure that the working group has reached consensus on the document, believes that all the known outstanding issues have been addressed, and is ready to put the document forward for Proposed Standard status. During the last call, any comments on the documents are collected and discussed on the mailing list. HOW LONG DOES IT LAST? The last call starts Monday, June 16, 2003 and will last approximately two weeks. It will end on Tuesday, July 1, 2003 at 1700 US ET. WHAT'S THE NEXT STEP? After the last call completes, there are three possible outcomes: 1) No changes are required and we request our ADs to put forward the documents to the IESG for Proposed Standard status. 2) Minor changes agreed to on the list are required, and the documents are revised. We then ask our ADs to put forward the revised documents to the IESG for Proposed Standard status. 3) Major issues are raised and no consensus is reached on the list. In this case, we discuss things until consensus is reached, at which time another working group last call will be issued. Assuming we achieve outcome 1) or 2), and that the ADs agree with our assessment, the next stop for the documents is with the IESG. The IESG reads them and may approve the documents (with or without changes), or send the documents back to the working group to have major issues addressed. If the first outcome happens, the documents are put forward for a two-week last call to the entire IETF, and after successful completion the documents are published as RFCs with Proposed Standard status. If the second outcome happens, we go back and address the issues, putting the documents forward again when we believe they're ready. WHAT SHOULD YOU DO? You should read the documents, making sure that 1) there are no problems or deficiencies or outstanding issues that need to be resolved; and 2) that there are no typos, formatting problems, grammatical errors, etc. Any substantive problems you find, you should send to the list. Any minor problems (typos, etc.) you may send to the list or just to the authors. If, for some reason, you have comments you don't want to send to the entire list, you may send them to me and/or LDUP WG co-chair John Strassner. Silence means consent. Read, enjoy, and send your comments in! regards, Chris Apple and John Strassner Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com From owner-ietf-ldup@mail.imc.org Mon Jun 16 20:15:34 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09741 for ; Mon, 16 Jun 2003 20:15:33 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5H09Drb028237 for ; Mon, 16 Jun 2003 17:09:13 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5H09DJJ028236 for ietf-ldup-bks; Mon, 16 Jun 2003 17:09:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5H09Crb028230 for ; Mon, 16 Jun 2003 17:09:12 -0700 (PDT) (envelope-from hardie@qualcomm.com) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h5H098xO011362 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 16 Jun 2003 17:09:08 -0700 (PDT) Received: from [129.46.74.110] (carbuncle.qualcomm.com [129.46.74.110]) by magus.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h5H096sh027993; Mon, 16 Jun 2003 17:09:06 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <000a01c3345f$6d389cb0$3d00000a@D7ST2111> References: <000a01c3345f$6d389cb0$3d00000a@D7ST2111> Date: Mon, 16 Jun 2003 17:09:05 -0700 To: , From: hardie@qualcomm.com Subject: Re: LDUP WG Last Call: LCUP Deliverable Cc: "John Strassner" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >At 7:31 PM -0400 6/16/03, Chris Apple wrote: >You should read the documents, making sure that 1) there >are no problems or deficiencies or outstanding issues that >need to be resolved; and 2) that there are no typos, >formatting problems, grammatical errors, etc. > >Any substantive problems you find, you should send to the >list. Any minor problems (typos, etc.) you may send to the >list or just to the authors. If, for some reason, you have >comments you don't want to send to the entire list, you may >send them to me and/or LDUP WG co-chair John Strassner. > >Silence means consent. This does not mean you have to be silent. I encourage those members of the working group who have completed a review of the document to send a message to the list with their comments, even if those are "It's good, ship it." or the moral equivalent. You do not have to be reporting an issue to respond to a last call; in fact, it is very useful for everyone involved to have comments on the document recording by the list. I realize this means extra traffic on the list, but it is in a good cause.... regards, Ted Hardie From owner-ietf-ldup@mail.imc.org Tue Jun 24 11:30:17 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20518 for ; Tue, 24 Jun 2003 11:30:15 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5OFJirb071126 for ; Tue, 24 Jun 2003 08:19:44 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5OFJigS071125 for ietf-ldup-bks; Tue, 24 Jun 2003 08:19:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from echt.caledonia.net (echt.caledonia.net [207.40.197.226]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5OFJdrb071113 for ; Tue, 24 Jun 2003 08:19:42 -0700 (PDT) (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (pool-151-204-202-57.pskn.east.verizon.net [151.204.202.57]) by echt.caledonia.net; Tue, 24 Jun 2003 09:19:03 -0600 Reply-To: From: "Chris Apple" To: Subject: Not-so-subtle reminder... Date: Tue, 24 Jun 2003 11:18:48 -0400 Organization: DSI-Consulting, Inc. Message-ID: <004601c33a63$f0d4b130$6500a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I-D revisions to be discussed at the Vienna IETF LDUP WG Session must be submitted before 0900 US ET on Monday, June 30, 2003. Our WG Meeting Agenda will largely be based on WG deliverable deliverables and associated documents and their status. Please send requests for additional agenda items directly to John and myself. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com From owner-ietf-ldup@mail.imc.org Fri Jun 27 11:14:18 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03584 for ; Fri, 27 Jun 2003 11:14:17 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5RF5Orb045504 for ; Fri, 27 Jun 2003 08:05:24 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5RF5O7I045503 for ietf-ldup-bks; Fri, 27 Jun 2003 08:05:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from echt.caledonia.net (echt.caledonia.net [207.40.197.226]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5RF5Mrb045480 for ; Fri, 27 Jun 2003 08:05:23 -0700 (PDT) (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (pool-141-150-249-166.pskn.east.verizon.net [141.150.249.166]) by echt.caledonia.net; Fri, 27 Jun 2003 09:04:43 -0600 Reply-To: From: "Chris Apple" To: Subject: Final I-D Cutoff Reminder Date: Fri, 27 Jun 2003 11:04:20 -0400 Organization: DSI-Consulting, Inc. Message-ID: <002401c33cbd$6cb347c0$6500a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit June 30th: FINAL Internet-Draft Cutoff All revised Internet-Draft submissions must be submitted by Monday, June 30th, 2003 at 09:00 ET. Internet-Drafts received after this time will NOT be announced NOR made available in the Internet-Drafts Directories. We will begin accepting Internet-Draft submissions the week of the meeting, though announcements will NOT be sent until the IETF meeting is over. Thank you for your understanding and cooperation. Please do not hesitate to contact us if you have any questions or concerns. FYI: These and other significant dates can be found at http://www.ietf.org/meetings/cutoff_dates_57.html Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com From owner-ietf-ldup@mail.imc.org Fri Jun 27 11:32:32 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04318 for ; Fri, 27 Jun 2003 11:32:30 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5RFJIrb047811 for ; Fri, 27 Jun 2003 08:19:18 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5RFJIrN047809 for ietf-ldup-bks; Fri, 27 Jun 2003 08:19:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5RFJErb047780 for ; Fri, 27 Jun 2003 08:19:16 -0700 (PDT) (envelope-from rvh@att.com) Received: from qsun.mt.att.com ([135.16.30.2]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h5RFIIIW017667; Fri, 27 Jun 2003 11:18:18 -0400 Received: from att.com by qsun.mt.att.com (8.8.8p2+Sun/ATTEMS-1.4.1 sol2) id LAA25198; Fri, 27 Jun 2003 11:18:23 -0400 (EDT) Message-ID: <3EFC5FE7.BFF09321@att.com> Date: Fri, 27 Jun 2003 11:16:56 -0400 From: Richard Huber X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: IETF LDUP Mailing List , Internet Drafts Editor CC: "Moats, Ryan" , "Maziarski, Gerald" Subject: New version of Usage Profiles draft Content-Type: multipart/mixed; boundary="------------B7C14604984AFA48B1E12206" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------B7C14604984AFA48B1E12206 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Internet Drafts Editor - Please publish the attached as draft-ietf-ldup-usage-profile-05.txt. LDUP - Most changes in the attached draft are to bring the references up to date. A few other editorial changes. Rick Huber --------------B7C14604984AFA48B1E12206 Content-Type: text/plain; charset=iso-8859-1; name="draft-ietf-ldup-usage-profile-05.txt" Content-Disposition: inline; filename="draft-ietf-ldup-usage-profile-05.txt" Content-Transfer-Encoding: 8bit INTERNET DRAFT Gen'l Usage Profile for LDAP Replication June 2003 Internet-Draft Richard V. Huber LDAP Duplication/Replication/Update Gerald F. Maziarski Protocols WG AT&T Laboratories Intended Category: Informational Ryan D. Moats Expires: December 2003 Lemur Networks June 2003 General Usage Profile for LDAPv3 Replication draft-ietf-ldup-usage-profile-05.txt Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt. The list of Internet-Drafts Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract Support for replication in LDAP directory systems is often one of the key factors in the decision to deploy them. But replication brings design constraints along with its benefits. We discuss some of the factors that should be taken into consideration when designing a replicated directory system. Both programming and architectural/operational concerns are addressed. Huber, et al Expires December 2003 [Page 1] INTERNET DRAFT Gen'l Usage Profile for LDAP Replication June 2003 Table of Contents 1 Introduction........................................................2 2 Meta-data Considerations............................................3 2.1 Schema Considerations...........................................3 2.2 Replication Agreements..........................................4 2.3 Access Control..................................................5 2.4 Change Logs.....................................................6 3 Naming Considerations...............................................6 4 Conflict Resolution Considerations..................................7 4.1 Consistent Access after Changes.................................7 4.2 Conflict Resolution in Single-Master Systems....................8 4.3 Problem Cases...................................................9 4.3.1 Atomicity....................................................9 4.3.1.1 Locking..................................................9 4.3.1.2 Partitioning............................................10 4.4 General Principles.............................................10 5 Failover Considerations............................................10 5.1 Common Issues..................................................11 5.2 Single Master Issues...........................................11 5.3 Multi-Master Issues............................................13 6 Other Issues.......................................................13 6.1 Locking........................................................13 6.2 Backup and Restore.............................................14 7 Impact of Non-LDAP Changes/Constraints.............................14 7.1 Changes Outside of LDAP........................................14 7.2 Application Triggers...........................................15 7.3 Policy Conflicts Across Servers................................15 8 Security Considerations............................................16 9 Acknowledgements...................................................16 10 References........................................................16 Authors' Addresses...................................................17 Full Copyright Statement.............................................18 1 Introduction As LDAP directories become part of the critical infrastructure for applications maintaining high reliability and availability is significant. Distributed, replicated directories can reduce reliability and capacity problems. However, applications that work well with a single, standalone directory can develop problems in a distributed environment unless both the applications and the environment are carefully designed. Huber, et al Expires December 2003 [Page 2] INTERNET DRAFT Gen'l Usage Profile for LDAP Replication June 2003 While particular areas of concern depend partly on whether the distributed directory is a single-master or multi-master system most concerns that are common to both. This document flags some issues as being specific to either single-master or multi-master directories. Unflagged issues pertain to both. The current replication framework provides no easily separable subset of functions for single-master and multi-master replication, therefor this addresses general issues regarding the deployment of single- master and multi-master directory systems. There may be additional drafts in the future that address specific applications. 2 Meta-data Considerations Any LDAP directory contains meta-data as well as the user data in the directory. Examples of this meta-data include descriptions of the data in the directory (e.g. schema), policies for use of the data (e.g. access controls), and configuration/status information (e.g. replication agreements); this is not an exhaustive list. This meta-data is stored in the directory itself, frequently accessible as regular data or as operational attributes. Issues arise when meta-data stored in the directory is replicated. However, not replicating meta-data also causes issues to arise. 2.1 Schema Considerations If the schema of one or more of the copies of a replica differs from the schema of the other replicas, then there is a possibility of schema mismatch when data is exchanged between them. The schema extensibility feature of LDAP nearly guarantees that replica groups comprised of a heterogeneous mix of systems will not contain homogeneous schema because of directory vendors' built-in extensions. A given directory may not utilize all of the elements of its schema, so schema differences do not always lead to schema mismatches during replication. Schema mismatch issues are further complicated by the possibility of replicating the "subschemaSubentry" itself. Some directories distribute schema changes through that mechanism. Currently there is no standard for LDAP schema representation within the subschemaSubentry. In the absence of such a standard, full schema interoperability is not possible in the IETF sense. Directory Huber, et al Expires December 2003 [Page 3] INTERNET DRAFT Gen'l Usage Profile for LDAP Replication June 2003 designers should establish common schema on all servers holding a replica. The following is a partial list of possible schema mismatches: 1. Object class not defined 2. Structure Rule of an object class 3. Structural vs. Auxiliary in an object class 4. Optional vs. Mandatory attribute in an object class 5. Object identifiers differ on an attribute type or on an object class 6. Type and number of attributes defined in a class 7. Attribute type not defined 8. Base syntax of an attribute type 9. Multi-valued vs. single-valued attribute types 10. Matching rule of an attribute type 11. Naming collisions of attribute type names 12. Attribute name aliasing ("street" vs. "streetAddress" vs. "Strasse") 13. ACL format (and consequently, ACL calculus) Schema mismatches that cause data corruption in one or more of the replicas must result in meta-data (e.g. log entries) in order to comply with Requirement P7 of [RFC3384]. However, not all schema differences produce corruption in all circumstances. Some schema differences may have little or no impact on the proper storage of replicated data. However, any time data is added to the directory, replication may result in data corruption due to a schema mismatch. Here are some options for dealing with such potential mismatches: - Use fractional replication to replicate only those attributes that do not have differences - Removal of all schema mismatches. - Use the same schema on all systems The tool described by requirement AM8 of [RFC3384] would help designers detect schema conflicts as early as possible. 2.2 Replication Agreements Replication Agreements are central to replication, as they allow configuration of most of the aspects of the replication process, including the triggers for replica cycles (from Requirement M1 in [RFC3384]), critical OID information (from Requirement M6 in [RFC3384]), and replication process parameters (Requirement M7 in Huber, et al Expires December 2003 [Page 4] INTERNET DRAFT Gen'l Usage Profile for LDAP Replication June 2003 [RFC3384]). Through the use of a standard replication agreement schema (Requirement SC2 of [RFC3384], [InfoMod]) it is possible to replicate the replication agreement. If a replication agreement includes replication credentials, the agreement should be read protected in the directory and transport of the replication agreement should be encrypted. When replication agreements are themselves distributed via replication, they are subject to same "loose consistency" problems (due to replication delay and deferred conflict resolution) as other data. Even a temporary inconsistency among replication agreements may cause unbalanced replication and further inconsistency. As "multi- mastering" complicates "loose consistency" issues, avoidance of these issues by making all replication agreement changes through the same master (see Sections 4 and 5) is strongly advised. 2.3 Access Control The following considerations complicate replication of Access Control Information: - Access Control Information (ACI) is treated as though it were stored as attributes in the directory [RFC2820] - LDAP [RFC2251] declares that changes resulting from a single LDAP MODIFY are atomic (but see caveats for multi-master replication in Sections 3 and 4) - The ACI affecting a given entry may not be part of that entry (it could be part of a group entry or part of an ancestor of the entry in question) - The ACI cannot always be changed atomically with associated data changes - The interaction of replication and partitioning is still unclear (i.e. what happens when access control policy is inherited from an area of replication that is not held locally). - Thus, if you aren't careful, you can leave windows where data is unprotected To reduce risk: - In all environments, access control changes should be made before adds and after deletes - In multi-master environments, access control changes and the associated data changes should be made on same system. Huber, et al Expires December 2003 [Page 5] INTERNET DRAFT Gen'l Usage Profile for LDAP Replication June 2003 Even when ACI is faithfully replicated (with the same transfer format) among heterogeneous members of a replica group, there is no guarantee that an ACI change is expressed similarly everywhere in the group. This caveat is partly due to the open issues with respect to partitioning mentioned above, and partly due to vendor differences with regard to the expression of security policy. 2.4 Change Logs Requirement G4 of [RFC3384] states that meta-data must not grow without bound. Since it is unrealistic to assume that meta-data won't be needed during replication, designers must consider how and when meta-data can be purged. Replicas that use connections with intermittent quality should use explicit replica cycle scheduling. Since the systems know when replication should have occurred, delayed replication can be detected and manual intervention initiated before the meta-data grows without bound. In extreme cases, it may be necessary to remove a replica from the replication group and restore it once better connectivity is available. In a multi-master system, it is possible for a consumer to receive changes that cannot be applied. For example, a modify request for an entry may arrive before the add request that creates that entry. The replication system will typically queue this change and wait for additional changes (see Section 3.3). 3 Naming Considerations A number of naming models have been proposed for directories ([RFC1255], [RFC2377], [CIMNames]), and many others have been implemented on an ad hoc basis. Each of these models specifies the naming attributes to be used and provides rules for using them which may also include containment rules. The naming plan applies to the directory as a whole, not the individual servers holding replicas. Therefore, in a heterogeneous replicated environment, all of the replicating servers must be capable of supporting all of the rules for the naming plan in use for that directory. Some directory implementations have naming constraints (e.g. containment rules, restrictions on attributes that can be used for naming). If such an implementation is part of a replicated directory, Huber, et al Expires December 2003 [Page 6] INTERNET DRAFT Gen'l Usage Profile for LDAP Replication June 2003 those constraints will have to be observed by all participating directories. If the environment contains implementations with incompatible constraints there is a major problem. This should be checked as early in the design phase as possible. Applications often have their own requirements on naming; in this case the directory will have to support multiple naming schemes. Thus, if two independent applications start sharing previously separate directory information, care should be taken that the naming is consistent across the applications. A difference in name form may be accepted through LDUP without constraint violation, but nevertheless result in unexpected behavior from a cross-application perspective. Consistent naming is not only important to the directory, but to the applications that consume directory information as well. 4 Conflict Resolution Considerations 4.1 Consistent Access after Changes Many operations on a directory are done as a set of steps. For example, a new object may be created by one operation, and its values may be filled in as part of a separate LDAP operation. An administrator may add a user to a directory, and that user may then try to log in using the new entry. Replicated LDAP directories provide loose consistency [RFC3384]. A new entry or a change to an existing entry will not reach all replicas immediately; there will be some delay before changes are available on all replicas. Changes made (e.g. adding a new user) on one physical system may appear to be "lost" if checked on another physical system before replication is complete. In general, LDAP applications should be prepared to operate correctly in the face of replication delays. In some cases, this means designing to allow for delay. In the case of the newly created user, it should be standard practice to ask the user to wait a while before trying to use the entry. In the case where the new object must be filled in, the application should make appropriate use of LDAP sessions to make sure that the same server is reached for both operations. As a general rule, an LDAP application should bind once and not unbind until a complete set of related operations have been performed. To achieve load balancing of write operations in a multi-master environment, balancing the write-enabled connections is recommended over balancing LDAP write operations. Huber, et al Expires December 2003 [Page 7] INTERNET DRAFT Gen'l Usage Profile for LDAP Replication June 2003 In the single-master case, all write requests go to one server. If a set of related reads and writes are done, they should all be done on the master if possible. Ideally, only sets of related operations that cannot include a write should go to one of the slave servers. But load balancing concerns may make this impractical. In some cases, related requests will deal with data in different partitions that are not all available on a single server. In this case, it is safer to keep sessions open to all servers rather than closing the session with one server and opening one with another server. It may not always be obvious to clients that they are using different servers. If a load distribution system is used between the client and the server, the client may find that a change request and a subsequent lookup are directed to different physical servers even though the original requests were sent to the same server name and/or address. Since LDAP is session oriented, any load distribution system used should take sessions into account. Thus, keeping all related read and write requests within a single bind/unbind session should be the goal in this situation as well. 4.2 Conflict Resolution in Single-Master Systems It is possible that resolution conflicts could occur in a single master replication system. Because requirement SM2 of [RFC3384] is a "SHOULD" and not a "MUST", it is possible for implementers to reorder changes. If changes are reordered, it is quite possible for a conflict to occur. Consider a case where schema changes are declared critical and must be moved to the front of the replication queue. Then the consumer servers might have to delete an attribute that still has values, and later process requests to delete the values of that attribute. However, directory administrators may have scenarios where re-ordering of replication information is desirable. On a case-by-case basis, the directory administrator should make such decisions. Many vendors may not implement conflict resolution for single-master replication. If such a system receives out-of-order changes from a system that does support them, replication errors will almost certainly occur. Designers should be aware that mismatches in the capabilities of replicating single-master directories could cause Huber, et al Expires December 2003 [Page 8] INTERNET DRAFT Gen'l Usage Profile for LDAP Replication June 2003 problems. Designs should not permit the master to re-order changes unless all slave copies are known to handle the situation correctly. 4.3 Problem Cases 4.3.1 Atomicity The fact that replication does not guarantee the time order arrival of changes at a consumer allows situations where changes that were applied successfully at the supplier may fail in part when an attempt is made to apply the same change at the consumer. Some examples appear below; additional examples are given in Appendix B.5 of [RFC3384]. 4.3.1.1 Locking There is an entry with distinguished name "DN" that contains attributes X, Y, and Z. The value of X is 1. On replica A, a ModifyRequest is processed which includes modifications to change that value of X from 1 to 0 and to set the value of Y to "USER1". At the same time, replica B processes a ModifyRequest which includes modifications to change the value of X from 1 to 0 and to set the value of Y to "USER2" and the value of Z to 42. The application in this case is using X as a lock and is depending on the atomic nature of ModifyRequests to provide mutual exclusion for lock access. In the single-server case, the two operations would have occurred sequentially. Since a ModifyRequest is atomic, the entire first operation would succeed. The second ModifyRequest would fail, since the value of X would be 0 when it was attempted, and the modification changing X from 1 to 0 would thus fail. The atomicity rule would cause all other modifications in the ModifyRequest to fail as well. In the multi-master case, it is inevitable that at least some of the changes will be reversed despite the use of the lock. Assuming the changes from A have priority per the conflict resolution algorithm, the value of X should be 0 and the value of Y should be "USER1" But what is the value of Z at the end of the replication cycle? If it is 42, then the atomicity constraint on the change from B has been violated. But for it to revert to its previous value, grouping information must be retained. Therefore, it is not clear when such information may be safely discarded. Thus, requirement G6 in [RFC3384] may be violated. The utility of locking mechanisms cannot be guaranteed with multi- master replication, and therefore results are likely to be misleading. Huber, et al Expires December 2003 [Page 9] INTERNET DRAFT Gen'l Usage Profile for LDAP Replication June 2003 As discussed further in section 6.1 below, its use in multi-master environments should be deprecated. 4.3.1.2 Partitioning Partitioning (design of replica groups) also adds complexity. For example, suppose two servers, A and B, are members of a replica-group for area of replication X while servers B and C are members of replica-group for area Y. It is possible to issue a ModifyRDN operation on server B that moves an entry from area X to area Y. Replication in area X would delete the entry on server A while replication in area Y would add the entry to server C. However, if another change on server C prevented the add operation from working (e.g. an entry with the same RDN but a different GUID exists there already), then the change on server A is inconsistent and will need to be reversed. Other examples of cases of this class include group membership modification and access control scoping. 4.4 General Principles The examples above discuss some of the most difficult problems that can arise in multi-master replication. Dealing with them is difficult and can lead to situations that are quite confusing to the application and to users. The common characteristics of the examples are: 1. Several directory users/applications are changing the same data 2. They are changing the data at the same time 3. They are using different directory servers to make these changes 4. They are changing data that are parts of a distinguished name or they are using ModifyRequest to both read and write a given attribute value in a single atomic request If any one of these conditions is reversed, the types of problems described above will not occur. There are many useful applications of multi-master directories where at least one of the above conditions does not occur or where careful design can reverse one of the conditions. If, for example, all atomic read/modify requests for a given object can be directed to the same server, condition 3 will not occur. For cases where all four conditions do occur, application designers should be aware of the possible consequences. 5 Failover Considerations Huber, et al Expires December 2003 [Page 10] INTERNET DRAFT Gen'l Usage Profile for LDAP Replication June 2003 One of the major reasons to use directory replication is to improve reliability of the directory system as a whole. Replication permits hot- and warm-standby configurations to be built easily. But there are some issues that must be considered during design. In this situation, single-master systems actually raise more concerns than multi-master. Both are addressed below. 5.1 Common Issues In both the single- and multi-master cases, clients must be able to find an alternate quickly when a server fails. Some possible ways to do this are detailed in [FindingLDAP] and [LDAPinDNS]. If all else fails, a list of possible servers can be built into client applications. Designers should consider how clients are notified that the server is again available. When the failed server comes back up, it is brought back into synchronization with the other servers and is ready to take requests. It is always possible that the failed server, if it was acting as a supplier, was unable to completely distribute its pending changes before removal from service, leaving its consumers in an inconsistent state. During the period between its removal from service and its eventual return, the inconsistency may have been compounded by further application activity. As there is no current automatic mechanism to rectify the problem, the administrator should use whatever mechanism is available to compare the replicas for consistency as soon after the event as is reasonable. Note that the process used to bring a failed server back into replication can also be used to add a server to a set of replicating servers. In this case, the new server might be initialized from a backed-up copy of the directory or it may acquire the entire DIB via replication. The former method is usually preferable when the directory is large. 5.2 Single Master Issues In a single-master system, the master is a single point of failure, as all modification has to originate at the master server. When high availability is a requirement, a quick, automated failover process for converting a slave replica to a new master is desirable, as the failover time becomes a major factor in determining system availability. The considerations in section 5.1 apply here; clients must know how to find the new master or a new slave in case of failure. Huber, et al Expires December 2003 [Page 11] INTERNET DRAFT Gen'l Usage Profile for LDAP Replication June 2003 To aid in promotion of a slave replica, the master could replicate control information and meta-data (including replication credentials) so that this information is available during failover promotion. This data may either be replicated on a single "failover designate" slave (which would become the master in during failover) or it could be replicated to all slaves. The first possibility has the advantage of minimizing the amount of extra replication while the second more robustly handles multiple failovers (i.e. failover of the newly promoted master to another slave before the original master has been restored). If this method is followed, data privacy mechanisms should be used to protect the replication session. If data privacy mechanisms (e.g. encryption) are used to protect the replication session, the new master must have the necessary key information. Further this key information should be independent of the master that is using it (i.e. not tied to the IP address of the master server). If it is not independent, slave replicas could be pre-configured with the keys for all possible masters to reduce failover time. Restoration of the failed or broken master can be handled in one of two ways: - It could join the replica group and function as a slave. - It could join the replica group and negotiate with the new master to synchronize and then take over as master. In either case, clients need a way to know that a new server is available. If the broken master is returned to service as a slave, then the administrator must, external to LDUP, distribute and resolve whatever pending changes remained undistributed and unresolved from the time immediately before it was removed from service. If the broken master is returned as a new master, then care must be taken with its replacement master to ensure that all of its pending changes are distributed and resolved before it is returned to duty as a slave. The slave replicas may also use the replication agreement to filter which master is allowed to submit changes. Such a model allows the slave servers to function correctly when the master server is "broken" and sending out incorrect updates. However, then it is necessary to update the replication agreement during the fail over process so that the slaves will accept updates from the new master. This is the case for both the original failure and the restoration of the restored master if that is how the restored master rejoins the replica group. Huber, et al Expires December 2003 [Page 12] INTERNET DRAFT Gen'l Usage Profile for LDAP Replication June 2003 5.3 Multi-Master Issues Typically, a multi-master configuration is used when high availability is required for writes as well as reads in the directory. Because there are multiple active servers prepared to take write requests, there is no "switchover" time in this case. But clients still need to be able to find an alternate server, so the considerations of Section 5.1 apply here. 6 Other Issues 6.1 Locking Section 4.3.1.1 discussed the problems that can arise when the "modify" command in LDAP is used for locking in a multi-master environment. There are more general principles at work there. LDAP is a distributed and replicated directory service that is typically described as "loosely consistent". In loose consistency, the data should eventually converge among the replicas, but at any given instant, replicas may be in disagreement. This stipulation is the general result of: 1. The delay due to replication or extended replication intervals 2. The out of natural time order arrival of data at a replica 3. The temporary isolation of distributed systems from one another 4. Failure to accept a change due to conflict resolution failure on a replica Because of loose consistency, data preconditions to an LDAP operation may differ among replicas. Multi-mastering may exacerbate this situation, but single-mastering will not totally eliminate it if out- of-order replication is allowed (see Section 4.2). One must carefully assess the effect of loose consistency when evaluating operations that place specific preconditions on data to work correctly. Applications which depend on such operations may be better suited for transactional models and/or non-distributed data. Distributed locking is one operation that depends on strict data preconditions. When data preconditions cannot be guaranteed, the lock is moot. The same principles hold for "atomic operations", defined here as any mix of allowable operations contained within the same LDAP PDU. RFC2251 requires that they either all fail or are applied as a unit. If strict data preconditions cannot be guaranteed, then the atomic operation may itself result in a further inconsistency requiring human intervention at one of the consumers. Huber, et al Expires December 2003 [Page 13] INTERNET DRAFT Gen'l Usage Profile for LDAP Replication June 2003 6.2 Backup and Restore Backup of a directory server should have the following goals: 1. It can be unambiguously and faithfully restored. 2. It is an internally consistent snapshot of an entire replica during the time interval it took to make it. This can only be achieved if the server is quiescent. 3. Replication can resume on a machine restored from that backup without information loss. Backup and restore of a single, operating directory server (rather than the entire directory system) presents its own challenges. "Loose consistency" works against the probability of achieving a loss-free copy of all the data in the directory, except under ideal conditions. Backup and restore of distributed directories is a decidedly easier task when the constraint of continuous availability is removed. In most cases, the removal of entire directory systems from write service is impossible, even for small periods of time. It is more practical to remove a single directory server from service to achieve a condition of quiescence. Once all write load is removed, including write load due to replication, an internally consistent copy of the data may be obtained. Replicas that have suffered catastrophic data loss may be restored from backups of working servers temporarily removed from service specifically to make a copy. This scenario illustrates the benefit of having three or more replicas in the system: no single point of write failure in the event that one of the replicas must be restored from a copy of another. The M11 requirement from [RFC3384] allows an empty replica to be brought up to date through replication. This feature duplicates, but does not make entirely unnecessary, backup procedures on directory servers. Backups are still needed to recover data that has been lost to all replicas, either through normal LDAP updates or through some catastrophic event. 7 Impact of Non-LDAP Changes/Constraints 7.1 Changes Outside of LDAP LDAP directories are typically built on top of some database or file system. Thus there are ways to change the data that do not go through the normal LDAP change mechanisms (e.g. ModifyRequest). If the data Huber, et al Expires December 2003 [Page 14] INTERNET DRAFT Gen'l Usage Profile for LDAP Replication June 2003 is modified outside of LDAP, the changes will not be checked for schema conformance nor will access controls be checked as the changes are made. Since both integrity and security checks are omitted, security can be adversely affected. Also, many systems use the normal LDAP modification mechanisms to trigger replication. Changes made using non-LDAP mechanisms may not be replicated at all, leading to inconsistencies between replica copies. 7.2 Application Triggers Directory servers commonly integrate one or more specific applications. To achieve this integration the directory server may intercept updates and run application-specific "trigger" code. Such triggers enforce directory invariants that cannot be expressed by the LDAP schema. A simple trigger example is password policy enforcement. A directory server might interpret a request to replace the current value of the userPassword attribute with some new value as a request to first check that the new value conforms to the server's password policy (e.g. the value is sufficiently long and complex) before storing the new value. Using this trigger the directory server voids the security risk associated with passwords that are easy to attack. A more complex trigger example is password hashing. A directory server might interpret a request to replace the current value of the userPassword attribute with some new value as a request to compute one or more secure hashes of the new value and store these hashes in one or more attributes, storing no value in the userPassword attribute. Using this trigger the directory server avoids the security exposure of storing the plaintext password. Replication between directory servers with different application triggers will compromise directory integrity. 7.3 Policy Conflicts Across Servers In addition to the discussions of ACI in Section 2.3 and triggering in section 7.2, LDUP replication can not (by its definition) handle replication of information that makes use of policy not expressible in the LDAP protocol. A prime example of this is security encoding of attributes (e.g. userPassword). This encoding is typically implementation specific and is not easily expressible via the LDAP protocol. Therefore replication of userPassword attributes between Huber, et al Expires December 2003 [Page 15] INTERNET DRAFT Gen'l Usage Profile for LDAP Replication June 2003 directory servers that use different encoding schemes will impede replication in a way that is not describable as schema or syntax mismatch. This is because of the bind-time policy semantics that are the true point of conflict. In general, any attribute with semantics that are outside the scope of what is expressible by the LDAP protocol could result in strange replication errors. Therefore, distributed directory implementers should (in the absence of a way to express such semantics) either strive for a homogeneous set of servers or ensure during acceptance testing that a new server can support the existing semantics of their directory. 8 Security Considerations This document discusses issues that arise in replication. Some of these issues are security related (e.g. replication of access control information) and the security implications are discussed in the relevant sections. 9 Acknowledgements This document owes a lot to discussions on the LDUP mailing list. In particular, the authors would like to thank Ed Reed, whose email to the mailing list drove much of section 6.1, and Mark Brown for identifying and generating text on the issues discussed in section 7. 10 References [CIMNames] Desktop Management Task Force, "Guidelines for CIM-to-LDAP Directory Mappings", DMTF Specification DSP0100, May 2000 (available online at http://www.dmtf.org/spec/DEN/DSP0100.htm). [FindingLDAP] R. Moats, R. Hedberg, "A Taxonomy of Methods for LDAP Clients Finding Servers", Internet Draft, draft-ietf-ldapext-ldap- taxonomy-05.txt, July 2001. [InfoMod] R. Moats, R. Huber, J. McMeeking, "LDUP Replication Information Model", Internet Draft, draft-ietf-ldup-infomod-07.txt, June 2003. [LDAPinDNS] M. Armijo, L. Esibov, P. Leach, R. L. Morgan, "Discovering LDAP Services with DNS", Internet Draft, draft-ietf- ldapext-locate-05.txt, March 2001. Huber, et al Expires December 2003 [Page 16] INTERNET DRAFT Gen'l Usage Profile for LDAP Replication June 2003 [RFC3384] E. Stokes, R. Weiser, R. Moats, R. Huber, "LDAPv3 Replication Requirements", RFC 3384, October 2002. [RFC1255] The North American Directory Forum, "A Naming Scheme for c=US", RFC 1255, September 1991. [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol", RFC 2251, December 1997. [RFC2820] E. Stokes, D. Byrne, B. Blakley, P. Behara, “Access Control Requirements for LDAP”, RFC2820. May 2000. [RFC2377] A. Grimstad, R. Huber, S. Sataluri, M. Wahl, "Naming Plan for Internet Directory-Enabled Applications", RFC 2377, September 1998. Authors' Addresses Richard V. Huber Room C3-3B30 AT&T Laboratories 200 Laurel Avenue South Middletown, NJ 07748 USA E-Mail: rvh@att.com Telephone: +1 732 420 2632 Fax: +1 732 368 1690 Gerald F. Maziarski Room C3-3Z01 AT&T Laboratories 200 Laurel Avenue South Middletown, NJ 07748 USA E-Mail: gfm@att.com Telephone: +1 732 420 2162 Fax: +1 732 368 1690 Ryan D. Moats Lemur Networks 15621 Drexel Circle Omaha, NE 68135 USA E-Mail: rmoats@lemurnetworks.net Telephone: +1 402 894 9456 Huber, et al Expires December 2003 [Page 17] INTERNET DRAFT Gen'l Usage Profile for LDAP Replication June 2003 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Huber, et al Expires December 2003 [Page 18] --------------B7C14604984AFA48B1E12206-- From owner-ietf-ldup@mail.imc.org Sun Jun 29 08:58:59 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27544 for ; Sun, 29 Jun 2003 08:58:42 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5TCmZFK023873 for ; Sun, 29 Jun 2003 05:48:35 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5TCmX5A023872 for ietf-ldup-bks; Sun, 29 Jun 2003 05:48:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from tconl91223.tconl.com (tconl91223.tconl.com [204.26.91.223]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5TCmUFK023866 for ; Sun, 29 Jun 2003 05:48:31 -0700 (PDT) (envelope-from jayhawk@tconl91223.tconl.com) Received: (from jayhawk@localhost) by tconl91223.tconl.com (8.11.6/8.11.0) id h5TCmP002181; Sun, 29 Jun 2003 07:48:25 -0500 Date: Sun, 29 Jun 2003 07:48:25 -0500 From: Ryan Moats To: ietf-ldup@imc.org, internet-drafts@ietf.org Subject: please publish new InfoMod draft Message-ID: <20030629074825.B1987@privateer.local.windrose.omaha.ne.us> Reply-To: rmoats@lemurnetworks.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Please replace infomod-06 with the attached draft. To LDUPers, this is being submitted to get in under the deadline. I have not, to date, seen any discussion or comments on the two issues I asked previously: 1) Who has client implementations use root DSE attributes? There are several root DSE attributes that seem redundant, but before axing, let's make sure there aren't existing implementations that plan on using them. 2) This interim draft also has changes in it to explicitly allow multiple replicas at the same DN. This is a definite shift and this is to let the working group reach consensus. Ryan (for the authors) ============================cut here Internet Draft Richard Huber Document: draft-ietf-ldup-infomod-07.txt AT&T Laboratories Expires: December 2003 John McMeeking IBM Ryan Moats Lemur Networks June 2003 LDUP Replication Information Model draft-ietf-ldup-infomod-07.txt 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft expires March, 2002. 2. Abstract [LDUP Model] describes the architectural approach to replication of LDAP directory contents. This document describes the information model and schema elements which support LDAP Replication Services which conform to [LDUP Model]. Directory schema is extended to provide object classes, subentries, and attributes to describe areas of the namespace which are under common administrative authority, units of replication (i.e., subtrees, or partitions of the namespace, which are replicated), servers which hold replicas of various types for the various partitions of the namespace, which namespaces are held on given servers, and the progress of various namespace management and replication operations. Among other things, this knowledge of LDUP Information Model where directory content is located will provide the basis for dynamic generation of LDAP referrals for clients who can follow them. The controlling framework by which the relationships, types, and health of replicas of the directory content will be defined so that, as much as possible, directory content is itself used to monitor and control the environment. Security information, including access control policy identifiers and information will be treated as directory content by the replication protocols when specified by the LDAPEXT group. The information model will describe required and optional house- keeping duties for compliant systems to implement, such as garbage collection of deleted objects, reconciliation of moved and renamed objects, update sequencing and transaction bracketing of changes, etc. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. The sections below reiterate these definitions and include some additional ones. LDUP Information Model 3. Table of Contents 1. Status of this Memo ...........................................1 2. Abstract ......................................................1 3. Table of Contents .............................................3 4. Recent document changes .......................................5 5. Introduction ..................................................7 5.1. Scope ......................................................7 5.2. Terms and Definitions ......................................7 6. Data design ...................................................7 7. Directory Knowledge ...........................................7 8. Schema ........................................................8 8.1. Data Structure Definitions .................................8 8.1.1. LdapChangeSequenceNumber .................................9 8.2. Attribute Definitions .....................................10 8.2.1. supportedReplicationProtocols ...........................10 8.2.2. replicaSubentries .......................................10 8.2.3. attributeExclusionFilter ................................11 8.2.4. attributeInclusionFilter ................................11 8.2.5. replicaURI ..............................................12 8.2.6. replicationStatus .......................................12 8.2.7. replicaType .............................................13 8.2.8. updateVector ............................................14 8.2.9. replicaSecondaryURI .....................................14 8.2.10. lostAndFoundEntryDN .....................................15 8.2.11. replicaOnline ...........................................15 8.2.12. replicaDN ...............................................15 8.2.13. replicationMechanismOID .................................15 8.2.14. replicationCredentialsDN ................................16 8.2.15. replicationScheduleDN ...................................16 8.2.16. updateVectorTrigger .....................................16 8.2.17. secondsToWaitDefault ....................................17 8.2.18. secondsToWait1 ..........................................17 8.2.19. attrReplicationGroup1 ...................................18 8.2.20. secondsToWait2 ..........................................18 8.2.21. attrReplicationGroup2 ...................................18 8.2.22. scheduleTimePeriod ......................................19 8.2.23. scheduleMonthOfYearMask .................................19 8.2.24. scheduleDayOfMonthMask ..................................19 8.2.25. scheduleDayOfWeekMask ...................................20 8.2.26. scheduleTimeOfDayMask ...................................20 8.2.27. scheduleLocalOrUtcTime ..................................20 8.3. Class Definitions .........................................20 8.3.1. ReplicationContext ......................................20 8.3.2. replicaSubentry .........................................21 8.3.3. replicaAgreement ........................................22 LDUP Information Model 8.3.4. replicaEventSchedule ....................................23 8.3.5. replicaTimeSchedule .....................................24 9. Semantics of the information model ...........................25 10. Object Identifier Assignments ..............................29 11. Security Considerations ....................................30 12. Copyright Notice ...........................................31 13. Acknowledgements ...........................................32 14. Authors' Addresses .........................................32 LDUP Information Model 4. Recent document changes Changes in this version - Explicitly change replicaAgreement to not be a subentry. - Explicitly allow multiple replicaSubentries per replicaContext - Added replicaDN to examples. Changes made to previous versions - Fixed OID values to have correct prefix: 2.16.840.1.113719.1.142 - Fixed formatting to avoid strange single quote characters in text formatted file - Changed name of attrs1 and attrs2 to attrReplicationGroup1 and attrReplicationGroup2 - Made obsolete timeScheduledSubentry and eventScheduledSubentry - Re-based replicaSubEntry and other object classes on subentry schema from draft-zeilenga-ldap-subentry-00.txt - Clarified that root DSE attribute replicaSubentries should be automatically updated on both add and delete of these entries - Made obsolete replicaSubEntry and replicaAgreementSubentry object classes - Defined replacement object classes replicaSubEntry2 and replicaAgreementSubentry2 - Defined replicaEventSchedule and replicaTimeSchedule object classes and associated attributes - Defined attributes that must appear in the server's root DSE entry as part of the LDUP information model - Many editorial fixes - Clarified the notion that the updateVector is a replicated attribute and thus, itself, has CSN information for its attribute values - Introduced the notion that replicaAgreementSubentry entries represent constraints to what is, by default, "immediate" replication session initiation - LDAP Schedule Subentry definition is defined. - LDAP Access Point removed in favor of just using the DN of the server holding the replica (so a new syntax isn't required). - LDAP Change Sequence Number syntax eliminated in favor of just calling it a CaseIgnoreString, so new comparison rules aren't required. - Deleted ldapSearchFilter definition from here. Sparse replicas is deferred. Might sparse be supported for single- master configurations (read-only, of course). - Fractional are okay in multi-master configurations, but again, only on read-only replicas. - Changed the naming convention upper-lower case usage to look less weird. - Consistency discussion - Schema document must clearly indicate that clients can and should inspect the replica subentries to understand the LDUP Information Model single-master/multi-master nature of the naming context to which they're talking. - The paradigm change, to distributed data, needs to be exhaustively discussed in the profile documents. How old applications which assume single-master behave or misbehave in a multi-master environment is critical to make clear. Draw examples from SMP pre-emptive programming practices, from DNS vs. host file models, etc. - To do: - verify LDUP OID number(s) with Novell - verify all OIDs assigned - verify all OIDs documented at the end of the document LDUP Information Model 5. Introduction 5.1. Scope This document describes schema for information used to control replication. Management and status schema elements are defined. Semantic interpretation of schema elements, including any special handling expectations are to be provided here. 5.2. Terms and Definitions Definitions are provided in [LDUP Requirements]. 6. Data design As described in [LDUP Model], knowledge of replicated portions of the directory information tree (DIT) is stored in the directory itself. An auxiliary class is defined to designate containers, or nodes, in the DIT which are the root-most, or base, of replication contexts. Directory subentries [LDAP Subentry] are used to hold information about replicas and replica agreements. In defining the replication agreement data model, describing the constraints under which replication between two replicas will occur, this document describes only the least set of information necessary to ensure interoperability between implementations. The current document defines data elements sufficient to describe most common replication needs. The specification of complex replication agreements and constraints is better served by usage of the emerging "policy model" [Policy schema]. 7. Directory Knowledge Information about what replicas exist, what they contain, their types, where they are stored, and how they may be contacted inevitably provides the basis for distributed directory knowledge. As namespaces from stand-alone servers are inter-connected with one another, this replica information can and will be used by name resolution operations to locate servers holding copies of specific objects, and to optimize distributed searches which span multiple Naming Contexts. However, the focus of this document is NOT to fully enable such distributed directory uses. Instead, we are focused on how portions of the namespace (Directory Information Tree - DIT) may be replicated, and how those replicas are configured and related to one another via Replication Agreements. LDUP Information Model As such, the following high level description (from [LDUP Model]) of the information model envisioned is provided as reference for the reader before presenting the detailed specifications. Generally, the DSE Naming Context attribute of an LDAPv3 server names the Naming Contexts for which there are replicas on that server. The Replication Context Auxiliary Class (replicationContext) is added to container objects which may have separately defined replication policy. Immediately subordinate to a Replication Context object are the Replica Subentry containers which identify where the identified replica resides (i.e., its LDAP Access Point), its type (Primary, Updateable, ReadOnly), if it is sparse, the LDAP search filter which defines what object classes it holds, and if it is fractional, the attributes it does or does not hold. Immediately subordinate in the namespace to a Replica Subentry are Replication Agreement leaf entries which each identify another Replica, the scheduling policy for replication operations (including times when replication is to be performed, when it is not to be performed, or the policies governing event-driven replication initiation). These Replication Agreements are used to specify constraints on when the replica will supply what changes to the "pointed to" other replica, as either the replication initiator or responder. Replication Agreements are not defined to cover the following advanced policy characteristics: - when a replica would allow consumers to request a replication session - when a replica would allow suppliers to start a replication session - when a replica would request a replication session from a supplier. These advanced policy specifications imply the specification of complex replication agreements and constraints. This is better served by usage of the emerging "policy model" [Policy schema]. Interoperable policies for replication agreements is left as a follow-on work effort. 8. Schema 8.1. Data Structure Definitions For the purposes of defining the encoding rules for attribute structures, the BNF definitions in section 4.1 of [RFC2252] will be used. They are based on the BNF styles of [RFC822]. LDUP Information Model To avoid requiring new syntax support to be added unnecessarily to existing LDAPv3 directory service implementations (and the accompanying matching rules, etc. they would entail), a string encoding is defined for ldapChangeSequenceNumber which can use CaseIgnoreString matching rules for ordering and equality. 8.1.1. LdapChangeSequenceNumber ( 1.3.6.1.4.1.1466.115.121.1.TBD DESC 'LDAP Change Sequence Number' ) Values in this syntax are encoded according to the following BNF. Note there MUST NOT be any white space separators, unless they are in replicaID, which must be encoded according to the instructions below. This encoding is specified so that the CaseIgnoreString equality and ordering rules will work correctly when replicaNumber is used. When replicaID is used, CaseIgnoreString comparison rules will not work unless each replicaID is exactly the same length with no padded white spaces (because CaseIgnoreString suppresses duplicate adjacent white space when it compares two strings). LDAPChangeSequenceNumber = GeneralizedZTime "#" \ S1 "#" replicaID "#" S2 GeneralizedZTime = yyyy | mm | dd | hh | mi | ss | "Z" yyyy = dddd mm = dd dd = dd hh = dd mi = dd ss = dd replicaID = dstring S1, S2 = numericstring The GeneralizedTime is used as described (cf. [X680] section 39.3 case b) without separators or white space, and representing a coordinated universal time (i.e., Greenwich Mean Time, or GMT). All times referenced by this syntax MUST be normalized to GMT - no local times, nor time zone offsets are permitted. To simplify comparisons of two CSNs, the "Z" MUST be the UTF-8 capital-Z character. The ReplicaID represents the specific Replica of this Naming Context where the event associated with this LDUP Information Model LDAPChangeSequenceNumber occurred. Note that in actual transfer, the replicaID MAY be represented by a number which is associated with the entryUUID of the replicaSubEntry associated with the replica (see the specification of the replicaIDTable in [LDUP Update Protocol]). When associated with an item of information within a replica, the replicaID should be traceable to the entryUUID of the replicaSubEntry associated with the replica on which the modification was made. This allows for compressed internal storage of change sequence numbers while still ensuring that change sequence numbers will be universally unique regardless of the replication context from which they were first produced. S1 and S2 are sequence numbers which are used to order two events with the same Generalized Time and replicaID. In order to use string matching rules for equality and ordering with values with this encoding, the length of each field must be consistent. Thus, all instances of S1 MUST be represented with the same number of digits, using leading zeros as necessary. The same with S2 and replicaID. 8.2. Attribute Definitions 8.2.1. supportedReplicationProtocols ( 2.16.840.1.113719.1.142.4.x NAME 'supportedReplicationProtocols' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 EQUALITY caseIgnoreMatch DESC 'set of OIDs which represent the (set of) protocols supported by this server' ) This attribute is added to the root DSE entry of servers which support replication as defined by [LDUP Model]. {THIS IS NOT TRUE SINCE WE ALLOW MULTIPLE REPLICAS ROOTED AT THE SAME REPLICATION CONTEXT. DO WE JUST REMOVE THIS PARAGRAPH, OR DO WE REQUIRE THAT THE SERVER CHECK (HOW?) SOME SORT OF _REFERENCE COUNT_ AND DELETE A GIVEN CONTECT FROM REPLICACONTEXTROOTS ONLY WHEN ALL REPLICAS WITH THAT ROOT CONTEXT HAVE BEEN REMOVED? JOHN - RYAN AND RICK CAN'T SEE ANY REASON TO KEEP THIS; IT DOESN'T SEEM USEFUL SINCE YOU CAN ALWAYS FIND REPLICA ROOTS BY SEARCHING FOR replicaSubentry AS AN OBJECTCLASS. IS THIS REQUIRED FOR X.500 OR SOMETHING?} 8.2.2. replicaSubentries ( 2.16.840.1.113719.1.142.4.x NAME 'replicaSubentries' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch DESC 'names of all replicaSubEntry entries that correspond to the replicas on this server. This is contrasted with the replicaContextRoots which notes the replication contexts, but not the replicaSubEntry sub-entries for this server within the replication context' ) LDUP Information Model This attribute in the root DSE entry names the replicaSubentry entries that correspond to the replicas that are held on "this" server. This is slightly different than the replicaContextRoots root DSE entry attribute which lists the replication contexts held on this server. The replicaSubentries attribute indicates "this" server's replicaSubentry entry within each replication context. When replicas are defined on the server, servers MUST add the name of the replicaSubentry representing "this" server to this root DSE attribute. When replicas are removed from the server, servers MUST remove the name from this root DSE attribute if a value exists in this root DSE attribute. {IS THIS CONSISTENT WITH MRM? THIS SAYS THAT THE SERVER MUST MANAGE THIS ENTRY. IS THIS REALLY USEFUL?? SHOULD WE DELETE?} 8.2.3. attributeExclusionFilter ( 2.16.840.1.113719.1.142.4.1 NAME 'attributeExclusionFilter' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE USAGE dSAOperation ) The attributeExclusionFilter is intended to contain a list of attributes in the form of an AttributeDescriptionList as described in section 4.5.1 Search Request of [RFC2251] with the following interpretation: an empty attributeExclusionFilter means that no attributes are excluded; the special values "*" and "1.1" mean that ALL attributes are excluded. A non-empty attributeExclusionFilter attribute on a replica subentry describes the attributes NOT PRESENT on entries held by that replica. Replicas MUST NOT accept changes for attributes they're not permitted to hold, per the attributeInclusionFilter and attributeExclusionFilter attributes on their replica subentry. A non-empty attributeExclusionFilter attribute on a replication agreement subentry describes which additional attributes are to be excluded from the updates to be sent from the supplier replica to the consumer replica. 8.2.4. attributeInclusionFilter ( 2.16.840.1.113719.1.142.4.2 NAME 'attributeInclusionFilter' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE USAGE dSAOperation ) The attributeInclusionFilter is intended to contain a list of attributes in the form of an AttributeDescriptionList as described in section 4.5.1 Search Request of [RFC2251] with the following interpretation: an empty attributeInclusionFilter means that all LDUP Information Model attributes are included; the special value "*" means that ALL attributes are included; the special value "1.1" is meaningless and is ignored in this usage. A non-empty attributeInclusionFilter attribute on a replica subentry describes the attributes that may be PRESENT on entries held by that replica. Replicas MUST NOT accept changes for attributes they're not permitted to hold, per the attributeInclusionFilter and attributeExclusionFilter attributes on their replica subentry. It is an error to specify both an attributeExclusionFilter and an attributInclusionFilter in the same replicaSubentry. 8.2.5. replicaURI ( 2.16.840.1.113719.1.142.4.x NAME 'replicaURI' DESC 'LDAP URLs which indicate how to connect to this replica' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 EQUALITY caseExactMatch USAGE dSAOperation ) The replicaURI attribute is a multi-valued attribute used to list the set of LDAP URLs that should be used to contact the replica for replication sessions. If all URLs in the replicaURL attribute are not contactable, the replicaSecondaryURL attribute values should be used to establish a replication session with the replica. The replicaURI MUST be an LDAP URL as specified in RFC 2255. The replicaURI SHOULD specify only the host name (or IP address) of the destination replica and possibly a port number. Filters, base DN, and other LDAP URL components MUST be ignored if they are supplied. 8.2.6. replicationStatus (2.16.840.1.113719.1.142.4.3 NAME 'replicationStatus' DESC 'human readable status of last replication attempt' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) The replicationStatus attribute MAY be used to hold a human readable message describing the most recent replication session attempt for a replication agreement. For example, such a messages might include 1) 9980805162203Z # Success # 2) 19980805162322Z # Failure # Server too busy, try again 3) 19980805170215Z # Failure # Unable to connect to DSA LDUP Information Model 4) 19980806002301Z # Failure # Authentication failed 5) 19980806003201Z # Failure # lost connection, reset by peer It is suggested, but not required, that the time of a replication attempt (completion, if successful or failure, if not), the result of the attempt, and any additional information about a failure be included in the string message. It is suggested, but not required, that the messages be stored with language tags (English, French, German, Japanese, Chinese, per [RFC2596]) particularly if multiple translations of the error messages are available to the DSA implementers. Sequences of status entries SHOULD be written to log files or other persistent storage, or in multi-valued replication history attributes, but are not specified here. 8.2.7. replicaType (2.16.840.1.113719.1.142.4.4 NAME 'replicaType' DESC 'Enum: 0-reserved, 1-Primary, 2-Updateable, 3-ReadOnly, all others reserved' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 EQUALITY integerMatch SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) ReplicaType is a simple enumeration, used to identify what kind of replica is being described in a Replica object entry. A ReadOnly replica only accepts LDAP Search operations (to Read entries, list containers, and search for entries). Because no updates ever originate from ReadOnly replicas, they never have changes to send to another replica. However, a ReadOnly replica may be designated a supplier DSA in a replica agreement, if it is simply passing along information it receives from Updateable replicas about entries and their changes. ReadOnly replicas may be partial replicas. An Updateable replica may accept both LDAP Search operations (to read, list, or search entries), as well as modification operations (to add, modify, or delete entries). The consequences of having partial updateable replicas are not fully understood. LDAP DSAs MAY require updateable replicas to be complete replicas. A Primary replica is an Updateable replica, but it is "more special" than other Updateable replicas. When LDAP application want to direct their operations to a single replica, so that the application can be sure that all application LDAP modification LDUP Information Model (add, delete, modify) operations will be immediately visible to application readers, the Primary replica is a good choice. Such a use would be consistent with High Confidence DAP option [X518]. One such application might be a management application which creates new naming contexts or joins two naming contexts into a single naming context. Another application might be one which creates new replicas, or replication agreements. There SHOULD be only one Primary replica defined for a naming context at any time. If applications, expecting there to be a Primary replica discover, by search or inspection of ReplicaType attributes of the defined Replicas of a naming context, find more than one _ they should realize that something is wrong. There MAY be NO primary replica defined for a naming context. Primary replicas MAY NOT be partial replicas. The way in which replicas change their type, as from ReadOnly to Updateable, or Updateable to Primary is outside the scope of this document. Section 5.1 "Replica Type" of [LDUP MODEL] details the permissible combinations of replica types and sparse/fractional replicas. 8.2.8. updateVector ( 2.16.840.1.113719.1.142.4.6 NAME 'updateVector' SYNTAX 1.3.6.1.4.1.1466.115.121.1.TBD EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch NO-USER-MODIFICATION USAGE dSAOperation ) The attribute updateVector is a multi-valued attribute which contains information for a replica describing the latest changes received by the replica from other replicas. There may be only one ldapChangeSequenceNumber entry from each replica in the updateVector. That is to say, there is a unique value constraint on the ReplicaID component of entries in the list. 8.2.9. replicaSecondaryURI ( 2.16.840.1.113719.1.142.4.x NAME 'replicaSecondaryURI' DESC 'LDAP URLs which indicate how to connect to this replica' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 EQUALITY caseExactMatch USAGE dSAOperation ) The replicaSecondaryURI attribute is a multi-valued attribute used to list the set of LDAP URLs that should be used to contact the replica for replication sessions if all LDAP URLs in the replicaURL attribute are not contactable. LDUP Information Model 8.2.10. lostAndFoundEntryDN ( 2.16.840.1.113719.1.142.4.x NAME 'lostAndFoundEntryDN' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch SINGLE-VALUE DESC 'name of the entry under which orphaned entries will be moved during replication update processing by this replica.' ) This attribute indicates the location under which the replica will move orphaned entries that are encountered while performing replication updates. The attribute is single-valued and is specific to each replica. 8.2.11. replicaOnline ( 2.16.840.1.113719.1.142.4.x NAME 'replicaOnline' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 EQUALITY booleanMatch SINGLE-VALUE DESC 'indicates whether or not the replica will will initiate and/or respond to replication session start requests.' ) This attribute indicates whether the replica is ready and willing to participate in replication sessions with other replicas that are defined as holding the replication context. 8.2.12. replicaDN ( 2.16.840.1.113719.1.142.4.x NAME 'replicaDN' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch SINGLE-VALUE DESC 'name of the consumer replicaSubentry entry that the replicaAgreement links to.' ) This attribute is used to link a replicaAgreement entry (associated with a supplier of replication update information) to the consumer replica that will be contacted by replication sessions constrained by the replicaAgreement. 8.2.13. replicationMechanismOID ( 2.16.840.1.113719.1.142.4.x NAME 'replicationMechanismOID' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 EQUALITY caseIgnoreMatch SINGLE-VALUE DESC 'the OID which represents the specific replication protocol used for replication sessions between the identified supplier and consumer replicas.' ) LDUP Information Model This attribute identifies the specific replication protocol used for replication sessions between the supplier and consumer replicas associated by the replicaAgreement entry. This attribute must be a value that is within the set of attribute values for the supportedReplicationProtocols attribute in the root DSE entry. 8.2.14. replicationCredentialsDN ( 2.16.840.1.113719.1.142.4.x NAME 'replicationCredentialsDN' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch SINGLE-VALUE DESC 'name of a separate entry in the directory tree which contains the credentials information used in identifying the supplier replica to the consumer replica when initiating a replication session.' ) This attribute is used to establish a separate entry in the directory tree that will hold the credentials information that is used to establish the supplier's identity at the consumer when starting a replication session. By placing credentials information in a separate entry, "pointed to" with this attribute, credentials information can be placed in a portion of the directory tree that is not replicated across multiple replicas. It can also be _shared_ by several replication contexts. 8.2.15. replicationScheduleDN ( 2.16.840.1.113719.1.142.4.x NAME 'replicationScheduleDN' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch SINGLE-VALUE DESC 'name of an entry which contains the specific information used to establish when replication sessions will be initiated by this replica supplier.' ) This attribute is used to "point to" either a replicaEventSchedule or replicaTimeSchedule entry which describes when replication sessions should be initiated by a replica supplier. If not specified, a default schedule is assumed. See the section describing the replicaAgreement for more details. 8.2.16. updateVectorTrigger ( 2.16.840.1.113719.1.142.4.x NAME 'updateVectorTrigger' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 EQUALITY booleanMatch SINGLE-VALUE DESC 'indicates whether or not updates made to the replicas updateVector should be treated as updates that cause the secondsToWaitDefault attribute value to be used in determining when to initiate a replication session.' ) LDUP Information Model This attribute is used to indicate whether or not changes to the replica's updateVector should be included as updates that cause the secondsToWaitDefault attribute value to be used when determining when to initiate replication sessions. If updateVectorTrigger is set to FALSE, then secondsToWaitDefault will not be used when the replica's updateVector is updated. This implies that some other update will need to be performed to the replica before the updated updateVector will be sent via a replication session. If upateVectorTrigger is set to TRUE, then updates to the updateVector will be used in determining when replication sessions should be initiated. Note that setting secondsToWaitDefault to 0 coupled with updateVectorTrigger to TRUE would cause replication sessions to continually "chase themselves", potentially clogging networks with an infinite loop of replication sessions. This combination SHOULD be prevented in implementations. If not specified, the value for updateVectorTrigger is assumed to be FALSE. 8.2.17. secondsToWaitDefault (2.16.840.1.113719.1.142.4.x NAME 'secondsToWaitDefault' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 EQUALITY integerMatch SINGLE-VALUE DESC 'The number of seconds to wait after an update is made to the replica before initiating a replication session.' USAGE dSAOperation ) This attribute indicates the number of seconds that a replica should wait after an update is made to the replica before initiating a replication session. If not specified, the value is assumed to be 0. This attribute value is used for updates to all attributes that are NOT specified by either the attrs1 or attrs2 attributes. This attribute is always used for updates made to the replica's updateVector if the updateVectorTrigger attribute is set to TRUE. 8.2.18. secondsToWait1 (2.16.840.1.113719.1.142.4.x NAME 'secondsToWait1' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 EQUALITY integerMatch LDUP Information Model SINGLE-VALUE DESC 'The number of seconds to wait after an update is made to any attributes named in the attrs1 attribute before initiating a replication session.' USAGE dSAOperation ) This attribute is similar to the secondsToWaitDefault attribute in how it is used. This attribute, however, is used to apply only to the attributes listed in the attrs1 attribute. This allows updates to different attributes to cause replication sessions to be initiated either sooner or later than updates made to other attributes. 8.2.19. attrReplicationGroup1 ( 2.16.840.1.113719.1.142.4.x NAME 'attrReplicationGroup1' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 EQUALITY caseIgnoreMatch DESC 'the set of attributes that are associated with the secondsToWait1 attribute. When updates are made to any of these attributes on the replica, a replication session will be delayed until after secondsToWait1 seconds have passed.' ) This attribute identifies a set of attributes that are associated with the secondsToWait1 attribute. When secondsToWait1 seconds have passed since an update to any attribute identified in the attrs1 attribute, a replication session will be initiated. 8.2.20. secondsToWait2 (2.16.840.1.113719.1.142.4.x NAME 'secondsToWait2' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 EQUALITY integerMatch SINGLE-VALUE DESC 'The number of seconds to wait after an update is made to any attributes named in the attrs2 attribute before initiating a replication session.' USAGE dSAOperation ) This attribute is similar to the secondsToWaitDefault attribute in how it is used. This attribute, however, is used to apply only to the attributes listed in the attrs2 attribute. This allows updates to different attributes to cause replication sessions to be initiated either sooner or later than updates made to other attributes. 8.2.21. attrReplicationGroup2 LDUP Information Model ( 2.16.840.1.113719.1.142.4.x NAME 'attrReplicationGroup2' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 EQUALITY caseIgnoreMatch DESC 'the set of attributes that are associated with the secondsToWait2 attribute. When updates are made to any of these attributes on the replica, a replication session will be delayed until after secondsToWait2 seconds have passed.' ) This attribute identifies a set of attributes that are associated with the secondsToWait2 attribute. When secondsToWait2 seconds have passed since an update to any attribute identified in the attrs2 attribute, a replication session will be initiated. 8.2.22. scheduleTimePeriod ( 2.16.840.1.113719.1.142.4.x NAME 'scheduleTimePeriod' SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 EQUALITY caseIgnoreMatch SINGLE-VALUE DESC 'the absolute time range over which this time specification is valid.' ) This attribute is patterned after the TimePeriod property identified in RFC 3060 [RFC3060] and [Policy Schema]. Refer to these references for details on the format and interpretation of this attribute. 8.2.23. scheduleMonthOfYearMask ( 2.16.840.1.113719.1.142.4.x NAME 'scheduleMonthOfYearMask' SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 SINGLE-VALUE DESC 'mask identifying the months of the year during which replication sessions should be performed.' ) This attribute is patterned after the MonthOfYearMask property identified in RFC 3060 [RFC3060] and [Policy Schema]. Refer to these references for details on the format and interpretation of this attribute. 8.2.24. scheduleDayOfMonthMask ( 2.16.840.1.113719.1.142.4.x NAME 'scheduleDayOfMonthMask' SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 SINGLE-VALUE DESC 'mask identifying the days of the month during which replication sessions should be performed.' ) This attribute is patterned after the DayOfMonthMask property identified in RFC 3060 [RFC3060] and [Policy Schema]. Refer to these references for details on the format and interpretation of this attribute. LDUP Information Model 8.2.25. scheduleDayOfWeekMask ( 2.16.840.1.113719.1.142.4.x NAME 'scheduleDayOfWeekMask' SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 SINGLE-VALUE DESC 'mask identifying the days of the week during which replication sessions should be performed.' ) This attribute is patterned after the DayOfWeekMask property identified in RFC 3060 [RFC3060] and [Policy Schema]. Refer to these references for details on the format and interpretation of this attribute. 8.2.26. scheduleTimeOfDayMask ( 2.16.840.1.113719.1.142.4.x NAME 'scheduleTimeOfDayMask' SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 EQUALITY caseIgnoreMatch DESC 'mask identifying the times during the day when replication sessions should be initiated.' ) This attribute is patterned after the TimeOfDayMask property identified in RFC 3060 [RFC3060] and [Policy Schema]. Refer to these references for details on the format and interpretation of this attribute. 8.2.27. scheduleLocalOrUtcTime ( 2.16.840.1.113719.1.142.4.x NAME 'scheduleLocalOrUtcTime' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 EQUALITY integerMatch SINGLE-VALUE DESC 'flag indicating whether or not times in the scheduleTimeOfDayMask are in UTC time or local time.' ) This attribute is patterned after the LocaOrUtcTime property identified in RFC 3060 [RFC3060] and [Policy Schema]. Refer to these references for details on the format and interpretation of this attribute. 8.3. Class Definitions 8.3.1. ReplicationContext ( 2.16.840.1.113719.1.142.6.2.2 NAME 'replicationContext' SUP top AUXILIARY ) The replicationContext auxiliary class, when present on an object, indicates the beginning, or root, of a naming context. The naming context is said to be rooted at the entry with the replicationContext auxiliary class in its list of object classes. LDUP Information Model The root-most entry of a naming context is the entry with the replicationContext auxiliary class in its list of object classes. Characteristics of the replication topology of a naming context are defined in the replicaSubentry sub-entries associated with the naming context. The attribute accessControlPolicyOID has been removed from here, and should be published as an subentry subordinate to the replicationContext, instead. The attribute nameContextCreationTimestamp used here in previous drafts has been eliminated as redundant. The ldapChangeSequenceNumber associated with the replicationContext value in the list of objectclass attribute values serves the same purpose. 8.3.2. replicaSubentry ( 2.16.840.1.113719.1.142.6.3.2 NAME 'replicaSubentry-2' SUP subentry STRUCTURAL MUST ( cn $ replicaURI $ replicaType $ lostAndFoundEntryDN $ replicaOnline ) MAY ( attributeExclusionFilter $ attributeInclusionFilter $ replicaSecondaryURI $ description $ updateVector ) ) Entries of type replicaSubentry MUST be named by their cn attribute as defined in [LDAP Subentry]. A replicationContext may have more than one replicaSubentry. The attributes attributeExclusionFilter and attributeInclusionFilter, if present, govern which entries and attributes from the local naming context are to be sent (or not sent) to the replica named in replicaDN of replica agreements for this replica. The attributeExclusionFilter names attributes which SHOULD NOT be sent. The attributeInclusionFilter names attributes which SHOULD be sent. The attribute replicaURI contains information in ldapURI format that can be used to contact (i.e., open a connection to) this replica. The replicaSecondaryURI contains the set of ldapURI format addresses that can be used as backup addresses if the replicaURI values cannot be used. The lostAndFoundEntryDN attribute is single-valued attribute that contains the distinguished name of the lost and found entry under which orphaned entries are placed. LDUP Information Model The replicaOnline attribute is a Boolean attribute which indicates whether or not this replica will supply and/or accept replication sessions. This attribute can be used to prevent replication sessions from being started before replicaAgreement entries have been defined. The attribute description contains a human-readable description of the sub-entry. The attribute updateVector contains a set of ldapChangeSequenceNumbers, one for each of the other replicas for this naming context, which records, from this replicas perspective, the last change event received from the other indicated replica. The subtreespecification attribute of the subentry superior object class is used to define the scope of the replication context. Use of the subtreespecification value SHOULD be limited to the base and components of ChopSpecification portions of this attribute. 8.3.3. replicaAgreement ( ?? NAME 'replicaAgreement' SUP subentry STRUCTURAL MUST ( cn ) MAY ( description $ replicaDN $ replicationMechanismOID $ replicationStatus $ replicationCredentialsDN $ replicationScheduleDN ) ) Entries of this type MUST be placed just below replicaSubentry entries in the directory tree. Name subordination is used to associate a replicaAgreement with the replicaSubentry representing the supplier of changes for all subordinate replication agreements. Processing of allowable changes to be sent is as follows: 1) the attributeInclusionFilter from the replica subentry defines a set of attributes which SHOULD be sent, less exclusions; 2) the union of attributes excluded by the attributeExclusionFilter from the replicaSubentry and the attributeExclusionFilter from the replicaAgreement defines a set of attributes which SHOULD NOT be sent; LDUP Information Model 3) the subtraction of attributes which SHOULD NOT be sent by (2) from the attributes which SHOULD be sent by (1) constitute the set of attributes for which changes MAY be sent. The attribute description contains a human-readable description of the sub-entry. The attribute replicaDN of syntax distinguishedName names another sub-entry of type replicaSubentry to whom changes are to be sent. If there is no value for the replicaDN attribute on a replicaAgreement, the replicaAgreement is ignored. Absence of a value may occur briefly when replicas and replica agreements are first being created, or when the replica to which a replica agreement applies is being deleted. The attribute replicationMechanismOID is used to indicate the type of replication protocol that is used between the supplier and consumer. If not specified, the default replication protocol defined in [LDUP Update Replication Protocol] is assumed. The attribute replicationStatus MAY be used to record the most recent result of an attempt to send changes to the replica named in replicaDN, whether success, or if failure, the nature of the problem encountered. The attribute replicationCredentialsDN, if present, names an entry which contains information used to initialize authenticated the LDAP connection between the supplier and consumer. Separating the credentials information from the replicaAgreement itself allows for this information to be placed outside of the replication context. The attribute replicationScheduleDN, if present, names an entry which governs the schedule for replication attempts. If not present, replication MUST be attempted when there are changes to be sent (i.e. a default replica schedule of type replicaEventSchedule is assumed with secondsToWaitDefault=0 and updateVectorTrigger=FALSE). See Section on replicaEventSchedule for more information about these attributes and their meaning. The subtreespecification attribute of the subentry superior object class is ignored. 8.3.4. replicaEventSchedule ( 2.16.840.1.113719.1.142.6.x.1 NAME 'replicaEventSchedule' SUP subentry STRUCTURAL MUST ( cn ) MAY ( description $ updateVectorTrigger $ secondsToWaitDefault $ secondsToWait1 $ attrs1 $ LDUP Information Model secondsToWait2 $ attrs2 ) ) The replicaEventSchedule object class is used to specify when to initiate replication sessions in terms of the time to wait after an update is made to the supplier replica. The attribute cn is used as the naming attribute for the replicaEventSchedule object class. It is thought that replicaEventSchedule entries would be placed below replicaAgreement entries but this is not required. The attribute description contains a human-readable description of the sub-entry. The attribute updateVectorTrigger is a Boolean attribute which indicates whether or not the update of the supplier's updateVector attribute should, itself, be used to trigger replication sessions. Since the updateVector is, itself, an attribute, it has CSNs associated with each of its values. Note that these CSNs may be different from the CSNs that are in the attribute values themselves. Thus, it is possible that the update to the updateVector would, itself, need to be treated as an update to be replicated. Indeed, this is necessary in order for "transitive replication" to work. The secondsToWaitDefault attribute is a non-negative integer value. This value indicates the number of seconds to wait after an update is made before starting a replication session. This value is used for all attributes other than those noted in the attrs1 and attrs2 attributes. The secondsToWait1 attribute is similar to the secondsToWaitDefault attribute. This non-negative integer value is used whenever any attribute listed in the attrs1 attribute is updated. The secondsToWait2 attribute is similar to the secondsToWait1 attribute but is associated with the attrs2 attribute. Note that whenever any of these seconds-to-wait time periods has expired, a replication session should be initiated and the full set of information that needs to be replicated should be sent to the consumer replica. This implies that some information would be replicated before its associated seconds-to-wait time period had expired. The subtreespecification attribute of the subentry superior object class is ignored. 8.3.5. replicaTimeSchedule ( 2.16.840.1.113719.1.142.6.x.1 NAME 'replicaTimeSchedule' SUP subentry STRUCTURAL LDUP Information Model MUST ( cn ) MAY ( description $ scheduleTimePeriod $ scheduleMonthOfYearMask $ scheduleDayOfMonthMask $ scheduleDayOfWeekMask $ scheduleTimeOfDayMask $ scheduleLocalOrUtcTime ) ) The replicaTimeSchedule object class is used to specify when to initiate replication sessions based on a scheduled time basis rather than in relation to when updates are made to the supplier replica. The attribute cn is used as the naming attribute for the replicaTimechedule object class. It is thought that replicaTimeSchedule entries would be placed below replicaAgreement entries but this is not required. The attribute description contains a human-readable description of the sub-entry. The remaining attributes in this object class are patterned after the attributes defined for the policyTimePeriodCondition construct defined in the Policy Core Information Model [RFC3060]. Because the LDAP schema mapping for this portion of the CIM model is not complete at this time, these attributes are defined specifically for this LDUP-related object class. Refer to RFC 3060 for details of the formats for the scheduleTimePeriod, scheduleMonthOfYearMask, scheduleDayOfMonthMask, scheduleDayOfWeekMask, scheduleTimeOfDayMask, and scheduleLocalOrUtcTime attributes. The subtreespecification attribute of the subentry superior object class is ignored. 9. Semantics of the information model The intent of this information model is to allow for useful and expected operation while requiring a minimum amount of data to be specified. In this spirit, replicaAgreement entries are treated as "constraints" on when to initiate replication sessions, not "requirements" on being able to initiate replication sessions. To clarify this concept, two examples are provided in this section. The first example shows the minimal set of information required to get replication going between three replicas: dn: ou=accounting, o=your company objectclass: organizationalUnit objectclass: replicationContext ou: accounting dn: cn=replica1, ou=accounting, o=your company LDUP Information Model objectclass: subentry objectclass: replicaSubentry-2 cn: replica1 subtreespecification: {} description: replica in location 1 replicaURI: ldap://sys1.yourcompany.com replicaType: 2 lostAndFoundEntryDN: cn=lostAndFound1, o=your company replicaOnline: TRUE dn: cn=replica2, ou=accounting, o=your company objectclass: subentry objectclass: replicaSubentry-2 cn: replica2 subtreespecification: {} description: replica in location 2 replicaURI: ldap://sys2.yourcompany.com replicaType: 2 lostAndFoundEntryDN: cn=lostAndFound2, o=your company replicaOnline: TRUE dn: cn=replica3, ou=accounting, o=your company objectclass: subentry objectclass: replicaSubentry-2 cn: replica3 subtreespecification: {} description: replica in location 3 replicaURI: ldap://sys2.yourcompany.com replicaType: 2 lostAndFoundEntryDN: cn=lostAndFound3, o=your company replicaOnline: TRUE With replicaSubentry entries defined as shown in this first example, replication sessions will be initiated by all replicas whenever an update is made to any attribute within any entries in the replicationContext. The default event schedule will be used which indicates that a replication session is initiated immediately after an update is made to a replica. Further, replication sessions would be initiated to ALL OTHER replicas. As this shows, maximal replication is defined using a minimal amount of configuration. The second example shows how replication sessions can be constrained by replicaAgreement entries. This example builds on the data shown in the first example. Assume that the following entries are added to the entries defined in the first example: dn: cn=agreement1->2, cn=replica1, ou=accounting, o=your company objectclass: subentry objectclass: replicaAgreement cn: agreement1->2 subtreespecification: {} description: Replica agreement constraining replication sessions from replica 1 to replica 2. LDUP Information Model replicationScheduleDN: cn=schedule1, cn=replica1, ou=accounting, o=your company replicaDN: cn=replica2, ou=accounting, o=your company dn: cn=agreement1->3, cn=replica1, ou=accounting, o=your company objectclass: subentry objectclass: replicaAgreement cn: agreement1->3 subtreespecification: {} description: Replica agreement constraining replication sessions from replica 1 to replica 3. replicationScheduleDN: cn=schedule1, cn=replica1, ou=accounting, o=your company replicaDN: cn=replica3, ou=accounting, o=your company dn: cn=schedule1, cn=replica1, ou=accounting, o=your company objectclass: subentry objectclass: replicaEventSchedule cn: schedule1 subtreespecification: {} description: schedule that initiates replication one minute after any update (including to the updateVector) is made to the replica. secondsToWaitDefault: 60 updateVectorTrigger: TRUE dn: cn=agreement2->1, cn=replica2, ou=accounting, o=your company objectclass: subentry objectclass: replicaAgreement cn: agreement2->1 subtreespecification: {} description: Replica agreement constraining replication sessions from replica 2 to replica 1. replicationScheduleDN: cn=schedule2, cn=replica2, ou=accounting, o=your company replicaDN: cn=replica1, ou=accounting, o=your company dn: cn=agreement2->3, cn=replica2, ou=accounting, o=your company objectclass: subentry objectclass: replicaAgreement cn: agreement2->3 subtreespecification: {} description: Replica agreement constraining replication sessions from replica 2 to replica 3. replicationScheduleDN: cn=schedule2, cn=replica2, ou=accounting, o=your company replicaDN: cn=replica2, ou=accounting, o=your company dn: cn=schedule2, cn=replica2, ou=accounting, o=your company objectclass: subentry objectclass: replicaEventSchedule cn: schedule2 subtreespecification: {} description: schedule that initiates replication two minutes LDUP Information Model after any update (including to the updateVector) is made to the replica. secondsToWaitDefault: 120 updateVectorTrigger: TRUE dn: cn=agreement3->1, cn=replica3, ou=accounting, o=your company objectclass: subentry objectclass: replicaAgreement cn: agreement3->1 subtreespecification: {} description: Replica agreement constraining replication sessions from replica 3 to replica 1. replicationScheduleDN: cn=schedule3, cn=replica3, ou=accounting, o=your company replicaDN: cn=replica1, ou=accounting, o=your company dn: cn=agreement3->2, cn=replica3, ou=accounting, o=your company objectclass: subentry objectclass: replicaAgreement cn: agreement3->2 subtreespecification: {} description: Replica agreement constraining replication sessions from replica 3 to replica 2. replicationScheduleDN: cn=schedule3, cn=replica3, ou=accounting, o=your company replicaDN: cn=replica2, ou=accounting, o=your company dn: cn=schedule3, cn=replica3, ou=accounting, o=your company objectclass: subentry objectclass: replicaEventSchedule cn: schedule3 subtreespecification: {} description: schedule that initiates replication one minute after any update (including to the updateVector) is made to the replica. secondsToWaitDefault: 60 updateVectorTrigger: TRUE In this example, replication sessions are limited such that they will begin one or two minutes after an update is made to any one replica, depending on the replica on which the update was made. This "constrains" the replication session initiation from the default of "immediate replication" of updates. There are many ways in which the constraints around when to initiate and/or accept replication sessions between two replicas. The information model defined here provides a small set of options. More elaborate policies can be defined and this is left as a future exercise. It is hoped that the work from the Policy workgroup can offer schema that would support the creation of these complex policies. LDUP Information Model 10. Object Identifier Assignments The LDUP OID prefix is ID ::= OBJECT IDENTIFIER ldup ID ::= { joint-iso-ccitt(2) country(16) us(840) organization(1) novell(113719) novell-internal- OIDS(1) ldup(142) } The OID assignments defined in this document are: Attributes: attributeExclusionFilter ID ::= 2.16.840.1.113719.1.142.4.1 attributeInclusionFilter ID ::= 2.16.840.1.113719.1.142.4.2 replicationStatus ID ::= 2.16.840.1.113719.1.142.4.3 replicaType ID ::= 2.16.840.1.113719.1.142.4.4 secToWaitClass1 ID ::= 2.16.840.1.113719.1.142.4.5.1 - OBSOLETE secToWaitClass2 ID ::= 2.16.840.1.113719.1.142.4.5.2 - OBSOLETE secToWaitClass3 ID ::= 2.16.840.1.113719.1.142.4.5.3 - OBSOLETE secToWaitClass4 ID ::= 2.16.840.1.113719.1.142.4.5.4 - OBSOLETE secToWaitClass5 ID ::= 2.16.840.1.113719.1.142.4.5.5 - OBSOLETE updateVector ID ::= 2.16.840.1.113719.1.142.4.6 replicaURI ID ::= 2.16.840.1.113719.1.142.4.x replicaSecondaryURI ID ::= 2.16.840.1.113719.1.142.4.x lostAndFoundEntryDN ID ::= 2.16.840.1.113719.1.142.4.x replicaOnline ID ::= 2.16.840.1.113719.1.142.4.x replicaDN ID ::= 2.16.840.1.113719.1.142.4.x replicationMechanismOID ID ::= 2.16.840.1.113719.1.142.4.x replicationCredentialsDN ID ::= 2.16.840.1.113719.1.142.4.x replicationScheduleDN ID ::= 2.16.840.1.113719.1.142.4.x updateVectorTrigger ID ::= 2.16.840.1.113719.1.142.4.x secondsToWaitDefault ID ::= 2.16.840.1.113719.1.142.4.x secondsToWait1 ID ::= 2.16.840.1.113719.1.142.4.x attrReplicationGroup1 ID ::= 2.16.840.1.113719.1.142.4.x secondsToWait2 ID ::= 2.16.840.1.113719.1.142.4.x attrReplicationGroup2 ID ::= 2.16.840.1.113719.1.142.4.x scheduleTimePeriod ID ::= 2.16.840.1.113719.1.142.4.x scheduleMonthOfYearMask ID ::= 2.16.840.1.113719.1.142.4.x scheduleDayOfMonthMask ID ::= 2.16.840.1.113719.1.142.4.x scheduleDayOfWeekMask ID ::= 2.16.840.1.113719.1.142.4.x scheduleTimeOfDayMask ID ::= 2.16.840.1.113719.1.142.4.x scheduleLocalOrUtcTime ID ::= 2.16.840.1.113719.1.142.4.x supportedReplicationProtocols ID ::= 2.16.840.1.113719.1.142.4.x replicaContextRoots ID ::= 2.16.840.1.113719.1.142.4.x replicaSubentries ID ::= 2.16.840.1.113719.1.142.4.x Object Classes: LDUP Information Model eventScheduledSubentry ID ::= 2.16.840.1.113719.1.142.6.1 - OBSOLETE nameContext ID ::= 2.16.840.1.113719.1.142.6.2.1 - OBSOLETE replicaSubentry ID ::= 2.16.840.1.113719.1.142.6.3.1 - OBSOLETE replicaAgreementSubentry ID ::= 2.16.840.1.113719.1.142.6.4.1 _ OBSOLETE replicationContext ID ::= 2.16.840.1.113719.1.142.6.2.2 replicaSubEntry-2 ID ::= 2.16.840.1.113719.1.142.6.3.2 replicaAgreementSubEntry-2 ID ::= 2.16.840.1.113719.1.142.6.4.2 - OBSOLETE eventScheduledSubentry ID ::= 2.16.840.1.113719.1.142.6.1 - OBSOLETE replicaEventSchedule ID ::= 2.16.840.1.113719.1.142.6.x.1 replicaTimeSchedule ID ::= 2.16.840.1.113719.1.142.6.x.1 replicaAgreement ID ::= TBD Note: Object Class OIDs have version numbers, Attribute OIDs don't. 11. Security Considerations Many of the attributes and object classes described in this document should be considered "security sensitive", and protected from unintended modification by LDAP servers. Generally, creating Naming Contexts, Replicas and Replica Agreement entries should only be allowed by directory administrators who are authorized to do so. The values of attributes defined here are intended to control the behavior of the directory service agents, themselves. Unintended modification of their values may result in incomplete replication of data (if ldapSearchFilter or attributeExclusionFilter are changed), inappropriate disclosure of information (if attributeInclusionFilter is changed), or updates may be lost (if updateVector is changed). To avoid depending to much on the ldapAccessPoint values for other replicas, connections between LDAP servers for the purpose of replication MUST ALWAYS be authenticated using an authentication mechanism appropriate for the nature of information to be exchanged. References [LDUP Model] - J. Merrells, E. Reed, U. Srinivisan, "An Abstract Model of LDAP Replication", Internet draft, draft-ietf-ldup-model- 08.txt, March 2003. [LDUP Requirements] - E. Stokes, R. Weiser, R. Moats, R. Huber, "Lightweight Directory Access Protocol (version 3) Replication Requirements", RFC 3384, October 2002. LDUP Information Model [LDAP Subentry] _ K. Zeilenga, Stephen Legg, "Subentries in LDAP", Internet draft, draft-zeilenga-ldap-subentry-07.txt, August 2002. [LDUP Update Protocol] _ J. McMeeking, "The LDUP Replication Update Protocol", Internet Draft, draft-ietf-ldup-protocol-04.txt, March 2003. [Policy Schema] - J. Strassner, B. Moore, R. Moats, E. Ellesson, "Policy Core LDAP Schema", Internet draft, draft-ietf-policy-core- schema-16.txt, October 2002. [RFC822] _ D. Crocker, "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES", August 1982, RFC 822 [RFC2251] _ M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3)", December 1997, RFC 2251 [RFC2252] _ M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", December 1997, RFC 2252 [RFC2255] _ T. Howes, M. Smith, _The LDAP URL Format_, December 1997, RFC 2255. [RFC2596] - 2596 M. Wahl, T. Howes, _Use of Language Codes in LDAP_, May 1999, RFC2596. [RFC3060] _ B. Moore, E. Ellesson, J. Strassner, A. Westerinen, "Policy Core Information Model _ Version 1 Specification", February 2001, RFC 3060 [X518] - ITU-T Recommendation X.518 (1997) | ISO/IEC 9594-4:1998, Information Technology _ Open Systems Interconnection _ The Directory: Procedures for Distributed Operation [X680] - ITU-T Recommendation X.680 (1994) | ISO/IEC 8824-1:1995, Information technology _ Abstract Syntax Notation One (ASN.1): Specification of Basic Notation 12. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process LDUP Information Model must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 13. Acknowledgements The authors would like to thank Ed Reed and Tim Han, the authors of the original infomod draft, for all their work. The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 14. Authors' Addresses Richard Huber AT&T Laboratories Email: rvh@att.com John McMeeking IBM Email: jmcmeek@us.ibm.com Ryan Moats Lemur Networks, Inc. Email: rmoats@lemurnetworks.net LDUP Mailing List: ietf-ldup@idc.org From owner-ietf-ldup@mail.imc.org Sun Jun 29 11:04:25 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00343 for ; Sun, 29 Jun 2003 11:04:25 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5TExmFK026764 for ; Sun, 29 Jun 2003 07:59:48 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5TExmXO026763 for ietf-ldup-bks; Sun, 29 Jun 2003 07:59:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from Tempo.Update.UU.SE (Tempo.Update.UU.SE [130.238.19.17]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5TExfFK026755 for ; Sun, 29 Jun 2003 07:59:46 -0700 (PDT) (envelope-from thorild@Update.UU.SE) Received: from Tempo.Update.UU.SE (ip6-localhost [IPv6:::1]) by Tempo.Update.UU.SE (8.12.9/8.12.9/Update-Iltempogigante) with ESMTP id h5TExfn4021953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Jun 2003 16:59:41 +0200 Received: (from thorild@localhost) by Tempo.Update.UU.SE (8.12.9/8.12.9/Update-Iltempogigante-submit) id h5TExe3X021950; Sun, 29 Jun 2003 16:59:40 +0200 X-Authentication-Warning: Tempo.Update.UU.SE: thorild set sender to thorild@Update.UU.SE using -f From: Thorild Selen MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <16126.65244.824929.823030@Tempo.Update.UU.SE> Date: Sun, 29 Jun 2003 16:59:40 +0200 To: rmoats@lemurnetworks.net Cc: ietf-ldup@imc.org Subject: InfoMod draft typos In-Reply-To: <20030629074825.B1987@privateer.local.windrose.omaha.ne.us> References: <20030629074825.B1987@privateer.local.windrose.omaha.ne.us> X-Mailer: VM 7.16 under Emacs 20.7.2 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h5TExlFK026759 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Found a few typos in this draft: 8.2.5: replicaURL: should be replicaURI replicaSecondaryURL: should be replicaSecondaryURI 8.2.6: 9980805162203Z: Probably intended to be 19980805162203Z; no big deal since it's just an example. 8.2.9: replicaURL: should be replicaURI Thorild Selén Datorföreningen Update / Update Computer Club, Uppsala, SE From owner-ietf-ldup@mail.imc.org Sun Jun 29 11:47:23 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00896 for ; Sun, 29 Jun 2003 11:47:22 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5TFhmFK027807 for ; Sun, 29 Jun 2003 08:43:48 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5TFhmlw027806 for ietf-ldup-bks; Sun, 29 Jun 2003 08:43:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from tconl91223.tconl.com (tconl91223.tconl.com [204.26.91.223]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5TFhkFK027801 for ; Sun, 29 Jun 2003 08:43:46 -0700 (PDT) (envelope-from jayhawk@tconl91223.tconl.com) Received: (from jayhawk@localhost) by tconl91223.tconl.com (8.11.6/8.11.0) id h5TFhXG02490; Sun, 29 Jun 2003 10:43:33 -0500 Date: Sun, 29 Jun 2003 10:43:33 -0500 From: Ryan Moats To: Thorild Selen Cc: ietf-ldup@imc.org Subject: Re: InfoMod draft typos Message-ID: <20030629104333.C2375@privateer.local.windrose.omaha.ne.us> Reply-To: rmoats@lemurnetworks.net References: <20030629074825.B1987@privateer.local.windrose.omaha.ne.us> <16126.65244.824929.823030@Tempo.Update.UU.SE> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <16126.65244.824929.823030@Tempo.Update.UU.SE>; from thorild@Update.UU.SE on Sun, Jun 29, 2003 at 04:59:40PM +0200 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit On Sun, Jun 29, 2003 at 04:59:40PM +0200, Thorild Selen wrote: | | Found a few typos in this draft: | | 8.2.5: replicaURL: should be replicaURI | replicaSecondaryURL: should be replicaSecondaryURI | | 8.2.6: 9980805162203Z: Probably intended to be 19980805162203Z; | no big deal since it's just an example. | | 8.2.9: replicaURL: should be replicaURI | | | Thorild Selén | Datorföreningen Update / Update Computer Club, Uppsala, SE | Thanks, so noted. Ryan