From owner-ietf-ldup@mail.imc.org Mon Oct 1 15:26:24 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28194 for ; Mon, 1 Oct 2001 15:26:23 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f91J4Pv13278 for ietf-ldup-bks; Mon, 1 Oct 2001 12:04:25 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f91J4OD13273 for ; Mon, 1 Oct 2001 12:04:24 -0700 (PDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA12942; Mon, 1 Oct 2001 15:01:48 -0400 Received: from d27ml001.rchland.ibm.com (d27ml001.rchland.ibm.com [9.5.39.28]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f91J2qW249614; Mon, 1 Oct 2001 15:02:52 -0400 Subject: RE: Operations crossing replication contexts To: Cc: ietf-ldup@imc.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "John McMeeking" Date: Mon, 1 Oct 2001 14:06:27 -0500 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 5.0.8 |June 18, 2001) at 10/01/2001 02:06:37 PM MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=86256AD80068F61D8f9e8a93df938690918c86256AD80068F61D" Content-Disposition: inline Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --0__=86256AD80068F61D8f9e8a93df938690918c86256AD80068F61D Content-type: text/plain; charset=us-ascii I'll defer to Steven on this. I think these may affect the URP document, but even if they don't, we ought to define how to handle these cases, or define constraints/expected behavior, somewhere in LDUP. My original concern with respect to URP was the relationship of L&F to replication contexts. URP seems to assume there is a single L&F; for example, 4.1 describes a pre-allocated UID for the Lost&Found entry. The information model implies there could be a single L&F for each replication context. On further reflection, it may not make any difference. It may only be necessary that a server maintain some association between an entry in L&F and the replication context it came from. Each replication primitive is associated with a replication context. If LDUP uses a pre-allocated UID for L&F during a replication session, the consumer server could have a single L&F, or multiple L&F. In the case of a single L&F, the consumer could "tag" the entry with a replication context. In the case of separate L&F for each replication context, the consumer places the entry in the proper L&F. In either case, the replication session need only flow the pre-allocated L&F UID and the replication context. The move scenario that Steven brought up complicates this analysis. There might be two replication contexts associated with an operation. URP works fine for handling the replication conflicts (example below), but we may not have enough information for administrative repair to work properly. Specifically, when an adminstrator performs repair via LDAP client operations, under what replication context does that operation get replicated? This applies to any operation that involves multiple replication contexts. A brief example of the move scenario, with: 2 replication contexts: ou=engineering and ou=manufacting; 3 servers: server 1 contains both contexts server 2 contains ou=engineering server 3 contains ou=manufacturing server 4 contains both contexts move cn=coyote from engineering to manufacturing (do this at server 1) LDUP replicates a MoveEntryPrimitive. What replication context is the primitive associated with? Ignoring that for a moment... On server 2, a glue entry is created in L&F to represent ou=manufacturing, and cn=coyote moved under that glue entry. On server 3, a glue entry is created for cn=coyote, and it is placed under ou=manufacturing. Figures - last time I read this I thought that glue entries were only present in L&F. If I followed this correctly, glue entries can show up elsewhere. On server 4, everything works fine. URP handled this in a reasonable way. Maybe we think the outcome is fine; if so, we should say this somewhere (model?). If we don't think the original client operation should have been allowed, that is a change (but not to URP). If we think that cn=coyote should have been created on server 3 (rather than a glue entry),then there is work to be done to a few documents; this probably requires change to the protocol, but possibly not to URP. John McMeeking OS/400 Directory Services (507)253-4596 (T/L) 553-4596 "John Strassner" liden.com> cc: Subject: RE: Operations crossing replication contexts 09/29/2001 03:55 PM Please respond to john.strassner Hmmm, just when I was about to call to see if all of the comments were finished on URP, up pops this message. So I have a quick question to John, Steven, and others that are interested in this thread: is it your aim to resolve this question as part of the URP Last Call, or is this something that you think affects other documents than URP? thanks and kind regards, John -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of John McMeeking Sent: Friday, September 28, 2001 6:52 AM To: ietf-ldup@imc.org Subject: Operations crossing replication contexts Thought I'd move a discussion between Steven Legg and myself into the public eye... This particular discussion is about how to deal with operations that cross replication contexts: - move an entry/subtree from one replication context to another - delete/rename entries that ancesters of replication contexts (mentioned at March IETF meeting) It hasn't progressed to the point of proposing concrete solutions just yet. With respect to moving entries between replication contexts, we note that this has to be initiated on a server that has contains updateable replicas of both contexts, else the server would fail the client request. However, others servers may have replicas of only one of the contexts. Perhaps such an action shouldn't be allowed. Perhaps it should be allowed only if the initial server can detect (based on replicaSubebtries) that both contexts are present on all relevant servers. Or it requires a bit more invention. With respect to the second point, this has to do with how a server knows what the boundaries of a replication context are, then how the server(s) should behave. An engineering group was formed at the March IETF meeting. I couldn't attend the first get together, and I am not aware that anything happened afterwards. An example of the situation: - renaming the ancester of a relication context has the effect the renaming the child replication context. The server where the ancester is located may not be aware that the child context even exists. Should this be allowed? How would replication handle it? John McMeeking IBM ----- Forwarded by John McMeeking/Rochester/IBM on 09/28/2001 08:31 AM ----- "Steven Legg" cc: Subject: RE: Single lost & found (RE: WG Last Call on URP 09/28/2001 12:01 I-D) AM Please respond to steven.legg John, Apologies for taking my time responding. > Pondering this a bit more... > > The problem of cross replication context operations could be > rather crudely > solved by stating that LDUP does not support moving entries > into or out of > areas of replication. You must delete entries from the source, and > recreate them in the target. Hopefully an implementation > would provide > some tools to make that exercise simpler. I'm not sure requiring delete/insert for moves between replication contexts actually solves more problems than it creates. Moves by delete/insert are something I want to avoid, in part because it makes moving subtrees expensive and dangerous. Expensive because every entry in the subtree has to be deleted and reinserted, and dangerous because other updates to entries in the subtree could get lost or corrupted. Recovery from system crashes in the middle of a subtree move also has to be dealt with. Since the propagation of updates between servers is not instantaneous, we would still have to deal with the possibility of a clash between an already propagating move update and a propagating administrative action to repartition the replication area. Propagation delays and conflicting changes also make it possible for a server to perform what looks to it like an intra-context move but which to another server appears to be an inter-context move. This can happen even if both servers have full knowledge of the replication context boundaries. I also have concerns with any solution where consumer DSAs making secondary shadowing agreements can hamstring the operations of the original supplier DSA, i.e. by creating additional replication context boundaries across which the original supplier can no longer do simple moves. In X.500 replication (which we implement) a supplier DSA doesn't need to have any knowledge of the secondary replication agreements a consumer might make. This is a good thing for scalability in large distributed environments. My preferred approach is to have a go at solving the problems with entries moving in and out scope for partial replicas, and apply that solution to entries moving in and out of replication contexts, since the problem spaces appear to be related. I haven't been devoting much time to thinking about replication in recent times but an LDUP implementation is on the agenda for our next release so I will be spending more time on it. In the last couple of days I've been following up on the idea of tagging entries with the replication areas in which they appear. This approach is looking promising. I'll let you and the rest of the working group know what I discover. > > That still leaves the question of how a server knows when an operation > crosses such boundaries. I asked that question at the March > IETF meeting > in Minneapolis. An engineering group was formed (to include LDAP-EXT > folks), and far as I can tell, never met. I've had various > thoughts on the > matter. Except for the effects of propagation delays I don't see a serious problem in deciding if a move crosses a boundary, but maybe we're not talking about the same thing. A server can only action a move operation if it masters both the old and new superior entries. If it masters those entries then it will have the necessary information about the replication context of each. A new superior entry in a child replication context held in the same server presents no problem. If the child replication context is primarily held in a different server then the superior server either doesn't master the new superior so it will disallow the move, or it replicates the subordinate server's replication context in which case it has the necessary information. > - One idea was that each server participated in a > domain-like entity,where > the definition of the domain resides in LDAP as a special area of > replication. Each server then can has knowledge of all the > replication > contexts and all the servers. Alternately, x.500 glue > entries might be > used. My sense is that this type of approach implies more distributed > directory function than the LDUP members want. > - At a minimum, it seems that each server needs to know the > bounds of the > replicas it hosts, that is the names of subordinate > replication contexts. > I envision this being done through something like an > operational attribute > of a replication context. When a child area of replication > is created, the > "childReplicationContext" attribute of the parent replication > context is > updated, and that change replicated to other replicas of the parent. > Deleting a child replication context may require > administrative action, as > I don't see how any single server could know that it held the last > remaining copy of the child area of replication (unless this > happens on a > server that holds both the parent and child replication contexts). I > suppose creating a child area of replication might require > administrative > action too, unless we require that the child be created on a > server that > also holds the parent. And as I think this through more, I > suppose that > some sort of glue entry would do the trick here (possibly > with a reference > to some server containing that replication context). > > Either way, it implies that something holds knowledge of the entire > replication topology, and that a tool hide as much of the nastiness as > possible. > > Any thoughts? And I suppose I really ought to put this > discussion on the > LDUP mailing list. Do you agree? It wouldn't hurt. Regards, Steven #### smime.p7s has been removed from this note on October 01 2001 by John McMeeking --0__=86256AD80068F61D8f9e8a93df938690918c86256AD80068F61D Content-type: application/octet-stream; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII9jCCApQw ggH9oAMCAQICAwSkbzANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDQxOTE5MjY0NFoXDTAyMDQxOTE5MjY0NFowTzEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEsMCoGCSqGSIb3DQEJARYdam9obi5zdHJhc3NuZXJAaW50ZWxsaWRl bi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKOQF9xvr2IzkspSZ5NHATzu64yNJl1D NVVu08Upy0q/Dvfm0/dWVRc/sg09Tr1seHcVLIjAlY6QWFJsPf5tuglzSuMPy+6bGj/mI3KSXpte dhD5o33qc0oBnIOyn+PuqW7fpWjIJwM2MNCLr7gG1IjrchggMput4b5jq2M3zXxJAgMBAAGjOjA4 MCgGA1UdEQQhMB+BHWpvaG4uc3RyYXNzbmVyQGludGVsbGlkZW4uY29tMAwGA1UdEwEB/wQCMAAw DQYJKoZIhvcNAQEEBQADgYEAtHVVEjLYbfAxqW9D1GxSpZYh7kWX/em+JcgXrxFom6kU3wgCrluP F0Ce97vS4VX/TTs9x9b9YUONsEi8kqN5XLY3995FwnFgT+s2ZVljKNFoCgk4COQJ3OS2l/bZWFRc xgR4auC8sLZmE2oxtOm1cigZMhbT8ZnKvWuBN/8q2tUwggMpMIICkqADAgECAgEMMA0GCSqGSIb3 DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD YXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0 aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMw MDAwMDAwWhcNMDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMw MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpj NSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL2 17CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIB ADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kN aiYqYoQfuIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvB UFe17BzX7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gwggMtMIIClqAD AgECAgEAMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wHhcNOTYwMTAxMDAwMDAwWhcNMjAxMjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRk W3HpR9gMUbbqcpGwhF59LQ2PexLfhSV1KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP 6E0PcR9AOKYAo4d49vmUhl6t6sBeduvZFKNdbnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9 edvlWsQcuQIDAQABoxMwETAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O +PWWpWdiKqTwTRFg0G+NYFhhrCa7UjVcCM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyi rNx54+duAEcftQ0o6AKd5Jr9E/Sm2Xyx+NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1R hGvk+NHOd6KBMYICqjCCAqYCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0 aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDBKRvMAkGBSsOAwIaBQCgggFlMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTAxMDkyOTIwNDExMlowIwYJKoZIhvcNAQkEMRYEFHhilkYfV27YkSLJk8b0FFo7YSkg MFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIx CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBKRvMA0GCSqGSIb3DQEBAQUABIGAoGCy g3Xutd560fp+CgO2BHHjyPjLrG/p7T/mAeKoOV81cXw3BVGrd22dGx7B3XSmAqipYDm2rTK8wTlW fWiAgOQSpJQF3oBSJMpZS2VSc5ibpjl+kM/pbogSPdNZDZFbXUKNFnKep9LmkvnMnARy71PmHnD6 Ma/k9qS66IrLh3oAAAAAAAAA --0__=86256AD80068F61D8f9e8a93df938690918c86256AD80068F61D-- From owner-ietf-ldup@mail.imc.org Wed Oct 3 04:21:01 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02877 for ; Wed, 3 Oct 2001 04:21:00 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9382QD02997 for ietf-ldup-bks; Wed, 3 Oct 2001 01:02:26 -0700 (PDT) Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9382ND02989 for ; Wed, 3 Oct 2001 01:02:23 -0700 (PDT) Received: (qmail 12431 invoked from network); 3 Oct 2001 08:12:46 -0000 Received: from osmium.adacel.com.au (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 3 Oct 2001 08:12:46 -0000 Reply-To: From: "Steven Legg" To: Cc: "'John McMeeking'" , Subject: RE: Operations crossing replication contexts Date: Wed, 3 Oct 2001 19:03:25 +1100 Message-ID: <003501c14be1$e289efe0$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 In-Reply-To: Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John, John Strassner wrote: > Hmmm, just when I was about to call to see if all of the comments were > finished on URP, up pops this message. So I have a quick > question to John, > Steven, and others that are interested in this thread: is it > your aim to > resolve this question as part of the URP Last Call, or is > this something > that you think affects other documents than URP? The question of immediate relevance to the last call on URP is whether there is a single Lost & Found per server, or per replication context. However there is a more general problem that the current LDUP documents don't adequately address partial replication. I regard two or more replication contexts held in the same server as an example of partial replication since moving an entry between replication contexts is essentially the same problem as a modification altering whether an entry appears in a sparse replica. We don't have a documented solution in either case. If the current LDUP specification can only be effectively implemented for servers holding one replication context and participating in no partial replication agreements then the question of whether there is one L&F per server or one L&F per replication context is rather academic since the total is one in both cases. The choice before us is to either: (1) Issue a first round of LDUP RFCs that address the particular case of only one replication context per server and no partial replication agreements. We can issue a second round of RFCs that updates the first set once we have a general solution for partial replication. Apart from the amendments discussed during the last call period, URP is ready for such a first round. OR (2) Not issue any RFCs until we have a solution for partial replication. It is likely that a general solution for partial replication will have some impact on URP. I don't envision any changes to the existing procedures for processing replication primitives, but there might need to be some extra primitives, and the procedures for applying user updates will have to address changes that span multiple areas of replication. Recently I've been thinking seriously again about LDUP partial replication. In order to give an indication of the sort of impact partial replication will make, here is a summary of some changes that would need to be made to the LDUP architecture to apply the most promising ideas I've been kicking around. (i) Hierarchically identified replication areas (RAs). RAs form subset/superset relationships. Servers enter into agreements to replicate specific identified RAs. The RA has to exist before the replication agreement is created. (ii) An update vector per RA instead of per server. This gets around severe restrictions on topology imposed by the Update Vector and facilitates expedited changes. (iii) Tagging replication primitives with the identifier of the RA where the original client update was performed and restricting the flow of replication primitives from servers holding subset RAs to servers holding superset RAs. (iv) Tagging each entry with the RAs it currently appears in (it could be an operational attribute). Entries moving in and out of scope of an RA are explicitly indicated by modifying the tags. This is where extra replication primitives might come in. At the moment I not sure if a have a foolproof way for a server holding a subset RA to get all the relevant content for an entry that has just moved into the scope of the subset RA. Glue entries in sparse replicas also complicate the picture. I'm looking at both a "push" model where the server holding the superset RA sends the entry contents it *thinks* the server holding the subset RA *might* need, and a "pull" model where the server holding the subset RA asks the server holding the superset RA for the information it believes is missing. Either method implies extensions to the replication protocol. When I think I have a workable solution I'll write up the details and post to the list. Regards, Steven From owner-ietf-ldup@mail.imc.org Wed Oct 3 09:23:05 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13183 for ; Wed, 3 Oct 2001 09:23:05 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f93D4oS26095 for ietf-ldup-bks; Wed, 3 Oct 2001 06:04:50 -0700 (PDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f93D4nD26087 for ; Wed, 3 Oct 2001 06:04:49 -0700 (PDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA160044 for ; Wed, 3 Oct 2001 09:02:18 -0400 Received: from d01mlc96.pok.ibm.com (d01mlc96.pok.ibm.com [9.117.250.33]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f93D3Ns252232 for ; Wed, 3 Oct 2001 09:03:23 -0400 To: ietf-ldup@imc.org Subject: RE: Operations crossing replication contexts X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 From: "Timothy Hahn" Message-ID: Date: Wed, 3 Oct 2001 09:03:21 -0400 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Build V509_09182001.dev00 |September 20, 2001) at 10/03/2001 09:03:25 AM, Serialize complete at 10/03/2001 09:03:25 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00471D9685256ADA_=" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00471D9685256ADA_= Content-Type: text/plain; charset="us-ascii" Steven, I really feel that LDUP should address the issues involved in a single server handling multiple replication contexts. If we don't I think we would be miss the mark by providing a replication model that would not meet the needs of LDAP directory deployments. I agree that providing this implies changes to all the replication drafts - with exception, perhaps, of the requirements. And since this probably has implications on the LDUP update protocol as well as the information model, it seems to me we should take the time to build it right now rather than have to build a whole new "version" to support mulitple replication contexts in a single server. Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) phone: 607.752.6388 tie-line: 8/852.6388 fax: 607.752.3681 "Steven Legg" Sent by: owner-ietf-ldup@mail.imc.org 10/03/2001 04:03 AM Please respond to steven.legg To: cc: John McMeeking/Rochester/IBM@IBMUS, Subject: RE: Operations crossing replication contexts John, John Strassner wrote: > Hmmm, just when I was about to call to see if all of the comments were > finished on URP, up pops this message. So I have a quick > question to John, > Steven, and others that are interested in this thread: is it > your aim to > resolve this question as part of the URP Last Call, or is > this something > that you think affects other documents than URP? The question of immediate relevance to the last call on URP is whether there is a single Lost & Found per server, or per replication context. However there is a more general problem that the current LDUP documents don't adequately address partial replication. I regard two or more replication contexts held in the same server as an example of partial replication since moving an entry between replication contexts is essentially the same problem as a modification altering whether an entry appears in a sparse replica. We don't have a documented solution in either case. If the current LDUP specification can only be effectively implemented for servers holding one replication context and participating in no partial replication agreements then the question of whether there is one L&F per server or one L&F per replication context is rather academic since the total is one in both cases. The choice before us is to either: (1) Issue a first round of LDUP RFCs that address the particular case of only one replication context per server and no partial replication agreements. We can issue a second round of RFCs that updates the first set once we have a general solution for partial replication. Apart from the amendments discussed during the last call period, URP is ready for such a first round. OR (2) Not issue any RFCs until we have a solution for partial replication. It is likely that a general solution for partial replication will have some impact on URP. I don't envision any changes to the existing procedures for processing replication primitives, but there might need to be some extra primitives, and the procedures for applying user updates will have to address changes that span multiple areas of replication. Recently I've been thinking seriously again about LDUP partial replication. In order to give an indication of the sort of impact partial replication will make, here is a summary of some changes that would need to be made to the LDUP architecture to apply the most promising ideas I've been kicking around. (i) Hierarchically identified replication areas (RAs). RAs form subset/superset relationships. Servers enter into agreements to replicate specific identified RAs. The RA has to exist before the replication agreement is created. (ii) An update vector per RA instead of per server. This gets around severe restrictions on topology imposed by the Update Vector and facilitates expedited changes. (iii) Tagging replication primitives with the identifier of the RA where the original client update was performed and restricting the flow of replication primitives from servers holding subset RAs to servers holding superset RAs. (iv) Tagging each entry with the RAs it currently appears in (it could be an operational attribute). Entries moving in and out of scope of an RA are explicitly indicated by modifying the tags. This is where extra replication primitives might come in. At the moment I not sure if a have a foolproof way for a server holding a subset RA to get all the relevant content for an entry that has just moved into the scope of the subset RA. Glue entries in sparse replicas also complicate the picture. I'm looking at both a "push" model where the server holding the superset RA sends the entry contents it *thinks* the server holding the subset RA *might* need, and a "pull" model where the server holding the subset RA asks the server holding the superset RA for the information it believes is missing. Either method implies extensions to the replication protocol. When I think I have a workable solution I'll write up the details and post to the list. Regards, Steven --=_alternative 00471D9685256ADA_= Content-Type: text/html; charset="us-ascii"
Steven,

I really feel that LDUP should address the issues involved in a single server handling multiple replication contexts.  If we don't I think we would be miss the mark by providing a replication model that would not meet the needs of LDAP directory deployments.

I agree that providing this implies changes to all the replication drafts - with exception, perhaps, of the requirements.  And since this probably has implications on the LDUP update protocol as well as the information model, it seems to me we should take the time to build it right now rather than have to build a whole new "version" to support mulitple replication contexts in a single server.
Regards,
Tim Hahn

Internet: hahnt@us.ibm.com
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681


"Steven Legg" <steven.legg@adacel.com.au>
Sent by: owner-ietf-ldup@mail.imc.org

10/03/2001 04:03 AM
Please respond to steven.legg

       
        To:        <john.strassner@intelliden.com>
        cc:        John McMeeking/Rochester/IBM@IBMUS, <ietf-ldup@imc.org>
        Subject:        RE: Operations crossing replication contexts

       




John,

John Strassner wrote:
> Hmmm, just when I was about to call to see if all of the comments were
> finished on URP, up pops this message. So I have a quick
> question to John,
> Steven, and others that are interested in this thread: is it
> your aim to
> resolve this question as part of the URP Last Call, or is
> this something
> that you think affects other documents than URP?

The question of immediate relevance to the last call on URP is whether
there is a single Lost & Found per server, or per replication context.
However there is a more general problem that the current LDUP documents
don't adequately address partial replication. I regard two or more
replication contexts held in the same server as an example of partial
replication since moving an entry between replication contexts is
essentially the same problem as a modification altering whether an entry
appears in a sparse replica. We don't have a documented solution in
either case.

If the current LDUP specification can only be effectively implemented
for servers holding one replication context and participating in no
partial replication agreements then the question of whether there is
one L&F per server or one L&F per replication context is rather academic
since the total is one in both cases.

The choice before us is to either:

(1) Issue a first round of LDUP RFCs that address the particular case
of only one replication context per server and no partial replication
agreements. We can issue a second round of RFCs that updates the first
set once we have a general solution for partial replication. Apart
from the amendments discussed during the last call period, URP is ready
for such a first round.

OR

(2) Not issue any RFCs until we have a solution for partial replication.

It is likely that a general solution for partial replication will have
some impact on URP. I don't envision any changes to the existing
procedures for processing replication primitives, but there might need
to be some extra primitives, and the procedures for applying user updates
will have to address changes that span multiple areas of replication.


Recently I've been thinking seriously again about LDUP partial replication.
In order to give an indication of the sort of impact partial replication
will make, here is a summary of some changes that would need to be made
to the LDUP architecture to apply the most promising ideas I've been
kicking around.

(i) Hierarchically identified replication areas (RAs). RAs form
subset/superset relationships. Servers enter into agreements to
replicate specific identified RAs. The RA has to exist before the
replication agreement is created.

(ii) An update vector per RA instead of per server. This gets around
severe restrictions on topology imposed by the Update Vector and
facilitates expedited changes.

(iii) Tagging replication primitives with the identifier of the RA
where the original client update was performed and restricting the
flow of replication primitives from servers holding subset RAs to
servers holding superset RAs.

(iv) Tagging each entry with the RAs it currently appears in
(it could be an operational attribute). Entries moving in and
out of scope of an RA are explicitly indicated by modifying the
tags. This is where extra replication primitives might come in.

At the moment I not sure if a have a foolproof way for a server
holding a subset RA to get all the relevant content for an entry
that has just moved into the scope of the subset RA. Glue entries
in sparse replicas also complicate the picture. I'm looking at
both a "push" model where the server holding the superset RA sends
the entry contents it *thinks* the server holding the subset RA
*might* need, and a "pull" model where the server holding the
subset RA asks the server holding the superset RA for the information
it believes is missing. Either method implies extensions to the
replication protocol.

When I think I have a workable solution I'll write up the details
and post to the list.

Regards,
Steven

--=_alternative 00471D9685256ADA_=-- From owner-ietf-ldup@mail.imc.org Wed Oct 3 09:31:19 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13531 for ; Wed, 3 Oct 2001 09:31:18 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id f93DE3D27816 for ietf-ldup-bks; Wed, 3 Oct 2001 06:14:03 -0700 (PDT) Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f93DE2D27809 for ; Wed, 3 Oct 2001 06:14:02 -0700 (PDT) Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id f93DDsA24212 for ; Wed, 3 Oct 2001 06:13:54 -0700 (PDT) Received: from netscape.com ([207.1.144.47]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GKMSR700.LYW; Wed, 3 Oct 2001 06:13:55 -0700 Message-ID: <3BBB0F15.8B18D724@netscape.com> Date: Wed, 03 Oct 2001 09:13:58 -0400 From: Mark Smith Organization: Netscape Communications X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en-US,en MIME-Version: 1.0 To: Timothy Hahn CC: ietf-ldup@imc.org Subject: Re: Operations crossing replication contexts References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Timothy Hahn wrote: > > Steven, > > I really feel that LDUP should address the issues involved in a single > server handling multiple replication contexts. If we don't I think we > would be miss the mark by providing a replication model that would not > meet the needs of LDAP directory deployments. > > I agree that providing this implies changes to all the replication > drafts - with exception, perhaps, of the requirements. And since this > probably has implications on the LDUP update protocol as well as the > information model, it seems to me we should take the time to build it > right now rather than have to build a whole new "version" to support > mulitple replication contexts in a single server. I strongly agree. A directory server that supports only one replication context, presumably for one contiguous subtree for the DIT, will not be usable in many situations. -- Mark Smith Netscape From owner-ietf-ldup@mail.imc.org Thu Oct 4 09:41:27 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12293 for ; Thu, 4 Oct 2001 09:41:26 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f94D56015340 for ietf-ldup-bks; Thu, 4 Oct 2001 06:05:06 -0700 (PDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f94D55D15331 for ; Thu, 4 Oct 2001 06:05:05 -0700 (PDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f94D5Wf05710 for ; Thu, 4 Oct 2001 16:05:32 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 4 Oct 2001 16:05:00 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Thu, 4 Oct 2001 16:04:59 +0300 Message-ID: <80E79E0EE6BCD3468E7A01C9E5BAD2200BE2BA@esebe003.NOE.Nokia.com> From: jukka.aakula@nokia.com To: richm@netscape.com Cc: ietf-ldup@imc.org Subject: Still one comment on the LCUP scalability Date: Thu, 4 Oct 2001 16:04:54 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I found the text in the LCUP draft: Implementors of servers that support the mechanism described in this document should ensure that their implementation scales well as the number of active persistent operations and the number of changes made in the directory increases. Server implementors are also encouraged to support a large number of client connections if they need to support large numbers of persistent operations. So I assume this means that one client can do a lot of persistent searches as well. Jukka > -----Original Message----- > From: ext Rich Megginson [mailto:richm@netscape.com] > Sent: 24. September 2001 17:20 > To: Aakula Jukka (NET/Espoo) > Cc: ietf-ldup@imc.org > Subject: Re: Question on LCUP > > > JUKA AAKULA wrote: > > > Thank you for the answer, Rich > > > > Still a question below: > > > > >> But suppose the client keeps a more dynamic cache in the sense > > >> that when the client "gets interested" in a certain entry, > > >> the client allways makes a Persistent Search ? > > > > > >Do you mean the client makes an additional Persistent > Search? I don't > > think that would be necessary. If the client somehow > > >becomes interested in an entry outside the scope of the > current LCUP > > request, the client could simply close the connection > > >and issue another LCUP request with a wider scope. > > > > Take an example: there are one million subscribers in a telephone > > catalogue. Each subscriber entry is immediately > > below the root entry. > > > > A client maintains a cache with a subset of the subscriber > entries using > > persistent search. Each time a new subscriber is added in > the subset the > > subscriber entry is searched for in the telephone catalogue using > > persistent search. (The subset is say > > members of some club.) > > > > Is such use of LCUP fully infeasible ? > > No. In the LCUP model, you would do an LCUP (persistent) > search with (for example) a base of o=root and a search filter of > cn=some club. When a new entry is added, only that new entry > is sent back via the persistent search. If for some reason the > client was disconnected, the client issues an LCUP search the > next time it is connected and gets back only the entries which were > added or modified since the last LCUP search. > > > Or should the client make a persistent search for all the > entries in the > > catalogue but skipping those > > it's not interested in ? > > I'm not sure that's necessary, since LCUP should only give > you back the entries you are interested in. > > > > > > > Jukka > From owner-ietf-ldup@mail.imc.org Thu Oct 4 10:39:20 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14598 for ; Thu, 4 Oct 2001 10:39:20 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f94EJVD19386 for ietf-ldup-bks; Thu, 4 Oct 2001 07:19:31 -0700 (PDT) Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f94EJTD19381 for ; Thu, 4 Oct 2001 07:19:29 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id f94EJOT28652 for ; Thu, 4 Oct 2001 07:19:24 -0700 (PDT) Received: from netscape.com ([205.217.229.42]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GKOQGD00.C4T; Thu, 4 Oct 2001 07:19:25 -0700 Message-ID: <3BBC6F23.C5F1670A@netscape.com> Date: Thu, 04 Oct 2001 08:16:03 -0600 From: richm@netscape.com (Rich Megginson) Organization: Netscape - Enterprise Products X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: jukka.aakula@nokia.com CC: ietf-ldup@imc.org Subject: Re: Still one comment on the LCUP scalability References: <80E79E0EE6BCD3468E7A01C9E5BAD2200BE2BA@esebe003.NOE.Nokia.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms75A6DCF79FFDC9AD1405D7A5" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms75A6DCF79FFDC9AD1405D7A5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit jukka.aakula@nokia.com wrote: > I found the text in the LCUP draft: > > Implementors of servers that support the mechanism described in this > document should ensure that their implementation scales well as the > number of active persistent operations and the number of changes > made in the directory increases. Server implementors are also > encouraged to support a large number of client connections if they > need to support large numbers of persistent operations. > > So I assume this means that one client can do a lot of persistent searches > as well. I think if a server is designed to support a large number of persistent searches and a large number of client connections, that should not exclude the possibility that a single client may have a large number of persistent searches and open connections. In fact, this may happen. Let's assume you have a server with several naming contexts. Each naming context is in a separate LCUP context. This means that you must do several different searches. Let's say you have a client maintaining a cache. That client may have to issue multiple concurrent LCUP persistent searches for each naming context. You could design the data layout of your server such that all LCUP contexts are contained within a single naming context, so that a single LCUP search with a single base could receive update notifications for all suffixes e.g. o=LCUP Contexts o=foo org ou=People ou=Groups o=bar org ou=People ou=Groups Then, you could issue a search with a base of o=LCUP Contexts and a search filter of (objectclass=mySubscriber). Then, any time a new subscriber is added to o=foo org or o=bar org, the LCUP search will provide notification. > > > Jukka > > > -----Original Message----- > > From: ext Rich Megginson [mailto:richm@netscape.com] > > Sent: 24. September 2001 17:20 > > To: Aakula Jukka (NET/Espoo) > > Cc: ietf-ldup@imc.org > > Subject: Re: Question on LCUP > > > > > > JUKA AAKULA wrote: > > > > > Thank you for the answer, Rich > > > > > > Still a question below: > > > > > > >> But suppose the client keeps a more dynamic cache in the sense > > > >> that when the client "gets interested" in a certain entry, > > > >> the client allways makes a Persistent Search ? > > > > > > > >Do you mean the client makes an additional Persistent > > Search? I don't > > > think that would be necessary. If the client somehow > > > >becomes interested in an entry outside the scope of the > > current LCUP > > > request, the client could simply close the connection > > > >and issue another LCUP request with a wider scope. > > > > > > Take an example: there are one million subscribers in a telephone > > > catalogue. Each subscriber entry is immediately > > > below the root entry. > > > > > > A client maintains a cache with a subset of the subscriber > > entries using > > > persistent search. Each time a new subscriber is added in > > the subset the > > > subscriber entry is searched for in the telephone catalogue using > > > persistent search. (The subset is say > > > members of some club.) > > > > > > Is such use of LCUP fully infeasible ? > > > > No. In the LCUP model, you would do an LCUP (persistent) > > search with (for example) a base of o=root and a search filter of > > cn=some club. When a new entry is added, only that new entry > > is sent back via the persistent search. If for some reason the > > client was disconnected, the client issues an LCUP search the > > next time it is connected and gets back only the entries which were > > added or modified since the last LCUP search. > > > > > Or should the client make a persistent search for all the > > entries in the > > > catalogue but skipping those > > > it's not interested in ? > > > > I'm not sure that's necessary, since LCUP should only give > > you back the entries you are interested in. > > > > > > > > > > > Jukka > > --------------ms75A6DCF79FFDC9AD1405D7A5 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIJFwYJKoZIhvcNAQcCoIIJCDCCCQQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BuowggMMMIICdaADAgECAgI4bjANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMTA2MDQxMzIzNTlaFw0wMTEyMDExMzIzNTla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxITAf BgkqhkiG9w0BCQEWEnJpY2htQG5ldHNjYXBlLmNvbTEXMBUGA1UEAxMOUmljaCBNZWdnaW5z b24xFTATBgoJkiaJk/IsZAEBEwVyaWNobTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA vzzOOuvTS4h7GhcAGzqVeimRSAAhcKDPG9I3nBzbjyhahyg1l+9jL3aWxzjZTeUc3mAvWuoK 3NsNsI6N4MV9kH2NDUEEw3GsSweDEU6MFBwPA2YCxa8Ct0NkR+VRWG/YfUalO/OqROKZ5KBY tiJCR31RQ5Iiwxe4ZgPVfrYoVzUCAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIF4DA2BggrBgEFBQcBAQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3Au bmV0c2NhcGUuY29tMB8GA1UdIwQYMBaAFCnbsi2Dfn+LI7vCzGa5Oegp8wKGMA0GCSqGSIb3 DQEBBAUAA4GBAMkxCPa1hNJmPODo+PvjDyGxRdXIKlgcbWMDuoBVZ7OulY006Jg02nnvwNnq q8wLIciyyjVP1rTpHsBApNCGxkRa5Oc5sCetbnyP5ZIOBCaOe0Bh/IWDDTHl3y9HTWmNxX8b OPkzNkWGigfW45m2Xr3lTjnUhXdFgt4QU57EbizQMIID1jCCAz+gAwIBAgIEAgAB5jANBgkq hkiG9w0BAQUFADBFMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPR1RFIENvcnBvcmF0aW9uMRww GgYDVQQDExNHVEUgQ3liZXJUcnVzdCBSb290MB4XDTAxMDYwMTEyNDcwMFoXDTA0MDYwMTIz NTkwMFowgZMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4g VmlldzEbMBkGA1UEChMSQW1lcmljYSBPbmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5v bG9naWVzMScwJQYDVQQDEx5JbnRyYW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAOLvXyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4s SSYg/wAX5IiIad79g1fgoxEZEarW3Lzvs9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYH XPCzeauaEKW8waTReEwG5WRB/AUlYybr7wzHblShjM5UV7YfktqyEkuNAgMBAAGjggGCMIIB fjBNBgNVHR8ERjBEMEKgQKA+hjxodHRwOi8vd3d3MS51cy1ob3N0aW5nLmJhbHRpbW9yZS5j b20vY2dpLWJpbi9DUkwvR1RFUm9vdC5jZ2kwHQYDVR0OBBYEFCnbsi2Dfn+LI7vCzGa5Oegp 8wKGMGYGA1UdIARfMF0wRgYKKoZIhvhjAQIBBTA4MDYGCCsGAQUFBwIBFipodHRwOi8vd3d3 LmJhbHRpbW9yZS5jb20vQ1BTL09tbmlSb290Lmh0bWwwEwYDKgMEMAwwCgYIKwYBBQUHAgEw WAYDVR0jBFEwT6FJpEcwRTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0dURSBDb3Jwb3JhdGlv bjEcMBoGA1UEAxMTR1RFIEN5YmVyVHJ1c3QgUm9vdIICAaMwKwYDVR0QBCQwIoAPMjAwMTA2 MDExMjQ3MzBagQ8yMDAzMDkwMTIzNTkwMFowDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwQIMAYB Af8CAQEwDQYJKoZIhvcNAQEFBQADgYEASmIO2fpGdwQKbA3d/tIiOZkQCq6ILYY9V4TmEiQ3 aftZXuIRsPmfpFeGimkfBmPRfe4zNkkQIA8flxcsJ2w9bDkEe+JF6IcbVLZgQW0drgXznfk6 NJrje2tMcfjrqCuDsDWQTBloce3wYyJewlvsIHq1sFFz6QfugWd2eVP3ldQxggH1MIIB8QIB ATCBmjCBkzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBW aWV3MRswGQYDVQQKExJBbWVyaWNhIE9ubGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9s b2dpZXMxJzAlBgNVBAMTHkludHJhbmV0IENlcnRpZmljYXRlIEF1dGhvcml0eQICOG4wCQYF Kw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w MTEwMDQxNDE2MDNaMCMGCSqGSIb3DQEJBDEWBBRNfZXysTsqRKQoXrcZBNKzxWWn/zBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggq hkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASBgAGxrjkSIW3mr1Bm H8wOOgND5x0RRbCVODJTOFKIgQnbhhXfTOST/aj+1mI33IseGR0+ur7IdYvEVoUo1Y+BEmfG bYuZZqzIUNSVEioWkXUckFqyJ2o8Lv2MzE0i2H8z4HIIpFNkQdNTldU4cR+C/1gozyUTI2oy sbVEHugSC+Gx --------------ms75A6DCF79FFDC9AD1405D7A5-- From owner-ietf-ldup@mail.imc.org Fri Oct 5 11:47:51 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24574 for ; Fri, 5 Oct 2001 11:47:51 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f95FPVL27287 for ietf-ldup-bks; Fri, 5 Oct 2001 08:25:31 -0700 (PDT) Received: from va2mc.ummailbox.net (va2mc.ummailbox.net [64.210.247.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f95FPUD27283 for ; Fri, 5 Oct 2001 08:25:30 -0700 (PDT) Received: from ex04.ummail.com (ex04.ummail.com [64.210.247.105:25]) by va2mc.ummailbox.net with ESMTP id M1005-1125-228500; Fri, 5 Oct 2001 15:25:16 GMT Received: by ex04.ummail.com with Internet Mail Service (5.5.2650.21) id ; Fri, 5 Oct 2001 11:23:56 -0400 Message-ID: <504D6456F0C87F4C8B11FB0C2021D6F602DACED7@ex04.ummail.com> From: Christopher Apple To: "'Mark Smith'" , Timothy Hahn Cc: ietf-ldup@imc.org Subject: RE: Operations crossing replication contexts Date: Fri, 5 Oct 2001 11:23:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0006_01C14D90.0EC67100"; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C14D90.0EC67100 Content-Type: multipart/mixed; boundary="----=_NextPart_001_0007_01C14D90.0ECC8B80" ------=_NextPart_001_0007_01C14D90.0ECC8B80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Strongly agree also. I can't see any real benefit to the folks who actually have to use LDUP implementations to have to cope with two ways of handling LDAPv3 replication depending on how many contexts per server they need. Steven: when could you have a revised I-D posted to the list plus some bullets indicating changes implied for other documents? Chris Apple Program Manager - Integration Services United Messaging Inc. (V) +1 610 425 2860 -----Original Message----- From: Mark Smith [mailto:mcs@netscape.com] Sent: Wednesday, October 03, 2001 9:14 AM To: Timothy Hahn Cc: ietf-ldup@imc.org Subject: Re: Operations crossing replication contexts Timothy Hahn wrote: > > Steven, > > I really feel that LDUP should address the issues involved in a single > server handling multiple replication contexts. If we don't I think we > would be miss the mark by providing a replication model that would not > meet the needs of LDAP directory deployments. > > I agree that providing this implies changes to all the replication > drafts - with exception, perhaps, of the requirements. And since this > probably has implications on the LDUP update protocol as well as the > information model, it seems to me we should take the time to build it > right now rather than have to build a whole new "version" to support > mulitple replication contexts in a single server. I strongly agree. A directory server that supports only one replication context, presumably for one contiguous subtree for the DIT, will not be usable in many situations. -- Mark Smith Netscape ------=_NextPart_001_0007_01C14D90.0ECC8B80 Content-Type: text/x-vcard; name="Christopher Apple (E-mail).vcf" Content-Disposition: attachment; filename="Christopher Apple (E-mail).vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Apple;Christopher FN:Christopher Apple (E-mail) ORG:UMI TITLE:Program Manager TEL;WORK;VOICE:(610) 425-2860 TEL;HOME;VOICE:(215) 873-0850 TEL;CELL;VOICE:(610) 585-4241 TEL;WORK;FAX:(610) 425-6501 ADR;WORK:;;1161 McDermott Drive;West Chester;Pa.;19380;United States of = America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:1161 McDermott = Drive=3D0D=3D0AWest Chester, Pa. 19380=3D0D=3D0AUnited States of Amer=3D ica EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com REV:20010925T181636Z END:VCARD ------=_NextPart_001_0007_01C14D90.0ECC8B80-- ------=_NextPart_000_0006_01C14D90.0EC67100 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF5DCCAqQw ggINoAMCAQICAwXEtzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMTAwMTIwMzQ0NFoXDTAyMTAwMTIwMzQ0NFowVzEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjE0MDIGCSqGSIb3DQEJARYlY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVk bWVzc2FnaW5nLm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAskTzIWwgiwgpN1uw6lPW 18QSwRHJrA1gsUDc/BvJsjlfGmlsfKKWz1vyLR4FHrVOLY9J82K1aTOrq6ce/aQfoQ1hKGH3tDPo AqetRW/nSpM2Jp50I3BImiFUr4ddB8WdNpYQgddQNCmvRAchnS+rwzsLUccV9LuukmfWf1EhvaUC AwEAAaNCMEAwMAYDVR0RBCkwJ4ElY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVkbWVzc2FnaW5nLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBAgUAA4GBAB2VoUyzMe1HFbQvgw5Z+UvKcG68eDAZ bE2fkCMQDvnaIeqQiMcKGx1AN6F6+JMgoKuoT60B2052mU0K/LoR5OYIIM9J3KlqYjgUNZtRu89U bz9GgtSzDWMSQm+lNOBNFV7BddVrhKBHCglHiAiYUmzO7bi/YOi96yz2R4RdX6AhMIIDODCCAqGg AwIBAgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgyNzIzNTk1OVowgZIx CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/+TRxoKNtmPHD T6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoT h/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZh dGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEB BAUAA4GBADGxS0dd+QFx5fVTbF151j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3 UFWobPcNrUwbvAP0teuiR59sogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o8 9kTqJmmHf0iezqWf54TYyWJirQXGMYICyDCCAsQCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYD VQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0w GwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMAIDBcS3MAkGBSsOAwIaBQCgggGDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAxMTAwNTE1MjI0NlowIwYJKoZIhvcNAQkEMRYEFEupqmOF6x9h Xfpd6nbpveewH7xXMHYGCSqGSIb3DQEJDzFpMGcwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MAcGBSsOAwIHMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAcGBSsOAwIaMAoGCCqG SIb3DQIFMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h aWwgUlNBIDIwMDAuOC4zMAIDBcS3MA0GCSqGSIb3DQEBAQUABIGAJtmNv18R6/d5X0GuefckC5tj qs8mdf5vol3/9flNnnkIqq/qbALfwERWx7vf7G9s+EompOKKgajRadCkZfDxSemv+y+Dfh7OK4Hn Q2eR1N9KIs0gNVvoqLRzC7qOw4de87bSEnGF52HJDDf10zUfC+mTw2ysNSp3SNodP6+M73UAAAAA AAA= ------=_NextPart_000_0006_01C14D90.0EC67100-- From owner-ietf-ldup@mail.imc.org Mon Oct 8 01:12:06 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01067 for ; Mon, 8 Oct 2001 01:12:06 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f984kjU00655 for ietf-ldup-bks; Sun, 7 Oct 2001 21:46:45 -0700 (PDT) Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by above.proper.com (8.11.6/8.11.3) with SMTP id f984kgD00651 for ; Sun, 7 Oct 2001 21:46:43 -0700 (PDT) Received: (qmail 23355 invoked from network); 8 Oct 2001 04:57:50 -0000 Received: from osmium.adacel.com.au (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 8 Oct 2001 04:57:50 -0000 Reply-To: From: "Steven Legg" To: "'Christopher Apple'" Cc: Subject: RE: Operations crossing replication contexts Date: Mon, 8 Oct 2001 15:47:42 +1100 Message-ID: <000001c14fb4$5e6528c0$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal In-Reply-To: <504D6456F0C87F4C8B11FB0C2021D6F602DACED7@ex04.ummail.com> Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Chris, Christopher Apple wrote: > Strongly agree also. I can't see any real benefit to the folks > who actually have to use LDUP implementations to have to cope > with two ways of handling LDAPv3 replication depending on > how many contexts per server they need. > > Steven: when could you have a revised I-D posted to the list > plus some bullets indicating changes implied for other documents? I can submit a revised URP draft with the changes already agreed during the last call period within a week or so, but for the changes required to properly support partial replication, I think the best approach is for me to write up the architectural details of what I've been working on and post that to the list. I can do that in parts over the next month. Once everyone has had a chance to think about it we can decide what amendments need to be made to which documents, including further changes to URP. Regards, Steven > > Chris Apple > Program Manager - Integration Services > United Messaging Inc. > > > (V) +1 610 425 2860 > > > -----Original Message----- > From: Mark Smith [mailto:mcs@netscape.com] > Sent: Wednesday, October 03, 2001 9:14 AM > To: Timothy Hahn > Cc: ietf-ldup@imc.org > Subject: Re: Operations crossing replication contexts > > > > Timothy Hahn wrote: > > > > Steven, > > > > I really feel that LDUP should address the issues involved > in a single > > server handling multiple replication contexts. If we don't > I think we > > would be miss the mark by providing a replication model > that would not > > meet the needs of LDAP directory deployments. > > > > I agree that providing this implies changes to all the replication > > drafts - with exception, perhaps, of the requirements. And > since this > > probably has implications on the LDUP update protocol as well as the > > information model, it seems to me we should take the time > to build it > > right now rather than have to build a whole new "version" to support > > mulitple replication contexts in a single server. > > I strongly agree. A directory server that supports only one > replication > context, presumably for one contiguous subtree for the DIT, > will not be > usable in many situations. > > -- > Mark Smith > Netscape > From owner-ietf-ldup@mail.imc.org Tue Oct 9 15:22:17 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12019 for ; Tue, 9 Oct 2001 15:22:16 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f99IlDB02911 for ietf-ldup-bks; Tue, 9 Oct 2001 11:47:13 -0700 (PDT) Received: from va2mc.ummailbox.net (va2mc.ummailbox.net [64.210.247.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f99Il9D02907 for ; Tue, 9 Oct 2001 11:47:09 -0700 (PDT) Received: from ex04.ummail.com (ex04.ummail.com [64.210.247.105:25]) by va2mc.ummailbox.net with ESMTP id H1009-1446-723600; Tue, 9 Oct 2001 18:46:55 GMT Received: by ex04.ummail.com with Internet Mail Service (5.5.2650.21) id ; Tue, 9 Oct 2001 14:45:21 -0400 Message-ID: <504D6456F0C87F4C8B11FB0C2021D6F602DACEE0@ex04.ummail.com> From: Christopher Apple To: "'steven.legg@adacel.com.au'" , Christopher Apple Cc: ietf-ldup@imc.org Subject: RE: Operations crossing replication contexts Date: Tue, 9 Oct 2001 14:45:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0009_01C150D0.D8D2FC50"; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C150D0.D8D2FC50 Content-Type: multipart/mixed; boundary="----=_NextPart_001_000A_01C150D0.D8D2FC50" ------=_NextPart_001_000A_01C150D0.D8D2FC50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sounds good. Please revise and publish the URP spec based on all comments but those relevant to this thread and we'll consider this WG Last Call of URP over officially - it was a while ago actually, but discussions kept going several days past the actual deadline... However, until we know specifically what the impact could be on the URP document, I don't plan to recommend that the Apps ADs review it for IESG consideration until after the subsequent postings relevant to this thread. And then, we may have to do another revision of the URP document with a subsequent WG Last Call based on any changes that the WG feels need be made to it. If after discussing the additional postings that you plan to make the WG indicates that no additional changes need to be made to URP, John and I could make a recommendation to the Apps ADs at that time to review the document without further changes or another WG Last Call. Chris Apple Program Manager - Integration Services United Messaging Inc. (V) +1 610 425 2860 -----Original Message----- From: Steven Legg [mailto:steven.legg@adacel.com.au] Sent: Monday, October 08, 2001 12:48 AM To: 'Christopher Apple' Cc: ietf-ldup@imc.org Subject: RE: Operations crossing replication contexts Chris, Christopher Apple wrote: > Strongly agree also. I can't see any real benefit to the folks > who actually have to use LDUP implementations to have to cope > with two ways of handling LDAPv3 replication depending on > how many contexts per server they need. > > Steven: when could you have a revised I-D posted to the list > plus some bullets indicating changes implied for other documents? I can submit a revised URP draft with the changes already agreed during the last call period within a week or so, but for the changes required to properly support partial replication, I think the best approach is for me to write up the architectural details of what I've been working on and post that to the list. I can do that in parts over the next month. Once everyone has had a chance to think about it we can decide what amendments need to be made to which documents, including further changes to URP. Regards, Steven > > Chris Apple > Program Manager - Integration Services > United Messaging Inc. > > > (V) +1 610 425 2860 > > > -----Original Message----- > From: Mark Smith [mailto:mcs@netscape.com] > Sent: Wednesday, October 03, 2001 9:14 AM > To: Timothy Hahn > Cc: ietf-ldup@imc.org > Subject: Re: Operations crossing replication contexts > > > > Timothy Hahn wrote: > > > > Steven, > > > > I really feel that LDUP should address the issues involved > in a single > > server handling multiple replication contexts. If we don't > I think we > > would be miss the mark by providing a replication model > that would not > > meet the needs of LDAP directory deployments. > > > > I agree that providing this implies changes to all the replication > > drafts - with exception, perhaps, of the requirements. And > since this > > probably has implications on the LDUP update protocol as well as the > > information model, it seems to me we should take the time > to build it > > right now rather than have to build a whole new "version" to support > > mulitple replication contexts in a single server. > > I strongly agree. A directory server that supports only one > replication > context, presumably for one contiguous subtree for the DIT, > will not be > usable in many situations. > > -- > Mark Smith > Netscape > ------=_NextPart_001_000A_01C150D0.D8D2FC50 Content-Type: text/x-vcard; name="Christopher Apple (E-mail).vcf" Content-Disposition: attachment; filename="Christopher Apple (E-mail).vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Apple;Christopher FN:Christopher Apple (E-mail) ORG:UMI TITLE:Program Manager TEL;WORK;VOICE:(610) 425-2860 TEL;HOME;VOICE:(215) 873-0850 TEL;CELL;VOICE:(610) 585-4241 TEL;WORK;FAX:(610) 425-6501 ADR;WORK:;;1161 McDermott Drive;West Chester;Pa.;19380;United States of = America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:1161 McDermott = Drive=3D0D=3D0AWest Chester, Pa. 19380=3D0D=3D0AUnited States of Amer=3D ica EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com REV:20010925T181636Z END:VCARD ------=_NextPart_001_000A_01C150D0.D8D2FC50-- ------=_NextPart_000_0009_01C150D0.D8D2FC50 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF5DCCAqQw ggINoAMCAQICAwXEtzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMTAwMTIwMzQ0NFoXDTAyMTAwMTIwMzQ0NFowVzEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjE0MDIGCSqGSIb3DQEJARYlY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVk bWVzc2FnaW5nLm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAskTzIWwgiwgpN1uw6lPW 18QSwRHJrA1gsUDc/BvJsjlfGmlsfKKWz1vyLR4FHrVOLY9J82K1aTOrq6ce/aQfoQ1hKGH3tDPo AqetRW/nSpM2Jp50I3BImiFUr4ddB8WdNpYQgddQNCmvRAchnS+rwzsLUccV9LuukmfWf1EhvaUC AwEAAaNCMEAwMAYDVR0RBCkwJ4ElY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVkbWVzc2FnaW5nLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBAgUAA4GBAB2VoUyzMe1HFbQvgw5Z+UvKcG68eDAZ bE2fkCMQDvnaIeqQiMcKGx1AN6F6+JMgoKuoT60B2052mU0K/LoR5OYIIM9J3KlqYjgUNZtRu89U bz9GgtSzDWMSQm+lNOBNFV7BddVrhKBHCglHiAiYUmzO7bi/YOi96yz2R4RdX6AhMIIDODCCAqGg AwIBAgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgyNzIzNTk1OVowgZIx CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/+TRxoKNtmPHD T6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoT h/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZh dGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEB BAUAA4GBADGxS0dd+QFx5fVTbF151j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3 UFWobPcNrUwbvAP0teuiR59sogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o8 9kTqJmmHf0iezqWf54TYyWJirQXGMYICyDCCAsQCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYD VQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0w GwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMAIDBcS3MAkGBSsOAwIaBQCgggGDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAxMTAwOTE4NDQwNlowIwYJKoZIhvcNAQkEMRYEFGPt+EFS+o4c 91idI5bvatjdVzlEMHYGCSqGSIb3DQEJDzFpMGcwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MAcGBSsOAwIHMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAcGBSsOAwIaMAoGCCqG SIb3DQIFMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h aWwgUlNBIDIwMDAuOC4zMAIDBcS3MA0GCSqGSIb3DQEBAQUABIGAXzmesFqN+TFE+GBxolvVQH93 TdM/tzEIzptGhaiLJYn6VxfUtYnzHwfazQWfieXUBYgtq0zJr9tnrom6AHf/xlwmRI880XBQz2BF pH9v231OFRfVo6IpVy8JqYzjiljAzsk23Q2gSlFz0QbBrkZHh+6yksjUgf634b9geMTqwU0AAAAA AAA= ------=_NextPart_000_0009_01C150D0.D8D2FC50-- From owner-ietf-ldup@mail.imc.org Wed Oct 24 07:34:52 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21619 for ; Wed, 24 Oct 2001 07:34:51 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id f9OBAw003066 for ietf-ldup-bks; Wed, 24 Oct 2001 04:10:58 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9OBAu803059 for ; Wed, 24 Oct 2001 04:10:56 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20914; Wed, 24 Oct 2001 07:10:53 -0400 (EDT) Message-Id: <200110241110.HAA20914@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldup-urp-05.txt Date: Wed, 24 Oct 2001 07:10:53 -0400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF. Title : LDUP Update Reconciliation Procedures Author(s) : S. Legg, A. Payne Filename : draft-ietf-ldup-urp-05.txt Pages : 31 Date : 23-Oct-01 This document describes the procedures used by LDAP [LDAPv3] or X.500 [X500] directory servers to reconcile updates performed by autonomously operating directory servers in a distributed, replicated directory service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldup-urp-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldup-urp-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011023111733.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-urp-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-urp-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011023111733.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Tue Oct 30 09:24:06 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01205 for ; Tue, 30 Oct 2001 09:24:06 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9UE1oo15885 for ietf-ldup-bks; Tue, 30 Oct 2001 06:01:50 -0800 (PST) Received: from smtp.oncalldba.com (roc-24-169-98-153.rochester.rr.com [24.169.98.153]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9UE1X815874 for ; Tue, 30 Oct 2001 06:01:49 -0800 (PST) Received: from RMINC_DOM-MTA by smtp.oncalldba.com with Novell_GroupWise; Tue, 30 Oct 2001 08:57:17 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Tue, 30 Oct 2001 08:56:58 -0700 From: "Ed Reed" To: Cc: , , Subject: draft-zeilenga-ldap-subentry-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f9UE1n815882 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Kurt - Thank you for putting this draft together. It's exactly as promised. I would suggest, though, that it needs to be treated as standards track, rather than informational. We know there are folks who would like to use the X.500 subentry for LDUP schema, and we're presently dithering over whether to just go ahead and refer to your document in the LDUP schema (that would let us go ahead and create the proposal to the X.500 group as to how to represent replica toplogy knowledge using X.500 subentries for consideration in future standards work). At this point, then, that's my only suggestion for the document - make it a standards track document. Thanks, Ed ref: http://search.ietf.org/internet-drafts/draft-zeilenga-ldap-subentry-00.txt ================= Ed Reed Reed-Matthews, Inc. +1 716 624 2402 (new!) http://www.Reed-Matthews.COM From owner-ietf-ldup@mail.imc.org Tue Oct 30 09:43:55 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02384 for ; Tue, 30 Oct 2001 09:43:55 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9UEM4017797 for ietf-ldup-bks; Tue, 30 Oct 2001 06:22:04 -0800 (PST) Received: from smtp.oncalldba.com (roc-24-169-98-153.rochester.rr.com [24.169.98.153]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9UEM3817792 for ; Tue, 30 Oct 2001 06:22:03 -0800 (PST) Received: from RMINC_DOM-MTA by smtp.oncalldba.com with Novell_GroupWise; Tue, 30 Oct 2001 09:17:46 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Tue, 30 Oct 2001 09:17:25 -0700 From: "Ed Reed" To: , Subject: Re: Subentries decision - internet draft withdrawn Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f9UEM3817794 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Tim - I went away from the meeting expecting that we would pull what we needed into the LDUP infomod document from the LDAP Subentries document. However, Kurt has now published a short and sweet id documenting adaption of the X.500 subentry to LDAP (see http://search.ietf.org/internet-drafts/draft-zeilenga-ldap-subentry-00.txt) and I now think we should go ahead and reference that draft, instead. What we'd do is 1) encourage Kurt to revise the draft to make it "Standards Track" instead of "Informational", so we can refer to it; 2) Follow David Chadwick's suggestion that we define the replicationAgreementSubentry class as a subclass of the X.500 subentry, and define a structure rule for it that allows containment of the replicationAgreementSubentry class entries by replicaSubentry class entries. That way we don't "break" the subentry definition, and the X.500 community can consider using the same technique to allow for name subordination (ie, containment) of subentries in the future. 3) discourage use of the specificationFilter in the SubtreeSpecification, 4) encourage a simple use of the base and ChopSpecification in the SubtreeSpecification Items 3 and 4 represent my bias, towards defining simple replicationAreas of non-overlaping partitions of an Administration Area. I'd appreciate hearing from the list whether such simplification is worth while, or not. One argument is that people will use them, because they're there, and so for interoperability sake, everyone should be required to fully support them. It's a compelling argument. Comments? Ed ================= Ed Reed Reed-Matthews, Inc. +1 716 624 2402 (new!) http://www.Reed-Matthews.COM >>> "Timothy Hahn" 08/13/01 11:15AM >>> Ed, Thanks for the summary. Was the concensus that we not use subentries at ALL with respect to the information model - i.e. just use "regular entries" for this information? This seems very easy to do at the expense of these entries "showing up" in the directory when they otherwise might not be expected. Of course, access controls and/or search filters would probably keep them from showing up in most cases anyway. I'll get to work on re-aligning the LDUP information model draft. Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) phone: 607.752.6388 tie-line: 8/852.6388 fax: 607.752.3681 "Ed Reed" 08/13/2001 10:04 AM To: , cc: Subject: Subentries decision - internet draft withdrawn Hello, all - At the IETF in London the working group chairs of the LDUP and (late) LDUPEXT working groups considered the issues raised surrounding the LDAP Subentries draft I've been working on. Their decision, as related to me, was to ask that the LDUP information model be revised so that object classes defined there for ReplicaSubentry and ReplicaAgreementSubentry no longer are treated as subentries, and that the work on the LDAP Subentries as a standards track document be ended. So, the draft is hereby withdrawn from work group consideration. The basis of the decision was that since the Access Control editors have decided not to use LDAP Subentries in their document, and since they were the only other charter-item document in the works that might have referenced the document, there appears to be insufficient interest in generalizing a variant from the X.500 version of Subentries to be worth continuing in the working group. There is a strongly felt (and forcefully expressed) feeling among several folks in the working group that there is no reason to "dummy down" the X.500 Subentry specification. So we won't. Thank you all for your patience in this matter... Ed ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM From owner-ietf-ldup@mail.imc.org Wed Oct 31 09:46:49 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20438 for ; Wed, 31 Oct 2001 09:46:49 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9VEM6m18551 for ietf-ldup-bks; Wed, 31 Oct 2001 06:22:06 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9VEM0818544 for ; Wed, 31 Oct 2001 06:22:00 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id f9VEPjC63958; Wed, 31 Oct 2001 14:25:58 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20011031060727.016c6b60@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 31 Oct 2001 06:21:20 -0800 To: "Ed Reed" From: "Kurt D. Zeilenga" Subject: Re: Subentries decision - internet draft withdrawn 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 08:17 AM 2001-10-30, Ed Reed wrote: >1) encourage Kurt to revise the draft to make it "Standards Track" >instead of "Informational", so we can refer to it; no problem. >2) Follow David Chadwick's suggestion that we define the >replicationAgreementSubentry class as a subclass of the X.500 >subentry, and define a structure rule for it that allows containment >of the replicationAgreementSubentry class entries by replicaSubentry class >entries. no problem. >3) discourage use of the specificationFilter in the SubtreeSpecification, I note that specificationFilter seems to a useful in supporting sparse replication. Kurt