From owner-ietf-ldup@mail.imc.org Tue Aug 1 00:35:56 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27513 for ; Tue, 1 Aug 2000 00:35:56 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA11163 for ietf-ldup-bks; Mon, 31 Jul 2000 21:01:20 -0700 (PDT) Received: from mailgate1.austin.ibm.com (mg01.austin.ibm.com [192.35.232.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA11156 for ; Mon, 31 Jul 2000 21:01:18 -0700 (PDT) Received: from netmail.austin.ibm.com (netmail.austin.ibm.com [9.53.250.98]) by mailgate1.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id XAA20434 for ; Mon, 31 Jul 2000 23:06:21 -0500 Received: from estokes (lig32-226-141-203.us.lig-dial.ibm.com [32.226.141.203]) by netmail.austin.ibm.com (8.8.5/8.8.5) with ESMTP id XAA25790 for ; Mon, 31 Jul 2000 23:04:47 -0500 Message-Id: <4.2.2.20000731230324.00a3f850@popmail2.austin.ibm.com> X-Sender: stokes@popmail2.austin.ibm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 31 Jul 2000 23:03:39 -0500 To: ietf-ldup@imc.org From: Ellen Stokes Subject: Fwd: Dinner BOF - Evolving LDAP Schema Entries (ELSE) Wed Aug 2 1730-1930 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >Date: Mon, 31 Jul 2000 22:45:46 -0500 >To: ietf-ldapext@netscape.com, ietf-ldup@imc.com >From: Ellen Stokes >Subject: Dinner BOF - Evolving LDAP Schema Entries (ELSE) Wed Aug 2 1730-1930 > >Here's some information on the informal (dinner) ELSE BOF. >For those interested, meet at the message board Wed Aug 2 at 1730. >Ellen > >-------------------------- > >Evolving LDAP Schema Entries (ELSE) BOF > >IETF Applications Area > >LDAPv3 (RFC 2251-2252) describes how clients can locate and retrieve the >attribute types, object classes and other schema rules which govern >an entry in the directory (its subschema). The underlying schema model is >defined in X.500(93 and later). > >Neither LDAPv3 nor X.500 currently define how administrative clients can >change the subschema over protocol. Several distinct implementations have >been >proposed, and interoperability is needed to allow applications to place >their schema into any appropriate LDAPv3 server, and allow administrators to >evolve their schema. > >The goal of this BOF is to determine whether there is sufficient interest >in forming an IETF working group for this topic. > >This working group would define how LDAPv3 clients can create and change >subschema. In particular it would consider (but not limited to): > >- grouping of LDAP schema attribute values >- procedures for partitioning subschema administrative areas >- procedures for merging new schema elements into a subschema area >- determining allowable changes to existing schema >- procedures for updating and removing existing schema elements > >The working group would not define any schemas itself, and schema >repositories, non-LDAP directories and non-directory databases are out >of scope of the working group. > >The working group might also consider additional schema model elements >beyond those required in RFC 2251 that would be suitable for inclusion or >refinement in the subschema entry. > >BOF Agenda >- Problem statement >- Work item prioritization >- Working group charter review > From owner-ietf-ldup@mail.imc.org Tue Aug 1 00:53:15 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03667 for ; Tue, 1 Aug 2000 00:53:15 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA12528 for ietf-ldup-bks; Mon, 31 Jul 2000 21:20:07 -0700 (PDT) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA12523 for ; Mon, 31 Jul 2000 21:20:05 -0700 (PDT) Received: (qmail 5075 invoked from network); 1 Aug 2000 04:18:31 -0000 Received: from cpe-144-132-68-23.vic.bigpond.net.au (HELO w98sysrec) (144.132.68.23) by relay1.pair.com with SMTP; 1 Aug 2000 04:18:31 -0000 X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: "'Albert Langer'" , Cc: Subject: RE: 1. "Atomicity and related concepts" and 2. "ModifiersName and Other Operational Attributes" Date: Tue, 1 Aug 2000 14:23:15 +1000 Message-ID: <000001bffb70$37382ac0$17448490@vic.bigpond.net.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 CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit "U2 replies "I didn't, the entry was (-,x) and I changed THAT to (y,w)." Sorry about the typo, above should of course read: "U2 replies "I didn't, the entry was (-,x) and I changed THAT to (-,w)." From owner-ietf-ldup@mail.imc.org Tue Aug 1 05:08:15 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04240 for ; Tue, 1 Aug 2000 05:08:14 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id BAA03732 for ietf-ldup-bks; Tue, 1 Aug 2000 01:35:27 -0700 (PDT) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA03725 for ; Tue, 1 Aug 2000 01:35:25 -0700 (PDT) Received: (qmail 2496 invoked from network); 1 Aug 2000 08:33:53 -0000 Received: from cpe-144-132-68-23.vic.bigpond.net.au (HELO w98sysrec) (144.132.68.23) by relay1.pair.com with SMTP; 1 Aug 2000 08:33:53 -0000 X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: Cc: Subject: RE: 5. "Oscillation" Date: Tue, 1 Aug 2000 18:38:42 +1000 Message-ID: <000701bffb93$e66f95a0$17448490@vic.bigpond.net.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 CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <001001bff13a$a1012ff0$b05508cb@osmium.adacel.com.au> Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [Steve] Suppose I have two replicas, R1 and R2, and an application that modifies a particular entry, E, at intervals of one hour. One instance of the application sends its modify requests to R1 every 15 minutes past the hour. A second instance of the application sends its modify requests to R2 every 45 minutes past the hour. The replication agreements are set up such that R1 initiates a replication session with R2, every hour on the hour, and R2 initiates a replication session with R1, every hour on the half hour. [...] ... and so it goes on, ad infinitum, with the two replicas growing two independent strands in the change tree for E. Neither strand ever becoming the single durable strand. If you set the replication schedules the right way (R3 <-> R1 at h:20, R3 <-> R2 at h:50) a third replica will alternate between these two strands. [Albert] I have omitted the details and confirm that MDCR would behave exactly as you describe. This might be a useful example to add, perhaps in a more tabular form, to help explain the details of the weeding and summarizing mechanism as Ryan requested. It is fairly obvious for ANY replication protocol that if an entry is being changed continually it cannot converge to a common state. That is not non-convergence, let alone oscillation. Non-convergence means that some finite sequence of changes does not eventually result in a common state within some bounded limit (which should be specified as the convergence delay), after no further changes are occurring. Oscillation means that some finite sequence of changes can result in continued indefinate alternation among two or more states. That is quite a common problem in protocols, usually dealt with by hop counts or traces. I guess your real point is rather that URP does not need any mechanism to deal with situations like you have described, whereas MDCR does. I agree that you have shown the current MDCR weeding and summarizing mechanism would not prevent a strand just continuing to grow forever, supporting Ryan's concern that large trees could become a problem. In general, the circumstances in which that would occur are where concurrent changes to an entry are *continually* happening within an interval no greater than the convergence delay limit. That is clearly a circumstance in which multi-master replication is being used inappropriately by an application, and sysadmin intervention would be required to fix it anyway, if the users didn't. MDCR is reasonably robust about that. For example with 12 bytes tree overhead in RAM, a strand could reach a length of 80,000 before occupying 1MB. With replication 100 times per day (more than 4 times the hourly interval you gave in the example), that would take more than 2 years. I still think it is likely that any applications behaving like this would be fixed anyway, before tree length became an issue, since they could not achieve anything useful and are therefore unlikely to keep doing it *continually*. They only have to stop making pointless changes *occasionally* for long enough, and the strand would get summarized. However as Murphy's law is the first law of protocol design, I agree that this issue should be dealt with, together with the full specification of convergence delays, if MDCR is added to the WG agenda. A specification of maximum tree length to trigger syadmin notification of a problem, or perhaps automated action, could be added, or included in general replica management standards. [...] > Here's a semi-formal proof that neither I nor anybody else > will be able to > come up with an example showing that URP also oscillates. [...] > 3. That entry state will replace any other it encounters and > will therefore > propagate to all replicas. (Leaving aside the fixable problem > with relying > on time stamps etc). [Steve] Your proof neglects the role of the purging mechanism. You have to show that all replicas will get all changes in spite of the cleanup going on in parallel, and in spite of the effects of restoring a replica from backup. Having shown that all replicas get all changes it is still necessary to show that all possible processing orders of the change reports produce the same outcome. The open-endedness of the list of changes can't be neglected either. [Albert] I explicitly qualified the proof that URP converges with the words "Leaving aside the fixable problem with relying on time stamps etc". I had already demonstrated that URP does NOT converge in item 4, precisely because of the issues concerning the purging mechanism and the problem of DSAs crashing and being restored from backups explained there: *** An important reason why priority for version numbers rather than timestamps is essential is to meet requirements for eventual convergence. The architecture draft explicitly states that there is no mandatory requirement for clock synchronization, which is reasonable because experience shows clocks do go out of sync regardless (4.5.3). It goes on to state "If timestamps are not accurate, and a server consistently produces timestamps which are significantly older than those of other servers, its updates will not have any effect and the real world time ordering of updates will not be maintained." In 13. Time, the architecture draft states: "The server must reject update operations, from any source, which would result in setting a CSN on an entry or a value which is earlier than the one that is there". The consequence of course is not just that "the real world time ordering of updates will not be maintained". *That* is an inevitable consequence of the fact that real world clocks are out of sync anyway. What will *ALSO* happen, is that changes made by DUAs will be accepted by some DSAs (eg those synchronized to the same clocks), and rejected by others, as explicitly required. DSAs *do* crash, and *do* get restored from backups, but URP simply ignores the consequences. Consequently there will be no eventual convergence, but increasing divergence, which will require manual sysadmin repairs to discover and fix entries that were only partially propagated. *** I was not attempting to refute myself. It is YOU who would have to show various things in order to complete a proof that URP converges with the present mechanism. As I understand it, you have not yet responded directly to that, but have tacitly admitted that you cannot do so by stating: "I have a procedure for solving the replica consistency problems of restored replicas and rejoined partitions but it is written in terms of a log-based implementation using a different purging mechanism. I'm still in the process of recasting it in state-based terms with an update vector." http://www.imc.org/ietf-ldup/mail-archive/msg00638.html I have attempted a semi-formal proof that MDCR does converge, with "weeding and summarizing" going on in parallel and despite network partitioning, DSA crashes and restorations etc in the full MDCR draft: http://www.ietf.org/internet-drafts/draft-langer-ldup-mdcr-00.txt If you (or anyone else) can see a problem in that, please draw it to my attention more specifically. From owner-ietf-ldup@mail.imc.org Tue Aug 1 08:34:10 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22920 for ; Tue, 1 Aug 2000 08:34:10 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id EAA23377 for ietf-ldup-bks; Tue, 1 Aug 2000 04:57:10 -0700 (PDT) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA23373 for ; Tue, 1 Aug 2000 04:57:08 -0700 (PDT) Received: (qmail 5829 invoked from network); 1 Aug 2000 11:55:39 -0000 Received: from cpe-144-132-68-23.vic.bigpond.net.au (HELO w98sysrec) (144.132.68.23) by relay1.pair.com with SMTP; 1 Aug 2000 11:55:39 -0000 X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: Cc: Subject: RE: 3. "Change Reports - ProtocolOps or Primitives" Date: Tue, 1 Aug 2000 22:00:29 +1000 Message-ID: <000a01bffbb0$16efe6a0$17448490@vic.bigpond.net.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 CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <001701bff155$9f3a5e60$b05508cb@osmium.adacel.com.au> Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Steve, I've now caught up with all other responses but am still unsure what you are getting at on this one. I'm omitting some and just focussing on the bits I *think* I understand. But they make so little sense to me that I'm still not sure I really do. [Steve] [...] The problem is that a list of all the standard LDAP or X.500 update operations does not describe all the possible update behaviours exhibited by directory servers. [...] For the protocol design there was a discussion on whether the user updates would be conveyed in the replication PDUs in their original form, which was then broken down in to primitives by each replica to be processed, or instead as the broken down set of primitives determined by the originating server. It was a given at that time that the updates would be broken down into primitives at some point, so it naturally came down to a choice between LDAP update request or replication primitives in the protocol. The replication primitives can describe exactly how a directory server executed a user update request without regard for the access protocol, protocol extensions, conformance level, support for operational attributes, etc. The small set of replication primitives is sufficient to describe a much larger set of current and future directory server behaviours, as well as being the basis for reconciling updates. [Albert] Ok, I understand that URP took as a given that operations would be broken down into primitives at some point, whereas MDCR took as given the opposite principle of treating operations as a whole ("atomicity"). I still don't see how anything follows from that as to the desirability of using the ASN for protocolOps or primitives in the protocol "on the wire". As far as I can see, either approach could switch to either format for reports generated by originator DSAs. That highlights the advantages of separating report propagation from update processing. You still *seem* to be raising an issue of primitives supporting non-LDAP directories better than protocolOps. This WG is about LDAP directories. There could well be other LDAP replication protocols, eg broadcast, defined in future. They will still take as given that the directory supports what standard LDAP clients expect it to support. Update procedures (whether based on reconciliation or conflict resolution) should be applied at each DSA independently of propagation of originator reports to ALL DSAs. That maps well to the fact that any LDAP client can update any LDAP server - the whole point of LDAP. A list of all the standard LDAP change operations *does* describe ALL the possible change behaviours that LDUP can define standards about. If some behaviour cannot be expressed in terms of standard change operations then its replication cannot be standardized. They are carefully aligned with X.500 so that they can be mapped with X.500 DAP change operations. > On the other hand you might more plausibly have meant to say that the > original protocolOp as received by the originating DSA may > include such > non-standardized information, or not be based on a DUA > protocolOp at all, > and therefore should or could not just be copied verbatim by MDCR. [Steve] That's what I was saying. [...] I think you might be underestimating how difficult it will be to translate arbitrary extensions, controls and alternative access protocols into canonical protocolOps. For one thing you will have to be prepared for a single user update to map into multiple protocolOps affecting multiple entries. I can think of a number of features in our directory and other vendor's directories that would require this. [Albert] Whatever the difficulties, that is exactly what an implementor has to do to generate either protocolOps or primitives at the originator DSA. Allowing arbitrary extensions to affect the propagation of change reports would be even more nightmarish. Some implementations will benefit from being able to copy the DUA protocolOp verbatim. Others will not, but anything extra they have to do is their problem, not ours. As long as they *can* map their directory to LDAP standards, they can benefit from LDAP standards. Whatever the "features" in your directory that have led you to contemplate URP, I can only suggest that you fix them and that other vendors with similar problems do likewise. The IETF standards process is not about fixing vendor problems resulting from failure to comply with existing standards. For example backlinks for pseudo referential integrity such as a memberOf attribute in a User entry that lists what groups the user is a member of could either be efficiently generated automatically at each compatible DSA or explicitly generated at the originator so that they would also update DSAs that have no such facility. Only the former makes sense to me, for future standardization of backlinks, and also for current interoperability, as the latter would still result in inconsistent backlinks from changes originated at DSAs that do not support that facility. But either way, allowing DSAs *other* than the originator to generate ANYTHING based on its arbitrary features while propagating, or allowing originators to generate anything that cannot be expressed as standard change operations, is a certain recipe for incompatability. Checkout the ASN for an LDAP protocolOp in RFC 2251. The subset for change operations includes ALL the information that is included in the set of URP primitives generated at an originator DSA and replicated in a framed operation to its neighbours, except for the entryIDs. An MDCR "report" adds the entryIDs and therefore includes ALL the information required to apply URP procedures. Simply re-using the existing ASN just makes the MDCR protocol much shorter to specify and easier to understand. If there was any reason to do so, an MDCR report could be reformatted as a sequence of URP primitives, adding the DN of the entry and the report and version numbers etc omitted by URP. I still cannot see any reason to do so. The critical distinction in report propagation is that MDCR replicates that report unchanged to every DSA and each applies it independently, whereas URP merges or reconciles reports while propagating them, thus adding to the inherent problems of merging or reconciling them at all. If for some reason, URP "reconciliation" was desirable, it could be done independently at each DSA in applying the reports (or primitives) while still having the same approach as MDCR in propagating every report (or every originator primitive) to every DSA. Complete separation of report propagation from update processing is a more natural "layered" approach to protocol design and makes it much easier to understand and predict the result, achieve convergence etc etc. A possible explanation for whats going on here is that certain vendors may have adopted a "state based" approach to replication that cannot be reconciled with the atomicity required by LDAP standards, and are trying to get IETF endorsement of a revision of the standard through the back door. If that IS what is going on, they should instead propose up front a revision to LDAP v3 while it is still a "proposed standard" rather than a "draft" standard or "standard". A vendor dominated WG revising a base standard won't cut it at final call. If a group of vendors want their own "industry" standard rather than either X.500 or LDAP, they can easily establish a forum to define it. LDAP has been adopted by vendors precisely because clients based on real standards make more sense than trying to combine the features available in various proprietary clients. Exactly the same will prove true when servers are replicating to each other as well as interacting with clients. You either standardize or you don't interoperate. [Steve] I regard efficiency on the wire as largely a non-issue for replication. My experience with X.525/DISP is that supplier DSAs can pump changes through to consumers at least an order of magnitude faster than the consumers can process them. A super efficient LDUP protocol won't make much overall difference. [Albert] I agree that the number of bytes is a non-issue. As a separate matter, allowing replication out of sequence requires a restart from the beginning to ensure update vectors are synchronized whenever a replication session is interrupted. That is most likely to happen on connection oriented links where bandwidth is most costly. I mentioned in email to Ed and will now repeat here, that this is especially a problem for "sometimes connected" or dialup DSAs that may need to interrupt a "supplier push" session to a Hub from another dialup DSA in order to obtain a session for the same replicated area, given that only one consumer session can be handled at a time by the Hub. Likewise, use of timestamps requires a full reload rather than incremental to get back into sync after failures, which causes bandwidth spikes. Both of these "features" of the current architecture draft are not inherent in URP but easily fixed. So far nothing has been done to fix them. Unlike the number of bytes in the syntax, they would have a significant impact on bandwidth requirements. > I also believe it is important not to impede future extensions to the > replication protocol to cover future standardization of > additional features > such as "signed operations". URP impedes this by nuking > operations so that > the very concept of an operation has been lost once it has > been subjected to > atomic fission and its constituent elements sent wandering through the > replication network. MDCR preserves the concept of a "whole" > operation (ie > an "atomic" operation), for other reasons, but has the > additional benefit of > not impeding future developments such as signed operations.o [Steve] Signed user operations are no more an issue for LDUP than they are for DISP (i.e. irrelevant). X.500 has signed operations and doesn't use the original DAP operations in its replication protocol and I've never found a problem with that. In any case, a canonical MDCR change report would invalidate the operation signature as surely as breaking the operation down into primitives. [Albert] X.500 DISP is single master and replicates operations, whatever the format. RFC 2649 (experimental) specifies a "signedAuditTrail" which includes a set of changes, each of which has a sequence number and a signed operation. A DSA can add its own signatures verifying the signed operations and a DUA can check the signed operations in sequence to verify that the entry state it is relying on is supported by signatures it trusts. This is particularly important for multi-master replication because every DSA and connection is an independent point of vulnerability. In that environment, certain critical functions are more likely to need verification of the origin of the data as they cannot just trust a SINGLE DSA and the path from it, but must trust an entire network of them, not all under the same management. URP cannot meet any such requirement because the entry state is NOT the result of applying a sequence of operations, as required by the LDAP/X.500 data model and assumed by people writing both applications and extensions for it. RFC 2649 is another excellent example of this assumption at work. MDCR can support signed operations because entry state IS the result of a carefully maintained sequence of operations, as required for atomicity. Perhaps the fundamental problem with non-atomicity is best illustrated by that in itself - nobody could guarantee the integrity of the result with a signature, because the result does not in fact have that integrity. Actual implementation of that support would require liasion with LDAPEXT to define replication of the "signatureIncluded" field of the signedOperation control and what to do when the originator DSA generates a signature on behalf of the DUA. Rather than carrying both the DUA original protocolOp used for the signature AND either a set of primitives or a canonical protocolOp used for report propagation, it would be better, if possible, to avoid that duplication by defining a canonical protocolOp to be used for signed operations. (Perhaps using DER, rather than BER and mime as specified in RFC 2649). This issue is "irrelevant" for URP since it cannot possibly support signed operations anyway. That does not make it irrelevant for LDUP. The fatal mistake of treating the LDAP v3 standard requiring atomicity as irrelevant is what makes URP irrelevant for LDAP and therefore for LDUP. Incidentally, liaison will also be necessary concerning the "zombieObject" used in RFC 2649 to maintain an audit trail for deletions. [ACI issues moved to item 9] From owner-ietf-ldup@mail.imc.org Tue Aug 1 10:02:04 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12710 for ; Tue, 1 Aug 2000 10:02:03 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA28285 for ietf-ldup-bks; Tue, 1 Aug 2000 06:26:51 -0700 (PDT) Received: from infidel.boolean.net (root@router.boolean.net [198.144.206.49]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA28280 for ; Tue, 1 Aug 2000 06:26:50 -0700 (PDT) Received: from gypsy.OpenLDAP.org (root@infidel.boolean.net [198.144.202.225]) by infidel.boolean.net (8.9.3/8.9.3) with ESMTP id NAA19189 for ; Tue, 1 Aug 2000 13:30:26 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <4.3.2.7.0.20000801090655.00b62840@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 01 Aug 2000 09:26:57 -0400 To: ietf-ldup@imc.org From: "Kurt D. Zeilenga" Subject: reconciliation of mutually exclusive operations 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: If the entry (contents trimmed): dn: cn=entry, dc=example, dc=net cn: entry boolean: FALSE is held by N servers in using multi-master replication and N independent, properly authorized clients each issuing the following operation to a different (willing and able) servers: dn: cn=entry, dc=example, dc=net changetype: modify delete: boolean boolean: FALSE - add: boolean boolean: TRUE - One client should get a success result code. N-1 clients should get a non-success result code. I believe that any replication specification which cannot ensure this behavior is not acting in accordance with X.500(93) as required by LDAPv3. From owner-ietf-ldup@mail.imc.org Tue Aug 1 10:17:29 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18966 for ; Tue, 1 Aug 2000 10:17:28 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA29001 for ietf-ldup-bks; Tue, 1 Aug 2000 06:38:04 -0700 (PDT) Received: from infidel.boolean.net (root@router.boolean.net [198.144.206.49]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA28996 for ; Tue, 1 Aug 2000 06:38:03 -0700 (PDT) Received: from gypsy.OpenLDAP.org (root@infidel.boolean.net [198.144.202.225]) by infidel.boolean.net (8.9.3/8.9.3) with ESMTP id NAA19231 for ; Tue, 1 Aug 2000 13:41:39 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <4.3.2.7.0.20000801094100.00b27ea0@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 01 Aug 2000 09:41:32 -0400 To: ietf-ldup@imc.org From: "Kurt D. Zeilenga" Subject: Fwd: controlling visability of subentries 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: Forwarded to LDUP list >Date: Mon, 31 Jul 2000 16:23:57 -0400 >To: ietf-ldapext@OpenLDAP.org >From: "Kurt D. Zeilenga" >Subject: controlling visability of subentries > >One other issue I would like to raise in regards to LDAP subentry >is the mechanism proposed to control their visibility. I believe >the approach of overloading the search filter to control visibility >is not the best approach. As we've found previously, the semantics >of such overloads are difficult to define (and hence implement) when >the filter is complex (which we must assume it will be). > >I believe that LDAPsubentry visibility should be control by a mechanism >more closely modeled after the X.500 subentry visibility mechanism. >In particular, I suggest use of a control. The use of a control >will allow a clear and concise specification of visibility semantics >which facilitates implementation and use. > >Comments? > > Kurt From owner-ietf-ldup@mail.imc.org Tue Aug 1 11:09:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04887 for ; Tue, 1 Aug 2000 11:09:12 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA02491 for ietf-ldup-bks; Tue, 1 Aug 2000 07:34:07 -0700 (PDT) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA02486 for ; Tue, 1 Aug 2000 07:34:06 -0700 (PDT) Received: (qmail 21718 invoked from network); 1 Aug 2000 14:32:39 -0000 Received: from cpe-144-132-68-23.vic.bigpond.net.au (HELO w98sysrec) (144.132.68.23) by relay1.pair.com with SMTP; 1 Aug 2000 14:32:39 -0000 X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: "'Kurt D. Zeilenga'" , Subject: RE: controlling visability of subentries Date: Wed, 2 Aug 2000 00:37:34 +1000 Message-ID: <000b01bffbc6$08a52400$17448490@vic.bigpond.net.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 CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <4.3.2.7.0.20000801094100.00b27ea0@router.boolean.net> Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Agree -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Kurt D. Zeilenga Sent: Tuesday, August 01, 2000 11:42 PM To: ietf-ldup@imc.org Subject: Fwd: controlling visability of subentries Forwarded to LDUP list >Date: Mon, 31 Jul 2000 16:23:57 -0400 >To: ietf-ldapext@OpenLDAP.org >From: "Kurt D. Zeilenga" >Subject: controlling visability of subentries > >One other issue I would like to raise in regards to LDAP subentry >is the mechanism proposed to control their visibility. I believe >the approach of overloading the search filter to control visibility >is not the best approach. As we've found previously, the semantics >of such overloads are difficult to define (and hence implement) when >the filter is complex (which we must assume it will be). > >I believe that LDAPsubentry visibility should be control by a mechanism >more closely modeled after the X.500 subentry visibility mechanism. >In particular, I suggest use of a control. The use of a control >will allow a clear and concise specification of visibility semantics >which facilitates implementation and use. > >Comments? > > Kurt From owner-ietf-ldup@mail.imc.org Tue Aug 1 13:29:49 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10281 for ; Tue, 1 Aug 2000 13:29:48 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA11983 for ietf-ldup-bks; Tue, 1 Aug 2000 09:55:01 -0700 (PDT) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA11976 for ; Tue, 1 Aug 2000 09:54:59 -0700 (PDT) Received: (qmail 15822 invoked from network); 1 Aug 2000 16:53:32 -0000 Received: from cpe-144-132-68-23.vic.bigpond.net.au (HELO w98sysrec) (144.132.68.23) by relay1.pair.com with SMTP; 1 Aug 2000 16:53:32 -0000 X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: "'Kurt D. Zeilenga'" , Subject: RE: reconciliation of mutually exclusive operations Date: Wed, 2 Aug 2000 02:58:27 +1000 Message-ID: <000c01bffbd9$b71bf140$17448490@vic.bigpond.net.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 CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <4.3.2.7.0.20000801090655.00b62840@router.boolean.net> Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [Kurt] If the entry (contents trimmed): dn: cn=entry, dc=example, dc=net cn: entry boolean: FALSE is held by N servers in using multi-master replication and N independent, properly authorized clients each issuing the following operation to a different (willing and able) servers: dn: cn=entry, dc=example, dc=net changetype: modify delete: boolean boolean: FALSE - add: boolean boolean: TRUE - One client should get a success result code. N-1 clients should get a non-success result code. I believe that any replication specification which cannot ensure this behavior is not acting in accordance with X.500(93) as required by LDAPv3. [Albert] Correct, but unfortunately the "should" behaviour is not possible with ANY form of multi-master replication, since it would require contacting other servers before returning the response code, and by definition, multi-master does not do that. The only "standard" way to do it, would be to unilaterally disconnect after making the change, without giving a response code, since the standard does tell DUAs not to assume anything in that situation. I'm not suggesting disconnection would be a good idea, but it is an option. (The standard does permit reads conflicting with what has just been written, since that happens with single master too, as users aren't supposed to be aware of which particular DSA they are asking). For multi-master, there is NO other way to avoid them all getting a "success" response when they all perform the operation around the same time at different replicas. There may well be applications which rely on the currently expected behaviour, eg to ensure that one, and only one, of those N DUAs performs some action. MDCR could also follow up with revocation notifications to all but one of the DUAs, and a confirmation notification to one, just to inform them of the conflict. They could wait for the notification before performing the action, as a sort of delayed response, while other applications would act on the immediate operation response. But I doubt that would be very useful in practice, other than as a reminder that they should not use multi-master in this situation. Perhaps it could be useful - for some applications that need high availability but not necessarily local availability with its longer convergence delay. We won't actually know without feedback. This sort of behaviour contrary to that currently expected certainly requires at least formal justification (eg in the requirements doc), but there really isn't much more we can do about it, apart from warning people not to use multi-master in that way. If some of the DUAs had attempted to simply delete the attribute "boolean", (assumed optional), both URP and MDCR would report "success" to both those that now expect the attribute to be absent and to those which expect it to be TRUE. But MDCR would at least follow up with a notification to those which have the wrong expectation as a result, and an (optional) confirmation to those that have the right expectation. Again this might not help much, but at least users and administrators would find out promptly by email that something odd was going on as a result of inappropriate use of multi-master, rather than just be left wondering why applications dependent on standard behaviour have intermittant failures (dependent on the replication schedule and which servers happen to be contacted, and therefore about as relevant to users in understanding an intermittant problem as the phase of the moon). Its rather more serious for a non-boolean attribute. If the current value of "color" is YELLOW and some try to set it to GREEN and others to RED, by deleting YELLOW first and then adding GREEN or RED respectively, they will again all get a "success" response, which confirms the inapplicability of multi-master replication to traffic control applications ;-) With MDCR, convergence would eventually be to just GREEN, with a notification to those that thought it was now RED, if a GREEN DUA got in first (according to the clock at that replica), or vice versa. The ordering is essentially arbitrary since clocks are not synchronized. If all N clocks happened to be identical (whether or not the "real" time was identical), it would be the color at the replica with the highest replica number, which is just as arbitrary, but no more so. With URP, the same would be true for a single valued color attribute, except for no notifications. For a multi-valued color attribute the eventual result of URP would be both GREEN and RED, contrary to the expectations of ALL the DUAs. When they try to fix it by deleting the color they think shouldn't be there, the result would of course be empty, and a schema violation if the color was mandatory, but they would again all be told "success" and with no follow up notification. With the multi-valued attribute ldapACI, which IS used for a sort of "traffic control" by the directory itself, it gets rather interesting when DUAs concurrently delete an old value and replace it with different new values. I'm looking forward to Steve's response to the request for an example in item 9. These sort of issues and examples should be clearly explained in the requirements document to get feedback on how actual existing applications would be affected. BTW can anyone do a quick unofficial description of the Pittsburg discussion outcome, re requirements document, prior to official minutes? From owner-ietf-ldup@mail.imc.org Tue Aug 1 16:26:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01775 for ; Tue, 1 Aug 2000 16:26:01 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA15845 for ietf-ldup-bks; Tue, 1 Aug 2000 12:46:07 -0700 (PDT) Received: from mail.mirapoint.com (IDENT:mirapoint@mail.mirapoint.com [208.48.74.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA15841 for ; Tue, 1 Aug 2000 12:46:06 -0700 (PDT) Received: from mail.mirapoint.com (mail.mirapoint.com [192.168.0.18]) by mail.mirapoint.com (Mirapoint) with SMTP id AAA09592; Tue, 1 Aug 2000 12:49:28 -0700 (PDT) Message-Id: <200008011949.AAA09592@mail.mirapoint.com> Date: Tue, 1 Aug 2000 12:50:02 -0700 From: Zachary Amsden Subject: RE: 3. "Change Reports - ProtocolOps or Primitives" To: Albert.Langer@directory-designs.org Cc: steven.legg@adacel.com.au, ietf-ldup@imc.org 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 Replication out of sequence does not require a restart, as long as changes are presented in order per replica. I would highly recommend text stating that changes from each replica MUST be transmitted in strictly increasing CSN order. My current implementation stores and transmits changes from each replica separately, in CSN order. This makes implementation a lot easier for everyone. I don't see any problem with requiring this. >[Albert] >I agree that the number of bytes is a non-issue. As a separate matter, >allowing replication out of sequence requires a restart from the beginning >to ensure update vectors are synchronized whenever a replication session >is interrupted. That is most likely to happen on connection oriented links >where >bandwidth is most costly. > >I mentioned in email to Ed and will now repeat here, that this is especially >a problem for "sometimes connected" or dialup DSAs that may need to >interrupt >a "supplier push" session to a Hub from another dialup DSA in order to >obtain >a session for the same replicated area, given that only one consumer session >can be handled at a time by the Hub. > >Likewise, use of timestamps requires a full reload rather than incremental >to get back into sync after failures, which causes bandwidth spikes. > >Both of these "features" of the current architecture draft are not inherent >in URP but easily fixed. So far nothing has been done to fix them. From owner-ietf-ldup@mail.imc.org Tue Aug 1 17:09:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06756 for ; Tue, 1 Aug 2000 17:09:02 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA16596 for ietf-ldup-bks; Tue, 1 Aug 2000 13:35:48 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA16592 for ; Tue, 1 Aug 2000 13:35:47 -0700 (PDT) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id PAA12302 for ; Tue, 1 Aug 2000 15:39:24 -0500 (CDT) Received: from lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr4u3.ericy.com (8.9.3/8.9.3) with ESMTP id PAA14307 for ; Tue, 1 Aug 2000 15:39:23 -0500 (CDT) Received: from LMC37.lmc.ericsson.se (lmc52.lmc.ericsson.se [142.133.16.192]) by lmc.ericsson.se (8.9.2/8.9.2) with ESMTP id QAA09009 for ; Tue, 1 Aug 2000 16:39:23 -0400 (EDT) Received: by lmc37.lmc.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Tue, 1 Aug 2000 16:37:31 -0400 Message-ID: <8DEF276EE650D311AD950008C7894CBC02ED7F81@lmc37.lmc.ericsson.se> From: "Youcef Dahmane (LMC)" To: ietf-ldup@imc.org Subject: ASN.1 format Date: Tue, 1 Aug 2000 16:37:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, has anybody have some GSM or/& ANSI specs in ASN.1 text format? Thank's. -Youcef From owner-ietf-ldup@mail.imc.org Tue Aug 1 21:11:34 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28455 for ; Tue, 1 Aug 2000 21:11:33 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA21652 for ietf-ldup-bks; Tue, 1 Aug 2000 17:32:10 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA21648 for ; Tue, 1 Aug 2000 17:32:09 -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 e720QER28816 for ; Tue, 1 Aug 2000 17:26:14 -0700 (PDT) Received: from netscape.com ([205.217.228.66]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FYN2YT01.FS6; Tue, 1 Aug 2000 17:35:17 -0700 Message-ID: <39876CD4.689FCF12@netscape.com> Date: Tue, 01 Aug 2000 20:35:32 -0400 From: mcs@netscape.com (Mark C Smith) Organization: iPlanet eCommerce Solutions X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Albert.Langer@directory-designs.org CC: "'Kurt D. Zeilenga'" , ietf-ldup@imc.org Subject: Re: controlling visability of subentries References: <000b01bffbc6$08a52400$17448490@vic.bigpond.net.au> 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 I also agree that it is probably better to define a control for this. Can we do so soon? FYI, our implementation of draft-ietf-ldup-subentry-03.txt today checks each equalityMatch filter component for objectclass=ldapSubEntry and considers returning subentries if it finds one anywhere. So all of these filters may result in ldapSubEntries being returned: (objectclass=ldapSubEntry) (!(objectclass=ldapSubEntry)) (&(objectclass=ldapSubentry)(cn=foo)) (|(objectclass=ldapSubEntry)(objectclass=myReplicaSubEntry)) If we stick with the filter approach, we should at least add some examples to the document. -- Mark Smith Directory Product Development / iPlanet E-Commerce Solutions My words are my own, not my employer's. Got LDAP? Albert Langer wrote: > > Agree > > -----Original Message----- > From: owner-ietf-ldup@mail.imc.org > [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Kurt D. Zeilenga > Sent: Tuesday, August 01, 2000 11:42 PM > To: ietf-ldup@imc.org > Subject: Fwd: controlling visability of subentries > > Forwarded to LDUP list > >Date: Mon, 31 Jul 2000 16:23:57 -0400 > >To: ietf-ldapext@OpenLDAP.org > >From: "Kurt D. Zeilenga" > >Subject: controlling visability of subentries > > > >One other issue I would like to raise in regards to LDAP subentry > >is the mechanism proposed to control their visibility. I believe > >the approach of overloading the search filter to control visibility > >is not the best approach. As we've found previously, the semantics > >of such overloads are difficult to define (and hence implement) when > >the filter is complex (which we must assume it will be). > > > >I believe that LDAPsubentry visibility should be control by a mechanism > >more closely modeled after the X.500 subentry visibility mechanism. > >In particular, I suggest use of a control. The use of a control > >will allow a clear and concise specification of visibility semantics > >which facilitates implementation and use. > > > >Comments? > > > > Kurt From owner-ietf-ldup@mail.imc.org Tue Aug 1 22:24:30 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11625 for ; Tue, 1 Aug 2000 22:24:29 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA28706 for ietf-ldup-bks; Tue, 1 Aug 2000 18:53:19 -0700 (PDT) Received: from mail.mirapoint.com (IDENT:mirapoint@mail.mirapoint.com [208.48.74.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA28702 for ; Tue, 1 Aug 2000 18:53:18 -0700 (PDT) Received: from mail.mirapoint.com (mail.mirapoint.com [192.168.0.18]) by mail.mirapoint.com (Mirapoint) with SMTP id AAA11175; Tue, 1 Aug 2000 18:56:54 -0700 (PDT) Message-Id: <200008020156.AAA11175@mail.mirapoint.com> Date: Tue, 1 Aug 2000 18:57:33 -0700 From: Zachary Amsden Subject: Re: controlling visability of subentries To: Mark C Smith Cc: ietf-ldup@imc.org 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 Yes, a control is definitely needed. I wasn't looking forwards to parsing arbitrary filters correctly. Also, since ldapSubEntries aren't actually in our object databases, but are metadata, using a control is a much easier way to figure this out. >I also agree that it is probably better to define a control for this. >Can we do so soon? > >FYI, our implementation of draft-ietf-ldup-subentry-03.txt today checks >each equalityMatch filter component for objectclass=ldapSubEntry and >considers returning subentries if it finds one anywhere. So all of >these filters may result in ldapSubEntries being returned: > >(objectclass=ldapSubEntry) >(!(objectclass=ldapSubEntry)) >(&(objectclass=ldapSubentry)(cn=foo)) >(|(objectclass=ldapSubEntry)(objectclass=myReplicaSubEntry)) > >If we stick with the filter approach, we should at least add some >examples to the document. From owner-ietf-ldup@mail.imc.org Wed Aug 2 12:27:29 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13826 for ; Wed, 2 Aug 2000 12:27:28 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA17211 for ietf-ldup-bks; Wed, 2 Aug 2000 08:54:34 -0700 (PDT) Received: from etrn.xmission.com (etrn.xmission.com [198.60.22.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17206 for ; Wed, 2 Aug 2000 08:54:32 -0700 (PDT) Received: from [166.70.104.49] (helo=reed.oncalldba.com) by etrn.xmission.com with smtp (Exim 2.12 #1) id 13K0uC-0003Xp-00 for ietf-ldup@imc.org; Wed, 2 Aug 2000 09:58:04 -0600 Received: from RMINC_DOM-Message_Server by reed.oncalldba.com with Novell_GroupWise; Wed, 02 Aug 2000 09:58:03 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Wed, 02 Aug 2000 09:50:14 -0600 From: "Ed Reed" To: , Cc: , Subject: Re: controlling visability of subentries 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 ns.secondary.com id IAA17207 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Okay - there seems to be concensus on the matter... Now - should I specify a new control, or use one someone else already has defined? Suggestions appreciated. Regards, Ed >>> Zachary Amsden 8/1/00 7:57:33 PM >>> Yes, a control is definitely needed. I wasn't looking forwards to parsing arbitrary filters correctly. Also, since ldapSubEntries aren't actually in our object databases, but are metadata, using a control is a much easier way to figure this out. >I also agree that it is probably better to define a control for this. >Can we do so soon? > >FYI, our implementation of draft-ietf-ldup-subentry-03.txt today checks >each equalityMatch filter component for objectclass=ldapSubEntry and >considers returning subentries if it finds one anywhere. So all of >these filters may result in ldapSubEntries being returned: > >(objectclass=ldapSubEntry) >(!(objectclass=ldapSubEntry)) >(&(objectclass=ldapSubentry)(cn=foo)) >(|(objectclass=ldapSubEntry)(objectclass=myReplicaSubEntry)) > >If we stick with the filter approach, we should at least add some >examples to the document. From owner-ietf-ldup@mail.imc.org Thu Aug 3 09:11:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23438 for ; Thu, 3 Aug 2000 09:11:40 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA05506 for ietf-ldup-bks; Thu, 3 Aug 2000 05:35:54 -0700 (PDT) Received: from printfile.ietf.marconi.com (printfile.ietf.marconi.com [147.73.128.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA05499 for ; Thu, 3 Aug 2000 05:35:52 -0700 (PDT) Received: from dwc-acer (wired-129-180.ietf.marconi.com [147.73.129.180]) by printfile.ietf.marconi.com (8.9.3/8.9.3) with ESMTP id IAA08165; Thu, 3 Aug 2000 08:43:40 -0400 (EDT) From: "David Chadwick" Organization: University of Salford To: Zachary Amsden , ietf-ldup@imc.org Date: Thu, 3 Aug 2000 13:38:55 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: more proposed protocol changes Reply-to: d.w.chadwick@salford.ac.uk Message-ID: <398975EF.15319.3BDD1@localhost> In-reply-to: <200008010005.AAA06550@mail.mirapoint.com> X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Date sent: Mon, 31 Jul 2000 17:05:30 -0700 From: Zachary Amsden Subject: more proposed protocol changes To: ietf-ldup@imc.org > To accomodate simultanaeous LDUP partial updates to > the same replica, it would make sense to allow the sender to > optionally send an update vector containing describing the > CSNs it is about to send. This could be passed back to other > suppliers for the same replica in the startReplicationResponse > while the original replication is proceeding. Zachary I worry about this sort of procedure, since the consumer is saying to the other suppliers that it has received the updates (from the first supplier) before it actually has. Once these suppliers store that update vector they will never attempt to update the consumer with these updates. Worse than that, if the connection with the first supplier breaks, the consumer now does not have the updates it has told everyone (except the first supplier) that it does have. What if the first supplier replicates with say the third supplier and gets the update vector from it before it restarts it link to the consumer. The first will now think that the consumer has the updates, wont it? David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From owner-ietf-ldup@mail.imc.org Thu Aug 3 09:42:29 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02472 for ; Thu, 3 Aug 2000 09:42:28 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA06948 for ietf-ldup-bks; Thu, 3 Aug 2000 06:06:39 -0700 (PDT) Received: from monet.digsigtrust.com (mail.digsigtrust.com [208.30.69.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA06944 for ; Thu, 3 Aug 2000 06:06:37 -0700 (PDT) Received: from digsigtrust.com (89.salt-lake-city-01-02rs.ut.dial-access.att.net [12.72.136.89]) by monet.digsigtrust.com (8.10.2/8.10.2) with SMTP id e73DAEv11879; Thu, 3 Aug 2000 07:10:14 -0600 (MDT) Message-ID: <39896D73.9C5FE92D@digsigtrust.com> Date: Thu, 03 Aug 2000 07:02:43 -0600 From: Russel F Weiser X-Mailer: Mozilla 4.73 [en]C-CCK-MCD NSCPCD47 (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: internet-drafts@ietf.org, ietf-ldup@imc.org, Ellen Stokes Subject: draft-ietf-ldup-replica-req-04.txt Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms347D56AF6855A69FE1F07227" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms347D56AF6855A69FE1F07227 Content-Type: multipart/mixed; boundary="------------D1ABE676EA3E34B67276C6F0" This is a multi-part message in MIME format. --------------D1ABE676EA3E34B67276C6F0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This is a updated version of the replication requirements document. requested by the LDUP working group to be updated. cheers RFW --------------D1ABE676EA3E34B67276C6F0 Content-Type: text/plain; charset=iso-8859-1; name="draft-ietf-ldup-replica-req-03.txt" Content-Disposition: inline; filename="draft-ietf-ldup-replica-req-03.txt" Content-Transfer-Encoding: 8bit INTERNET-DRAFT Russel F. Weiser Informational Draft Digital Signature Trust Co. Expires 21 April 2000 Ellen Stokes IBM 2 August 2000 LDAP V3 Replication Requirements Status of this Memo This document is am 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. Abstract This document discusses the fundamental requirements for replication of data accessible via the LDAPv3 [RFC2251] protocol. It is intended to be a gathering place for general replication requirements needed to provide interoperability between informational directories. 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 [RFC2119]. Weiser & Stokes 21 April 2000 [PAGE 1] INTERNET-DRAFT LDAP Replication Requirements 2 August 2000 Table of Contents 1.Introduction.....................................................3 2. Terminology.....................................................3 3. Objective.......................................................5 4. Applicability Statement.........................................5 5. Replication Model..............................................10 6. Replication Protocol...........................................12 7. Schema.........................................................13 8. Administration and Management Considerations...................13 9. Acknowledgement................................................14 10. References....................................................15 11. Author's Address..............................................15 Weiser & Stokes 2 Febuary 2000 [Page 2] INTERNET-DRAFT LDAP Replication Requirements 2 August 2000 1. Introduction The ability to distribute directory information throughout the network provides a two fold benefit to the network: (1) increasing the reliability of the directory through fault tolerance, and (2) brings the directory content closer to the clients using the data. LDAP’s acceptance as an access protocol for directory information is driving the need to distribute LDAP directory content among servers within enterprise and Internet. Currently LDAP does not define a replication mechanism and only generally mentions LDAP shadow servers (see [RFC2251] and [Changelog]) in passing. The requirements for replication are critical to the successful deployment and acceptance of LDAP in the market place. 2. Terminology For the purposes of this document, the following terminology definitions are used: Area of replication - A whole or portion of a directory tree(DIT) making up a distinct unit of data to be replicated. This may also be known as "unit of replication". Atomic operation - The ability to treat and contain several updates or attribute changes as a single operation for replication purposes to guarantee that the several updates or attribute changes are propagated to a replica as a single unit. Authoritative Master Replica - The Primary updateable replica of the replicated information. Conflict resolution - Deterministic procedures within replication protocols, utilized to resolve change information conflicts that may arise due to conflicting changes affecting a directory entry. Fractional replication - The capability to replicate a subset of attributes of any given entry. Incremental Update - The process of updating a replica, or copy, of a naming context, by updating only those fields or objects which have changed. Master Slave, or Single Master Replication - Replication model that assumes only one server, the master, allows write access to the replicated data. Note that Master-Slave replication can be considered a proper subset of multi-master replication. Weiser & Stokes 2 Febuary 2000 [Page 3] INTERNET-DRAFT LDAP Replication Requirements 2 August 2000 Multi-Master Replication - A replication model where entries can be written and updated on any of several updateable replica copies without requiring communication with other updateable replicas before the write or update is performed. Naming Context - Suffix of a Sub-tree. A sub-tree of entries held in a single server [X.500]. One-way Replication - The process of synchronization in a single direction where the authoritative source information is provided to a replica. Partial Replication - The capability to replicate some subset of entries in a naming context. Propagation behavior - The general behavior of the actual synchronization process between a consumer and a provider of replication information. Read-only Replica - A read-only copy of a replicated directory. A read-only replica is assumed to be a slave replica of master slave or single master replication definition. Replica - A single instance of a whole or portion of the Directory tree (DIT) as defined by area of replication. Replica Ring - A set of servers, which hold in common the same DIT information as, defined by “Area of replication”. These servers may be managed under a single replication agreement that handles all members of the set of servers as a group. Replica Cycle - When a change or groups of changes need to be propagated to the other member of a replica ring. The process of contacting a replica member would be considered the beginning of a replication cycle; the termination of communications with a replica is the end of the cycle whether its due to an error or successful exchange of update records. Replication - The process of copying portions of naming context information and content between multiple LDAP servers, such that certain predefined portions of the information are available from different servers. Replication can occur between either homogeneous implementations across heterogeneous platforms (operating systems) or heterogeneous implementations supporting identical replication across heterogeneous platforms (operating systems). Sparse Replica - A incomplete copy of a sub-tree which maybe inclusive with updateable, or Read-only. See Partial replication and Weiser & Stokes 2 Febuary 2000 [Page 4] INTERNET-DRAFT LDAP Replication Requirements 2 August 2000 Fractional replication. Topology - Refers to the shape of the directed graph describing the relationships between replicas, as in the replicated directory topology. Two-way Replication - The process of synchronization where change information may flow bi-directionally between two replica. Update Propagation - Protocol-based process by which directory replicas are reconciled. Updateable Replica - A Non-authoritative read-writeable copy of the replicated information. Such that during conflict resolution a authoritative master takes precedents in resolving conflicts. 3. Objective The major objective is to provide an interoperable LDAP V3 directory synchronization protocol which is simple, highly efficient and flexible enough to support both multi-master and master-slave replication operations to meet the needs of both the internet and enterprise environments. 4. Applicability Statement Generally replication can be characterized by looking at data consistency models across existing technologies. This may provide insight to LDAP v3 replication requirements. The following is a brief examination of the following data models. Model 1: Tight Consistency -- Includes environments where all replicas must always contain exactly the same directory content. Two phase commit transaction models may be used to preserve transaction consistency. Model 2: Eventual Consistency or Transient Consistency -- Includes X.500 Directories, Bayou [XEROX], and NDS (Novell Directory Services) names service where definite knowledge of the global replica topology is provided through predetermined replication agreements. Such that every update propagates to every replica that it can reach via a path of stepwise eventual connectivity. Transaction consistency is preserved for transactions directed at the master server in X.500 implementations. NDS additionally provides deterministic consistency over time to all replicas due to its inherent replication policies. Weiser & Stokes 2 Febuary 2000 [Page 5] INTERNET-DRAFT LDAP Replication Requirements 2 August 2000 Model 3: Limited Effort Eventual Consistency -- Includes Xerox Clearinghouse [XEROX] that provides a statistical probability of convergence with global knowledge of replica topology. Similar to "Eventual Consistency", except where replicas may purge updates therefore dropping propagation changes when some replica time boundary is exceeded, thus leaving some changes replicated to a portion of the replica topology. Transactional consistency is not preserved, though some weaker constraints on consistency are available. Model 4: Loosest Consistency -- Includes opportunistic or simple cache where information is provided from the cache until stale. Model 5: Ad hoc -- A copy of a date store where no follow up checks are made for the accuracy/freshness of the data. Consistency models 2, and 3 involve the use of prearranged replication agreements or "Predefined Replication Agreements" between cooperating servers. The complexity of Model 1's use of 2- phase commit adds additional overhead that should not considered at this time. Models 4 and 5 involve unregistered replicas which "pull" updates from another directory server without that server's knowledge. These models can be considered to violate a directory's security policies. Therefore models 1, 4, and 5 are declared to be out of scope of this working group. So through further review of these consistency models two application areas can then be derived with even further characterizations of the data types usages. Eventual Consistency or Transient Consistency (Model 2) - This model provides policy configuration through security management parameters; the data is more dynamic and utilizes dynamic address information. Limited Effort Eventual Consistency (Model 3) - This model matches a white-pages environment which contains fairly static data and address information. This model mainly replicates message attributes. Therefore it is believed an LDAP replication should be flexible enough to cover the above range of capabilities. The generalized use of LDUP replication environment is to provide for the distribution of LDAP directory information in order to improve accessibility and consistency of the information held by the directory. 4.1 Replication Scenarios Weiser & Stokes 2 Febuary 2000 [Page 6] INTERNET-DRAFT LDAP Replication Requirements 2 August 2000 The following directory deployment examples are intended to substantiate and validate our replication requirements. It is assumed in all cases that directory implementations from different vendors are involved. 4.1.1 Extranet Example A company has a trading partner to whom it wishes to provide directory information. This information may be as simple as a corporate telephone directory, or as complex as an extranet work flow application. For performance reasons the company may wish to have a replica of its directory within the Partner Company, rather than simply exposed beyond its firewall. The requirements, which follow from this scenario, are: - One-way replication, single mastered. - Authentication of clients. - Common access control and access control identification. - Secure transmission of updates. - Selective attribute replication (Fractional Replication), so that only partial entries can be replicated. 4.1.2 Consolidation Example Company A acquires company B. In the transition period, whilst the organizations are merged, both directory services must coexist. Company A may wish to attach company B's directory to its own. The requirements, which follow from this scenario, are: - Multi-Master replication. - Common access control model. Access control model identification. - Secure transmission of updates. - Replication between DITs with potentially differing schema. 4.1.3 Replication Heterogeneous Deployment Example An organization may deliberately deploy multiple directory services within their enterprise to employ the differing benefits of each service. In this case multi-master replication will be required to ensure that the multiple updateable replicas of the DIT are synchronized. Some vendors may provide directory clients, which are tied to their own directory service. The requirements, which follow from this scenario, are: - Multi-Master replication Weiser & Stokes 2 Febuary 2000 [Page 7] INTERNET-DRAFT LDAP Replication Requirements 2 August 2000 - Common access control model and Access control model identification. - Secure transmission of updates. - Replication between DITs with potentially differing schemas. 4.1.4 Shared Name Space Example Two organizations may choose to cooperate on some venture and need a shared name space to manage their operation. Both organizations will require administrative rights over the shared name space. The requirements, which follow from this scenario, are: - Multi-Master replication. - Common access control model and Access control model identification. - Secure transmission of updates. 4.1.5 Supplier Initiated Replication A single master environment, which maintains a number of replicas of the DIT by pushing changes, based on a defined schedule. The requirements, which follow from this scenario, are: - Single-master environment. - Supplier-initiated replication. - Secure transmission of updates. 4.1.6 Consumer Initiated Replication Again a single mastered replication topology, but the replica initiates the replication exchange rather than the master. An example of this is a replica that resides on a laptop computer that may run disconnected for a period of time. The requirements, which follow from this scenario, are: - Single-master environment. - Consumer initiated replication. - Open scheduling (anytime). 4.1.7 Prioritized attribute replication The password attribute can provide an example of the requirement for prioritized attribute replication. A user is working in Utah and the administrator resides in California. The user has forgotten his password. So the user calls or emails the administrator to request a new password. The administrator provides the updated password (a change). Policy states that this attribute is critical and must be Weiser & Stokes 2 Febuary 2000 [Page 8] INTERNET-DRAFT LDAP Replication Requirements 2 August 2000 available to the user for login immediately (e.g. shortly) after the administrator changed it. Replication needs to occur immediately for critical attributes/objects. The requirements, which follow from this scenario, are: - Incremental replication of changes. - Automatic replication on change of certain attributes. - Replicate based on time/attribute semantics. 4.1.8 Bandwidth issues The replication of Server (A) R/W replica (a) in Katmandu is handled via a dial up phone link to Paris where server (B) R/W replica of (a) resides. Server (C) R/W replica of(a) is connected by a T1 connection to server (B). Each connection has a different performance characteristic. The requirements, which follow from this scenario, are: - Minimize repetitive updates when replicating from multiple replication paths. - Incremental replication of changes. - Provide replication cycles to delay and/or retry when connections can not be reached. - Allowances for consumer initiated or supplier initiated replication. 4.1.9 Interoperable Administration and Management The administrator with administrative authority of the corporate directory which is replicated by numerous geographically dispersed LDAP servers from different vendors notices that the replication process is not completing correctly as the change log is continuing to grow and/or error message informs him. The administrator uses his $19.95 RepCo LDAP directory replication diagnostics tools to look at Root DSE replica knowledge on server 17 and determines that server 42 made by LDAP’RUS Inc. is not replicating properly due to an Object conflict. Using his Repco Remote repair tools he connects to server 42 and resolves the conflict on the remote server. The requirements, which follow from this scenario, are: - Provides replication audit history. - Provisions for managing conflict resolution. - Provide LDAP access to predetermined agreements, topology and policy attributes. - Provide operations for comparing replica’s content for validity. - Provide LDAP access to status and audit information. Weiser & Stokes 2 Febuary 2000 [Page 9] INTERNET-DRAFT LDAP Replication Requirements 2 August 2000 4.1.10 Enterprise Directory Replication Mesh A Corporation builds a mesh of directory servers within the enterprise utilizing LDAP servers from various vendors. Five servers are holding the same area of replication. The predetermined replication agreement(s) for the enterprise mesh are under a single management, and the security domain allows a single predetermined replication agreement to manage the 5 servers replication. The requirements, which follow from this scenario, are: - Predefined replication agreements that manage more than a single area of replication that is held on numerous servers. - Common support of replication management knowledge across vendor implementation. - Rescheduling and continuation of a replication cycle when one server in a replica ring is busy and/or unavailable. 5. Replication Model 5.1 LDAP Replication MUST be allowed to span different vendors directory services in order to provide interoperability. 5.2 All replicas MUST eventually be updated with the changed information, if specified by the replication policy. 5.3 Replication schedules MUST be configurable to allow for periodic replication, with the replication period determined by administrator of the replicated system. 5.4 Replication Model MUST enable replication cycle to be initiated on change or based on the number of pending changes. 5.5 The replication model MUST allow for administrative initiation of replication cycle for any replica that may have just come back online or was unavailable during previous replication cycles. 5.6 The replication model MUST support both master-slave and authoritative multi-updateable replica relationships. 5.7 All replicated information between the master database and its replica databases MUST be identical including all non-user modify operational attributes such as time stamps. Note this does not imply that the entire database is identical from replica to replica, but that the subset of data, chosen to replicate is identical from replica to replica. Some operational attributes may be dynamically evaluated; these attributes will not necessarily appear to be identical. Weiser & Stokes 2 Febuary 2000 [Page 10] INTERNET-DRAFT LDAP Replication Requirements 2 August 2000 5.8 In distributed multi-vendor environment, LDAP replication MUST NOT require all copies of the replicated information be complete copies of the replicated object. 5.9 LDAP replication MUST encompass common schema objects and attributes, access control, and name space information. 5.10 Sub-tree Replication MUST be defined to allow for greater flexibility in replication topologies of the DIT as defined by the area of replication called partial replication. 5.11 Replication of critical values MUST be synchronized and have priority over non-critical values. An example of a critical value might be a password or certificate value. 5.12 Replication activities MUST occur within the context of a predefined replication agreement that addresses proper knowledge of access requirements and credentials between the synchronizing directories. Currently X.525 DISP [X.525] discusses this as a shadowing agreement including such information as unit of replication, update mode, and access point defining many of the policies between the master and a replica. 5.13 The acceptance and usage of the Internet requires that LDAP replication be available across disparate vendor directory services. 5.14 LDAP replication MUST provide scalability to both enterprise and Internet environments, e.g. an LDAP server may provide replication services to replicas within an enterprise as well as across the Internet. 5.15 The replication model MUST define deterministic policy such that replication cycle startup time conflicts between two or more competing master replicas may be resolved programmatically. An example might be automatic submission and rescheduling by one of the masters. In such a case, these replication "conflicts" MUST be resolved by the replication policy. 5.16 Any replication capable LDAP server MUST allow replication where the 2 replicating servers agree they can replicate. This may be accomplished through administrative agreements assuming compatible access control model and common schema are provided. 5.17 The replication model MUST be able to handle convergence and resurrection of attributes and objects. This is a consequence of delete and move with respect to the replication process. Weiser & Stokes 2 Febuary 2000 [Page 11] INTERNET-DRAFT LDAP Replication Requirements 2 August 2000 5.18 It is not realistic to assume that all vendors have cooperating schemas, but that replication may be allowed between diverse schema. The Model MAY allow for replication between divergent schema of objects. 6. Replication Protocol 6.1 The act of replication SHOULD have minimal impact on both the system and network performance. 6.2 The replica synchronization SHOULD be handled in such a manner as to not saturate network with repetitive entry replication from multiple synchronization providers points. 6.3 Replication MUST only be allowed after the authentication and verification of authorization of both the replica and the source directory. 6.4 The transport for LDAP synchronization MUST allow for the integrity and confidentiality of each replicated server. 6.5 Replicated data MUST be transferable in a secure manner. 6.6 Replication protocol MUST provide for recovery and rescheduling of a replication cycle due to a replication initiation conflicts (e.g. consumer busy replicating with other servers) and or loss of connection(e.g. supplier cannot reach a replica). The replication protocol MUST include restarting at the last acknowledged update prior to interruption rather than re-sending updates it had already sent to a consuming replica. 6.7 LDAP replication MUST allow for full update to facilitate replica initialization and reset loading utilizing a standardized format such as LDIF [LDIF] format. 6.8 The replication standard SHOULD NOT limit the size of a replica. The area of replication is defined to be a whole or portion of a DIT, also allowing a portion of a naming context to be replicated. Incremental replication SHOULD be allowed. 6.9 The replication agreements MUST accommodate multiple servers receiving the same replica under a single predefined agreement. 6.10 The replication protocol MUST allow either a master or replica to initiate the replication process. 6.11 Additionally the initiator MUST be allowed to determine whether it will become a consumer or supplier during the synchronization startup process. This would allow a replica to Weiser & Stokes 2 Febuary 2000 [Page 12] INTERNET-DRAFT LDAP Replication Requirements 2 August 2000 be periodically connected and synchronized from remote sites at the local administrator's discretion. 6.12 Multiple LDAP changes to a single server: If transactional consistency is propagated during replication, then multiple LDAP changes submitted to a single server SHOULD BE treated as a single 'atomic unit of work'. 6.13 An LDAP Replication Standard SHOULD NOT limit the transaction rate of a replication session. 6.14 Entry change information MUST be purged or discarded in a timely manner when change information becomes outdated due to propagated to all replica members. 7. Schema 7.1 Replica knowledge MUST be provided as DSE attributes. 7.2 The Replication Protocol documents MUST define standard schema for representing replication agreements, and MUST define the semantics associated with modifying the attributes of replication agreements. The documents MUST also define a standard method for determining the location of these agreements accessible utilizing LDAP. 7.3 The Replication Protocol documents MUST define standard schema for publishing state information about a given replica, and MUST define a standard method for determining the location of this information. 7.4 A location independent management point MUST be defined to provide authorized administrators with well known access to the replication policies, regardless of network location. 7.5 Replication agreements of all servers containing replicated information MUST be accessible via LDAP. 7.6 All objects MUST be uniquely identifiable throughout the object lifetime . 8. Administration and Management Considerations 8.1 Replication policies MUST allow replication of changed information to be administratively postponed to a more Weiser & Stokes 2 Febuary 2000 [Page 13] INTERNET-DRAFT LDAP Replication Requirements 2 August 2000 convenient period. 8.2 Allowance for non-scheduled replication of a replica MUST be provided upon request such that the replica server has been down or unconnected for a period of time. 8.3 Each copy of a replica MUST maintain audit history information of which servers it has replicated with and which servers have replicated with it. 8.4 A replica MUST store conflicted versions of the replicated object to allow optional human review and intervention. 8.5 Access to replication predetermined agreements, topologies, and policies attributes MUST be provided through LDAP access. 8.6 The capability to check the differences between two replicas for the same information SHOULD be provided for. This should entail a client invoking an operation at some server, which causes that server to extract the contents from some other server it has a replication agreement with and report the differences back to the client as the result. 8.7 Authenticated access SHOULD be provided so that Administrative LDAP clients may query a server for the current state and replication history for each replica that the server maintains replication agreements with. 8.8 The ability to view replication conflicts, and override the resolution derived by the replication policy MUST be provided. 8.9 The deletion of sensitive data MUST be handled in an orderly manner so that at no time will that data be available without proper access control. That is, access control information (ACI) associated with sensitive data must be deleted after or simultaneously with the delete of the sensitive data. Likewise, when adding sensitive data, ACI MUST be added first or simultaneously with the addition of that data. 9. Acknowledgement This document is based on input from IETF members interested in LDUP Replication. Weiser & Stokes 2 Febuary 2000 [Page 14] INTERNET-DRAFT LDAP Replication Requirements 2 August 2000 10. References [RFC2251] M. Wahl, T. Howes, S. Kille "Lightweight Directory Access Protocal", RFC 2251. [RFC2119] S.Bradner, " Key words for use in RFCs to indicate Requirement Levels", RFC 2119. [LDIF] Gordon Good, "The LDAP Data Interchange Format (LDIF)", Internet draft, draft-ietf-asid-ldif-00.txt, November 1996. [Changelog] Gordon Good, "Definitions of an Object Class to Hold LDAP Change records", Internet Draft, draft-ietf-asid-changelog- 00.txt, November 1996. [X.501] ITU-T Recommendation X.501 (1993), | ISO/IEC 9594-2: 1993, Information Technology - Open Systems Interconnection - The Directory: Models [XEROX] Hauser, C. "Managing update conflicts in Bayou, a weakly connected replicated storage system". Palo Alto, CA: Xerox PARC, Computer Science Laboratory; 1995 August; CSL-95-4. [CSL-95-04] 11. Author's Address Russel F. Weiser Digital Signature Trust Co. One South Main Street Salt Lake City, Utah 84111 USA E-mail: rweiser@digsigtrust.com Telephone: +1-801-246-4323 Fax +1-801-246-4361 Ellen J. Stokes IBM 11400 Burnet Rd. Austin, Texas 78758 USA E-mail: stokes@austin.ibm.com Telephone: +1-512-838-3725 Fax: +1-512-838-0156 Weiser & Stokes 2 Febuary 2000 [Page 15] --------------D1ABE676EA3E34B67276C6F0-- --------------ms347D56AF6855A69FE1F07227 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIJJwYJKoZIhvcNAQcCoIIJGDCCCRQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BtUwggbRMIIFuaADAgECAhEA0B5HMgAAAnwAAAAeAAAAhzANBgkqhkiG9w0BAQUFADCBqTEL MAkGA1UEBhMCdXMxDTALBgNVBAgTBFV0YWgxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MSQw IgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xETAPBgNVBAsTCERTVENBIFgx MRYwFAYDVQQDEw1EU1QgUm9vdENBIFgxMSEwHwYJKoZIhvcNAQkBFhJjYUBkaWdzaWd0cnVz dC5jb20wHhcNOTkxMjAyMjExNDA1WhcNMDAxMjAxMjExNDA1WjCBqTELMAkGA1UEBhMCVVMx DjAMBgNVBAcTBVNhbmR5MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4x GDAWBgNVBAMTD1J1c3NlbCBGIFdlaXNlcjEmMCQGCSqGSIb3DQEJARYXcndlaXNlckBkaWdz aWd0cnVzdC5jb20xIjAgBgoJkiaJk/IsZAEBExJEMDFFNDczMi4yN0MuMUUuODUwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBANNJxF7FlLKkJqiLe/bw62ipHRBk9ekpF/yiXtvMleoi GK0UR5uAe0z1Nze0di6YVSDFYkTks9K2mObkFIsqpRQc2D0om4po7AaQO+Z32ndUDvExySBa JXnDHuvwyCIsJHAf3CsSu4BVQsk3JKjR3AufGgeWljxIthSIJURTwupbAgMBAAGjggN0MIID cDCCAaMGA1UdIASCAZowggGWMIIBkgYJYIZIAYb5LwAAMIIBgzBSBggrBgEFBQcCARZGaHR0 cHM6Ly9zZWN1cmUuZGlnc2lndHJ1c3QuY29tL2RvY3MvcG9saWNpZXMvdHMvZHN0LWNwcy12 MTk5OTA4MjQuaHRtbDCCASsGCCsGAQUFBwICMIIBHRqCARlUaGUgdmFsdWUgb2YgdGhpcyBU cnVzdCBJRCBDZXJ0aWZpY2F0ZSwgaXRzIHJlbGlhbmNlIGxpbWl0LCBhbmQgdGhlIGxpYWJp bGl0eSBvZiB0aGUgaXNzdWVyIGFyZSBlc3RhYmxpc2hlZCBieSBjb250cmFjdCBhbmQgbGlt aXRlZCBieSBVdGFoIGxhdy4gIFRvIHJlYXNvbmFibHkgcmVseSBvbiB0aGlzIGNlcnRpZmlj YXRlLCB5b3UgbXVzdCBiZSBhbiBhdXRob3JpemVkIHJlbHlpbmcgcGFydHkgYW5kIHZhbGlk YXRlIGl0IGF0OiAgaHR0cHM6Ly9zZWN1cmUuZGlnc2lndHJ1c3QuY29tL3RzLjB8BgNVHR8E dTBzMHGgb6BthmtsZGFwOi8vbGRhcC5kaWdzaWd0cnVzdC5jb20vb3U9RFNUQ0EgWDEsbz1E aWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4sYz1VUz9jZXJ0aWZpY2F0ZVJldm9jYXRpb25M aXN0O2JpbmFyeTCCASwGCWCGSAGG+EIBDQSCAR0WggEZVGhlIHZhbHVlIG9mIHRoaXMgVHJ1 c3QgSUQgQ2VydGlmaWNhdGUsIGl0cyByZWxpYW5jZSBsaW1pdCwgYW5kIHRoZSBsaWFiaWxp dHkgb2YgdGhlIGlzc3VlciBhcmUgZXN0YWJsaXNoZWQgYnkgY29udHJhY3QgYW5kIGxpbWl0 ZWQgYnkgVXRhaCBsYXcuICBUbyByZWFzb25hYmx5IHJlbHkgb24gdGhpcyBjZXJ0aWZpY2F0 ZSwgeW91IG11c3QgYmUgYW4gYXV0aG9yaXplZCByZWx5aW5nIHBhcnR5IGFuZCB2YWxpZGF0 ZSBpdCBhdDogIGh0dHBzOi8vc2VjdXJlLmRpZ3NpZ3RydXN0LmNvbS90cy4wDAYDVR0TBAUw AwEBADALBgNVHQ8EBAMCA/gwDQYJKoZIhvcNAQEFBQADggEBAMVQtCJMFubri+P65pchiAwz VCJerrZNa9bNwWKn9mhvpgEIDUsZEkac3SyLu7P5rusv7ybWPvdpyORBqAZk/l8FGgwfyciB q/J/To9Rgp8fFD9W0rjsrjFRoObBP9hTgazGc4YpWP/893nrNkzwlH+CROVhOxHfFZSiYnhS +bGBrh+zDLusQ9b+M7+ikyxlFZulBnXhVytPdVKBkxse+vLotr7mCh4Hc3HMch6dmTwzUhLl KQo6rcNZ91sbfMLjLCQz3IrnEf4Rc52tEAMmVlG2p/ZlXjTT4aUlp8+igWGcLDZubL/0+fQj J9vBiYiUo9vHhGUNc9qSUl+QztkiDiwxggIaMIICFgIBATCBvzCBqTELMAkGA1UEBhMCdXMx DTALBgNVBAgTBFV0YWgxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MSQwIgYDVQQKExtEaWdp dGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xETAPBgNVBAsTCERTVENBIFgxMRYwFAYDVQQDEw1E U1QgUm9vdENBIFgxMSEwHwYJKoZIhvcNAQkBFhJjYUBkaWdzaWd0cnVzdC5jb20CEQDQHkcy AAACfAAAAB4AAACHMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMDAwODAzMTMwMjQ2WjAjBgkqhkiG9w0BCQQxFgQUHfDCcuzk6Xc+ z9gtqmd04xTW1sYwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEB BQAEgYBsHsWVM1RRbfnnjACUkgv8o7PiRUBrwosYQKtI+y72ZqMJrtAtI1ksTfTxt135hJgi ebcHM1viTxONNLAceIG4HdzFTeUF2WpYlwbQw1KzZ/b/I9zsNTajd8xLb8sNuZBxzqgEeFbF HG9kVUaOVbKGQIcogFYlfrz0ya58pjD1qA== --------------ms347D56AF6855A69FE1F07227-- From owner-ietf-ldup@mail.imc.org Thu Aug 3 11:22:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12320 for ; Thu, 3 Aug 2000 11:22:01 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA10950 for ietf-ldup-bks; Thu, 3 Aug 2000 07:34:19 -0700 (PDT) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA10944 for ; Thu, 3 Aug 2000 07:34:18 -0700 (PDT) Received: (qmail 16911 invoked from network); 3 Aug 2000 14:32:58 -0000 Received: from cpe-144-132-68-23.vic.bigpond.net.au (HELO w98sysrec) (144.132.68.23) by relay1.pair.com with SMTP; 3 Aug 2000 14:32:58 -0000 X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: "'Zachary Amsden'" Cc: , Subject: RE: 3. "Change Reports - ProtocolOps or Primitives" Date: Thu, 3 Aug 2000 21:49:38 +1000 Message-ID: <002d01bffd58$81481f00$17448490@vic.bigpond.net.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 CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <200008011949.AAA09592@mail.mirapoint.com> Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [Zachary] Replication out of sequence does not require a restart, as long as changes are presented in order per replica. I would highly recommend text stating that changes from each replica MUST be transmitted in strictly increasing CSN order. My current implementation stores and transmits changes from each replica separately, in CSN order. This makes implementation a lot easier for everyone. I don't see any problem with requiring this. [Albert] Simply requiring strict ordering of the sequence of changes from each *originator* replica would, as you say, be sufficient to avoid the wasted bandwidth from restarts problem. I'm not sure whether or not it would be sufficient for reducing the bandwidth spikes on full resynchronization problem. Either way, there are some major performance benefits to ALSO adding a local record/message sequence number (independent of originator sequence number except when the originator is the local replica, in which case it is identical), and maintaining *that* strict order. This does maintain the order from each originator but ALSO allows the exchange of a single "HighwaterMark" between replication neighbours, as used in the Coda/Active Directory protocols and proposed for report propagation in MDCR. The HighwaterMark has no global significance and is not needed either to avoid restarts or for the weeding/summarizing or purging mechanism. However it is useful between neighbours to enhance performance, and I suspect also to avoid a full resynchronization after failure. The specifics are implementation dependent. As I am not an implementor and not familiar with the full range of implementations, I am less clear on this than as regards standards and protocol algorithms. However here's an attempt to discuss some implementation issues as I understand them. There are currently two major types of implementations: 1) Log based, in which logs of local changes and updates from neighbour supplier replicas are appended sequentially and used to transmit them to neighbour consumers. 2) Entry based, in which local changes and updates from neighbour suppliers are stored with the corresponding entries. A scan of the entries is then used to select reports for replication to consumers for each replication session. I have the impression that there may be some sort of informal "design constraint", not explicitly mentioned in the requirements draft, that may have resulted in omitting ordering from the specification so as not to be any simpler to implement for log based implementations than for entry based ones. I am inclined to agree with you that there should be no problem for either type of implementation in requiring ordering. It is natural for log based implementations and just requires an index for entry based implementations. Active Directory is an example of an entry based implementation with such an index and seems to perform at least as well as Novell's. BTW Microsoft has published sponsored test results showing that it works several times faster. If Novell has published a reply or alternative test results, could someone please post a link (or better still, non-sponsored benchmarks independent of either). Unless that is done, I would assume that is conclusive evidence that there is no performance advantage in not ordering. There is also apparantly some confusion between "entry based" and "state based". A log based implementation would naturally store operations rather than states for local changes, and existing "Changelog" implementations derived from UMich LDAP servers do the same for replication. An "entry based" implementation could also be "state based" rather than operation based. But anything supporting signed operations, or maintaining atomicity as proposed in MDCR, would have to store operations. I see no reason why the primary key for that could not be entryID in an entry based implementation. For EITHER log based or entry based implementations, it seems to me natural to use a single key for maintaining the sorted order for receiving changes from suppliers and local DUAs and passing them on to consumers. That is what Active Directory does, using a local record/message sequence number as proposed in MDCR. It is state based (ie also entry based). An alternative is to use a global timestamp and not have a secondary key at all. As well as causing the problems we are agreed about, that strikes me as substantially less efficient internally. Unless there is some sort of index you would have to scan EVERY entry to check whether it is above the UpdatedMark of each consumer for each replication session, despite the fact that replication sessions are frequent and most entries are unchanged. By using a separate record/report number as either the log primary key for a log based implementation, or a secondary key for an entry based implementation, you can then use a HighWater mark for each neighbour consumer to drastically limit either the entries scanned or the starting point of a log scan. Then FROM that starting point, you transmit only the change reports that are above the UpdatedMark or vector for the particular consumer. This has no impact on bandwidth and restarts, since exactly the same reports, based on the consumer's UpdatedMarks or vector would be transmitted as without the HighwaterMark. But it is much less resource intensive for replication sessions internally. Separating this local record/report number from the originator report number is necessary for this sequencing. It also avoids the absurdity of relying on timestamps for originator sequencing despite clocks not even being monotonic. As mentioned in MDCR, it can also be used with a state based (non-atomic) protocol design to set an entry record sequence number as the maximum of the Attribute (Active Directory) and/or Attribute value (URP) sequence numbers of the entry, to further speed up processing. You *seem* to be indicating that you have a log based implementation, in which change reports are stored in separate logs for each originating replica and that it would therefore be convenient to transmit these logs in the same sequence to consumers. I can understand why separate logs might be used for the local changes and those from each *supplier*, but I do not understand the point of separate logs for each *originator*, since each replication session from a neighbour supplier would be a mixture of reports from several originators, who are not necessarily neighbours. With multiple logs, by simply adding a local record sequence number to each log record (sequential across logs as well as within them), you would be able to transmit the changes in the same sequence as received, by simply merging the logs as you transmit, without an extra sort, just as Active Directory is able to transmit them in that order despite being entry based (and in fact state based). >[Albert] >I agree that the number of bytes is a non-issue. As a separate matter, >allowing replication out of sequence requires a restart from the beginning >to ensure update vectors are synchronized whenever a replication session >is interrupted. That is most likely to happen on connection oriented links >where >bandwidth is most costly. > >I mentioned in email to Ed and will now repeat here, that this is especially >a problem for "sometimes connected" or dialup DSAs that may need to >interrupt >a "supplier push" session to a Hub from another dialup DSA in order to >obtain >a session for the same replicated area, given that only one consumer session >can be handled at a time by the Hub. > >Likewise, use of timestamps requires a full reload rather than incremental >to get back into sync after failures, which causes bandwidth spikes. > >Both of these "features" of the current architecture draft are not inherent >in URP but easily fixed. So far nothing has been done to fix them. From owner-ietf-ldup@mail.imc.org Thu Aug 3 11:22:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12434 for ; Thu, 3 Aug 2000 11:22:13 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA10942 for ietf-ldup-bks; Thu, 3 Aug 2000 07:34:12 -0700 (PDT) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA10938 for ; Thu, 3 Aug 2000 07:34:10 -0700 (PDT) Received: (qmail 16636 invoked from network); 3 Aug 2000 14:32:50 -0000 Received: from cpe-144-132-68-23.vic.bigpond.net.au (HELO w98sysrec) (144.132.68.23) by relay1.pair.com with SMTP; 3 Aug 2000 14:32:50 -0000 X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: "'Russel F Weiser'" , , , "'Ellen Stokes'" Subject: RE: draft-ietf-ldup-replica-req-04.txt Date: Fri, 4 Aug 2000 00:38:26 +1000 Message-ID: <002c01bffd58$7c78bca0$17448490@vic.bigpond.net.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 CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <39896D73.9C5FE92D@digsigtrust.com> Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit The attached document is 03 and has no significant differences from 02. Is that intentional? Now I'm REALLY curious as to the outcome of the Pittsburg discussion. Could somebody who was there PLEASE provide an unofficial description? -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Russel F Weiser Sent: Thursday, August 03, 2000 11:03 PM To: internet-drafts@ietf.org; ietf-ldup@imc.org; Ellen Stokes Subject: draft-ietf-ldup-replica-req-04.txt This is a updated version of the replication requirements document. requested by the LDUP working group to be updated. cheers RFW From owner-ietf-ldup@mail.imc.org Thu Aug 3 17:56:03 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24831 for ; Thu, 3 Aug 2000 17:56:02 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA28213 for ietf-ldup-bks; Thu, 3 Aug 2000 14:18:18 -0700 (PDT) Received: from mailgate1.austin.ibm.com (mg01.austin.ibm.com [192.35.232.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA28209 for ; Thu, 3 Aug 2000 14:18:15 -0700 (PDT) Received: from netmail.austin.ibm.com (netmail.austin.ibm.com [9.53.250.98]) by mailgate1.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA19718 for ; Thu, 3 Aug 2000 16:23:31 -0500 Received: from estokes (lig32-226-52-207.us.lig-dial.ibm.com [32.226.52.207]) by netmail.austin.ibm.com (8.8.5/8.8.5) with ESMTP id QAA61202; Thu, 3 Aug 2000 16:21:56 -0500 Message-Id: <4.2.2.20000803161625.00a3eba0@popmail2.austin.ibm.com> X-Sender: stokes@popmail2.austin.ibm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 03 Aug 2000 16:20:27 -0500 To: , "'Russel F Weiser'" , , From: Ellen Stokes Subject: RE: draft-ietf-ldup-replica-req-04.txt In-Reply-To: <002c01bffd58$7c78bca0$17448490@vic.bigpond.net.au> References: <39896D73.9C5FE92D@digsigtrust.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This was intentional because the current draft had expired and needed to be re-issused so it can be updated from people's comments. Ellen At 12:38 AM 8/4/00 +1000, Albert Langer wrote: >The attached document is 03 and has no significant differences from 02. > >Is that intentional? > >Now I'm REALLY curious as to the outcome of the Pittsburg discussion. > >Could somebody who was there PLEASE provide an unofficial description? > >-----Original Message----- >From: owner-ietf-ldup@mail.imc.org >[mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Russel F Weiser >Sent: Thursday, August 03, 2000 11:03 PM >To: internet-drafts@ietf.org; ietf-ldup@imc.org; Ellen Stokes >Subject: draft-ietf-ldup-replica-req-04.txt > > >This is a updated version of the replication requirements document. >requested by the LDUP working group to be updated. >cheers >RFW From owner-ietf-ldup@mail.imc.org Thu Aug 3 18:38:53 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07130 for ; Thu, 3 Aug 2000 18:38:52 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA02731 for ietf-ldup-bks; Thu, 3 Aug 2000 14:59:29 -0700 (PDT) Received: from mail.mirapoint.com (IDENT:mirapoint@mail.mirapoint.com [208.48.74.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA02727 for ; Thu, 3 Aug 2000 14:59:28 -0700 (PDT) Received: from mail.mirapoint.com (mail.mirapoint.com [192.168.0.18]) by mail.mirapoint.com (Mirapoint) with SMTP id AAA19274; Thu, 3 Aug 2000 15:03:14 -0700 (PDT) Message-Id: <200008032203.AAA19274@mail.mirapoint.com> Date: Thu, 3 Aug 2000 15:03:16 -0700 From: Zachary Amsden Subject: Re: more proposed protocol changes To: d.w.chadwick@salford.ac.uk Cc: ietf-ldup@imc.org 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 You are correct. That is why I explicitly specified that you would also need a semantical change, "under no circumstances should the update vector passed from a consumer to a supplier via a startReplicationResponse be interpreted as the current update vector of that consumer". Rather, it is an "update vector request". You can instead use the update vector returned from either a replicationUpdateResponse, or an endReplicationResponse. It actually makes more sense to use that value anyway, since you will need to commit that update vector as your known update vector for that consumer, since you need to have confirmation that the consumer has committed all the changes sent to it. In any case, I don't think it is necessary to actually forbid a consumer from taking having concurrent partial updates to the same replica, as it states in the architecture draft. ---- Original message ---- >Date: Thu, 3 Aug 2000 13:38:55 +0100 >From: "David Chadwick" >Subject: Re: more proposed protocol changes >To: Zachary Amsden , ietf-ldup@imc.org >Cc: > >Date sent: Mon, 31 Jul 2000 17:05:30 -0700 >From: Zachary Amsden >Subject: more proposed protocol changes >To: ietf-ldup@imc.org > >> To accomodate simultanaeous LDUP partial updates to >> the same replica, it would make sense to allow the sender to >> optionally send an update vector containing describing the >> CSNs it is about to send. This could be passed back to other >> suppliers for the same replica in the startReplicationResponse >> while the original replication is proceeding. > >Zachary > >I worry about this sort of procedure, since the consumer is saying >to the other suppliers that it has received the updates (from the first >supplier) before it actually has. Once these suppliers store that >update vector they will never attempt to update the consumer with >these updates. Worse than that, if the connection with the first >supplier breaks, the consumer now does not have the updates it >has told everyone (except the first supplier) that it does have. What >if the first supplier replicates with say the third supplier and gets the >update vector from it before it restarts it link to the consumer. The >first will now think that the consumer has the updates, wont it? > >David From owner-ietf-ldup@mail.imc.org Thu Aug 3 18:49:08 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10481 for ; Thu, 3 Aug 2000 18:49:07 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA02941 for ietf-ldup-bks; Thu, 3 Aug 2000 15:10:10 -0700 (PDT) Received: from mail.mirapoint.com (IDENT:mirapoint@mail.mirapoint.com [208.48.74.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA02937 for ; Thu, 3 Aug 2000 15:10:09 -0700 (PDT) Received: from mail.mirapoint.com (mail.mirapoint.com [192.168.0.18]) by mail.mirapoint.com (Mirapoint) with SMTP id AAA19321; Thu, 3 Aug 2000 15:13:38 -0700 (PDT) Message-Id: <200008032213.AAA19321@mail.mirapoint.com> Date: Thu, 3 Aug 2000 15:13:40 -0700 From: Zachary Amsden Subject: RE: 3. "Change Reports - ProtocolOps or Primitives" To: Albert.Langer@directory-designs.org Cc: steven.legg@adacel.com.au, ietf-ldup@imc.org 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 It is a log based implementation, where changes are stored in separate logs for each *originator*. *Originator* being an updatable replica with a known replica identifier. Thus one supplier may transmit data that gets recorded in several logs, demultiplexed based on the replicaID. The logs are naturally in strictly increasing CSN order because of the protocol design. This ordering is sufficient to establish a known update vector in the case of an interrupted transmission. Sorry about the terminology confusion. >You *seem* to be indicating that you have a log based implementation, in >which change reports are stored in separate logs for each originating >replica >and that it would therefore be convenient to transmit these logs in the >same sequence to consumers. I can understand why separate logs might be >used for the local changes and those from each *supplier*, but I do not >understand the point of separate logs for each *originator*, since each >replication session from a neighbour supplier would be a mixture of reports >from >several originators, who are not necessarily neighbours. From owner-ietf-ldup@mail.imc.org Fri Aug 4 03:53:30 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18912 for ; Fri, 4 Aug 2000 03:53:30 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA08399 for ietf-ldup-bks; Fri, 4 Aug 2000 00:13:21 -0700 (PDT) Received: from mail1.ecal.com ([216.150.139.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA08395 for ; Fri, 4 Aug 2000 00:13:20 -0700 (PDT) Received: from pacapple ([63.208.245.6]) by mail1.ecal.com (Post.Office MTA v3.5.2 release 221 ID# 30-55765U3000L300S0V35) with SMTP id com for ; Fri, 4 Aug 2000 03:16:54 -0400 Reply-To: From: capple@ecal.com (Christopher Apple) To: Subject: RE: draft-ietf-ldup-replica-req-04.txt Date: Fri, 4 Aug 2000 03:16:32 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01BFFDC2.63C83090" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <4.2.2.20000803161625.00a3eba0@popmail2.austin.ibm.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal 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_0000_01BFFDC2.63C83090 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Albert, As Ellen says, this was intentional. The document had to be re-published. The simplest thing to do was to rev the version number. It is supposed to be the same document as the -03- version. I wanted people to be able to look at *something* that was not located only in mailing list archives. Its not fair to expect people to do this when they should be able to go to the Internet Drafts repository to find a copy. Chris Apple capple@ecal.com -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Ellen Stokes Sent: Thursday, August 03, 2000 5:20 PM To: Albert.Langer@directory-designs.org; 'Russel F Weiser'; internet-drafts@ietf.org; ietf-ldup@imc.org Subject: RE: draft-ietf-ldup-replica-req-04.txt This was intentional because the current draft had expired and needed to be re-issused so it can be updated from people's comments. Ellen At 12:38 AM 8/4/00 +1000, Albert Langer wrote: >The attached document is 03 and has no significant differences from 02. > >Is that intentional? > >Now I'm REALLY curious as to the outcome of the Pittsburg discussion. > >Could somebody who was there PLEASE provide an unofficial description? > >-----Original Message----- >From: owner-ietf-ldup@mail.imc.org >[mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Russel F Weiser >Sent: Thursday, August 03, 2000 11:03 PM >To: internet-drafts@ietf.org; ietf-ldup@imc.org; Ellen Stokes >Subject: draft-ietf-ldup-replica-req-04.txt > > >This is a updated version of the replication requirements document. >requested by the LDUP working group to be updated. >cheers >RFW ------=_NextPart_000_0000_01BFFDC2.63C83090 Content-Type: text/x-vcard; name="Chris Apple.vcf" Content-Disposition: attachment; filename="Chris Apple.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Apple;Chris FN:Chris Apple NICKNAME:capple ORG:eCal Corporation TEL;WORK;VOICE:215-627-5001, ext. 3839 TEL;CELL;VOICE:(267) 977-8333 TEL;WORK;FAX:215-627-0927 ADR;WORK:;;510 Walnut Street;Philadelphia;PA;19106;US LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:510 Walnut = Street=3D0D=3D0APhiladelphia, PA 19106=3D0D=3D0AUS URL: URL:http://www.ecal.com EMAIL;PREF;INTERNET:capple@ecal.com REV:20000725T173628Z END:VCARD ------=_NextPart_000_0000_01BFFDC2.63C83090-- From owner-ietf-ldup@mail.imc.org Sat Aug 5 04:32:08 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07752 for ; Sat, 5 Aug 2000 04:32:08 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id AAA18578 for ietf-ldup-bks; Sat, 5 Aug 2000 00:54:59 -0700 (PDT) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA18571 for ; Sat, 5 Aug 2000 00:54:57 -0700 (PDT) Received: (qmail 22112 invoked from network); 5 Aug 2000 07:53:43 -0000 Received: from cpe-144-132-68-23.vic.bigpond.net.au (HELO w98sysrec) (144.132.68.23) by relay1.pair.com with SMTP; 5 Aug 2000 07:53:43 -0000 X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: "'Zachary Amsden'" Cc: , Subject: 10. "Report propagation sequence" Date: Sat, 5 Aug 2000 17:58:36 +1000 Message-ID: <000001bffeb2$f6634d40$17448490@vic.bigpond.net.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 CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200008032213.AAA19321@mail.mirapoint.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [Zachary] It is a log based implementation, where changes are stored in separate logs for each *originator*. *Originator* being an updatable replica with a known replica identifier. Thus one supplier may transmit data that gets recorded in several logs, demultiplexed based on the replicaID. The logs are naturally in strictly increasing CSN order because of the protocol design. This ordering is sufficient to establish a known update vector in the case of an interrupted transmission. Sorry about the terminology confusion. [Albert] This discussion started in: 3. "Change Reports - ProtocolOps or Primitives". http://www.imc.org/ietf-ldup/mail-archive/msg00664.html It is really a separate item, so I am changing the thread to: 10. "Report propagation sequence" and appending the whole of that section of the original to this, so that when Steve, Ed or others respond, they can also do so here. There was no terminology confusion as your explanation corresponds to what I thought your implementation was doing. What I did not understand in the paragraph you responded to, was *why* a log based implementation would choose to demultiplex the updates it consumes into separate logs for each originator replicaId. That is clearly not necessary in order to transmit updates in the same sequence that they are received, for each originator replicaId. You have still not explained what advantages it has. The paragraph you were responding to was included in a longer message repeated below. The first sentence agreed with you that your proposal to maintain the sequence only within each originator replicaID is sufficient to avoid any need for restarts (ie establishes a known update vector in the case of interrupted transmission). That of course assumes that the protocol design is changed to require *all* replicas to propagate changes from each originator in the same sequence that they are received, as you proposed. We are both agreed that such a change is necessary to avoid restarts, although so far nobody else has commented. (Steve has indicated that he is drafting some change to URP that may be related). However the remainder argued that as well as that design change, it is desirable to further require all replicas to propagate each update it receives (or local change), in the same sequence as they are received, regardless of originator. That necessarily maintains the sequencing within each originator but adds a stronger requirement NOT to demultiplex the updates consumed and then transmit the separate logs sequentially (or at least to merge them on transmission as though the implementation had never done so). We seem to be agreed that the sequencing in the current architecture should be changed, but you have proposed a different alternative sequencing to MDCR, without responding to my explanation below, of the advantages of the HighwaterMark enabled by the stronger sequencing in MDCR: http://www.ietf.org/internet-drafts/draft-langer-ldup-mdcr-00.txt At least one of us is confused now, possibly both, as you have responded only to the one part of my response that we seemed to be clear about and in agreement about. BTW, the terminology I am using is defined in MDCR, which is an alternative protocol design, not an implementation. I have now added terms to distinguish between "entry based" and "state based" (ie non-atomic) implementations as we are discussing implementation performance issues. My definitions have not been adopted by the WG, but I use them to try to avoid the confusion between originator changes and propagation updates inherent in the current architecture. Complete relevant sections of original messages follow: *** [Steve] I regard efficiency on the wire as largely a non-issue for replication. My experience with X.525/DISP is that supplier DSAs can pump changes through to consumers at least an order of magnitude faster than the consumers can process them. A super efficient LDUP protocol won't make much overall difference. [Albert] I agree that the number of bytes is a non-issue. As a separate matter, allowing replication out of sequence requires a restart from the beginning to ensure update vectors are synchronized whenever a replication session is interrupted. That is most likely to happen on connection oriented links where bandwidth is most costly. I mentioned in email to Ed and will now repeat here, that this is especially a problem for "sometimes connected" or dialup DSAs that may need to interrupt a "supplier push" session to a Hub from another dialup DSA in order to obtain a session for the same replicated area, given that only one consumer session can be handled at a time by the Hub. Likewise, use of timestamps requires a full reload rather than incremental to get back into sync after failures, which causes bandwidth spikes. Both of these "features" of the current architecture draft are not inherent in URP but easily fixed. So far nothing has been done to fix them. Unlike the number of bytes in the syntax, they would have a significant impact on bandwidth requirements. [Zachary] Replication out of sequence does not require a restart, as long as changes are presented in order per replica. I would highly recommend text stating that changes from each replica MUST be transmitted in strictly increasing CSN order. My current implementation stores and transmits changes from each replica separately, in CSN order. This makes implementation a lot easier for everyone. I don't see any problem with requiring this. [Albert] Simply requiring strict ordering of the sequence of changes from each *originator* replica would, as you say, be sufficient to avoid the wasted bandwidth from restarts problem. I'm not sure whether or not it would be sufficient for reducing the bandwidth spikes on full resynchronization problem. Either way, there are some major performance benefits to ALSO adding a local record/message sequence number (independent of originator sequence number except when the originator is the local replica, in which case it is identical), and maintaining *that* strict order. This does maintain the order from each originator but ALSO allows the exchange of a single "HighwaterMark" between replication neighbours, as used in the Coda/Active Directory protocols and proposed for report propagation in MDCR. The HighwaterMark has no global significance and is not needed either to avoid restarts or for the weeding/summarizing or purging mechanism. However it is useful between neighbours to enhance performance, and I suspect also to avoid a full resynchronization after failure. The specifics are implementation dependent. As I am not an implementor and not familiar with the full range of implementations, I am less clear on this than as regards standards and protocol algorithms. However here's an attempt to discuss some implementation issues as I understand them. There are currently two major types of implementations: 1) Log based, in which logs of local changes and updates from neighbour supplier replicas are appended sequentially and used to transmit them to neighbour consumers. 2) Entry based, in which local changes and updates from neighbour suppliers are stored with the corresponding entries. A scan of the entries is then used to select reports for replication to consumers for each replication session. I have the impression that there may be some sort of informal "design constraint", not explicitly mentioned in the requirements draft, that may have resulted in omitting ordering from the specification so as not to be any simpler to implement for log based implementations than for entry based ones. I am inclined to agree with you that there should be no problem for either type of implementation in requiring ordering. It is natural for log based implementations and just requires an index for entry based implementations. Active Directory is an example of an entry based implementation with such an index and seems to perform at least as well as Novell's. BTW Microsoft has published sponsored test results showing that it works several times faster. If Novell has published a reply or alternative test results, could someone please post a link (or better still, non-sponsored benchmarks independent of either). Unless that is done, I would assume that is conclusive evidence that there is no performance advantage in not ordering. There is also apparantly some confusion between "entry based" and "state based". A log based implementation would naturally store operations rather than states for local changes, and existing "Changelog" implementations derived from UMich LDAP servers do the same for replication. An "entry based" implementation could also be "state based" rather than operation based. But anything supporting signed operations, or maintaining atomicity as proposed in MDCR, would have to store operations. I see no reason why the primary key for that could not be entryID in an entry based implementation. For EITHER log based or entry based implementations, it seems to me natural to use a single key for maintaining the sorted order for receiving changes from suppliers and local DUAs and passing them on to consumers. That is what Active Directory does, using a local record/message sequence number as proposed in MDCR. It is state based (ie also entry based). An alternative is to use a global timestamp and not have a secondary key at all. As well as causing the problems we are agreed about, that strikes me as substantially less efficient internally. Unless there is some sort of index you would have to scan EVERY entry to check whether it is above the UpdatedMark of each consumer for each replication session, despite the fact that replication sessions are frequent and most entries are unchanged. By using a separate record/report number as either the log primary key for a log based implementation, or a secondary key for an entry based implementation, you can then use a HighWater mark for each neighbour consumer to drastically limit either the entries scanned or the starting point of a log scan. Then FROM that starting point, you transmit only the change reports that are above the UpdatedMark or vector for the particular consumer. This has no impact on bandwidth and restarts, since exactly the same reports, based on the consumer's UpdatedMarks or vector would be transmitted as without the HighwaterMark. But it is much less resource intensive for replication sessions internally. Separating this local record/report number from the originator report number is necessary for this sequencing. It also avoids the absurdity of relying on timestamps for originator sequencing despite clocks not even being monotonic. As mentioned in MDCR, it can also be used with a state based (non-atomic) protocol design to set an entry record sequence number as the maximum of the Attribute (Active Directory) and/or Attribute value (URP) sequence numbers of the entry, to further speed up processing. You *seem* to be indicating that you have a log based implementation, in which change reports are stored in separate logs for each originating replica and that it would therefore be convenient to transmit these logs in the same sequence to consumers. I can understand why separate logs might be used for the local changes and those from each *supplier*, but I do not understand the point of separate logs for each *originator*, since each replication session from a neighbour supplier would be a mixture of reports from several originators, who are not necessarily neighbours. With multiple logs, by simply adding a local record sequence number to each log record (sequential across logs as well as within them), you would be able to transmit the changes in the same sequence as received, by simply merging the logs as you transmit, without an extra sort, just as Active Directory is able to transmit them in that order despite being entry based (and in fact state based). From owner-ietf-ldup@mail.imc.org Sat Aug 5 19:55:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17751 for ; Sat, 5 Aug 2000 19:55:34 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA06629 for ietf-ldup-bks; Sat, 5 Aug 2000 16:25:08 -0700 (PDT) Received: from infidel.boolean.net (root@router.boolean.net [198.144.206.49]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA06625 for ; Sat, 5 Aug 2000 16:25:06 -0700 (PDT) Received: from gypsy.OpenLDAP.org (root@infidel.boolean.net [198.144.202.225]) by infidel.boolean.net (8.9.3/8.9.3) with ESMTP id XAA33717; Sat, 5 Aug 2000 23:28:41 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <4.3.2.7.0.20000805152931.00bc9320@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 05 Aug 2000 16:27:43 -0700 To: "Ed Reed" From: "Kurt D. Zeilenga" Subject: Re: controlling visability of subentries 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 06:50 AM 8/2/00 -0600, Ed Reed wrote: >Now - should I specify a new control, or use one someone else already >has defined? Suggestions appreciated. I would suggest the control have a syntax similar to ManageDsaIT control defined by draft-ietf-ldapext-refer-00.txt (or draft-zeilenga-ldap-nameref-00.txt) but with semantics of the X.511 ServiceControls "subentries" option [X.511(97) 5.7f]. Kurt From owner-ietf-ldup@mail.imc.org Sat Aug 5 19:56:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17823 for ; Sat, 5 Aug 2000 19:56:07 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA06635 for ietf-ldup-bks; Sat, 5 Aug 2000 16:26:17 -0700 (PDT) Received: from infidel.boolean.net (root@router.boolean.net [198.144.206.49]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA06631 for ; Sat, 5 Aug 2000 16:26:16 -0700 (PDT) Received: from gypsy.OpenLDAP.org (root@infidel.boolean.net [198.144.202.225]) by infidel.boolean.net (8.9.3/8.9.3) with ESMTP id XAA33737 for ; Sat, 5 Aug 2000 23:30:15 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <4.3.2.7.0.20000804161734.00b0cc40@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 05 Aug 2000 16:28:58 -0700 To: ietf-ldup@imc.org From: "Kurt D. Zeilenga" Subject: Framing/Grouping Issues 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: Roger, Ellen, and I discussed combining draft-ietf-ldup-framing-00.txt and draft-zeilenga-ldap-grouping-00.txt into one specification. The former provides a framing mechanism (all operations between the start and end belong to a frame) where the former offers a grouping mechanism [all operations tagged with a "cookie" control belong to a group]. We agreed that there were uses for both framing and grouping and we agreed to create a combined I-D which supported both styles. The style would be prescribed by the OID associated with the frame/group type (along with other semantics). If you have concerns regarding this "combined" or "dual" framing/grouping approach, please voice them ASAP. Also, we discussed the addition of "manage" frame/group operation (no management semantics are defined). We agreed to add this as well. If you have concerns regarding this addition, please voice them ASAP. Kurt From owner-ietf-ldup@mail.imc.org Sat Aug 5 22:45:36 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14272 for ; Sat, 5 Aug 2000 22:45:36 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA15804 for ietf-ldup-bks; Sat, 5 Aug 2000 19:15:49 -0700 (PDT) Received: from infidel.boolean.net (root@router.boolean.net [198.144.206.49]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA15800 for ; Sat, 5 Aug 2000 19:15:48 -0700 (PDT) Received: from gypsy.OpenLDAP.org (root@infidel.boolean.net [198.144.202.225]) by infidel.boolean.net (8.9.3/8.9.3) with ESMTP id CAA34242; Sun, 6 Aug 2000 02:19:43 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <4.3.2.7.0.20000805182150.00afb590@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 05 Aug 2000 19:19:23 -0700 To: From: "Kurt D. Zeilenga" Subject: RE: reconciliation of mutually exclusive operations Cc: In-Reply-To: <000c01bffbd9$b71bf140$17448490@vic.bigpond.net.au> References: <4.3.2.7.0.20000801090655.00b62840@router.boolean.net> 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 agree that multi-master replication will break any and all implementations which rely on X.500/LDAP data consistency properties. Though I agree multi-master replication is useful in many applications of the directory, so is tight data consistency. Minimally, some means must be provided to allow clients to discover the consistency properties offered. However, existing clients which rely on existing consistency properties would have to be redesigned to use this discovery mechanism. I believe LDUP WG should specifically address this and related issues in requirements document. Kurt From owner-ietf-ldup@mail.imc.org Sun Aug 6 00:56:38 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05594 for ; Sun, 6 Aug 2000 00:56:38 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id VAA22309 for ietf-ldup-bks; Sat, 5 Aug 2000 21:26:32 -0700 (PDT) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA22305 for ; Sat, 5 Aug 2000 21:26:31 -0700 (PDT) Received: (qmail 16481 invoked from network); 6 Aug 2000 04:25:19 -0000 Received: from cpe-144-132-68-23.vic.bigpond.net.au (HELO w98sysrec) (144.132.68.23) by relay1.pair.com with SMTP; 6 Aug 2000 04:25:19 -0000 X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: "'Kurt D. Zeilenga'" , Subject: RE: Framing/Grouping Issues Date: Sun, 6 Aug 2000 14:30:18 +1000 Message-ID: <000001bfff5f$077753e0$17448490@vic.bigpond.net.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 CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <4.3.2.7.0.20000804161734.00b0cc40@router.boolean.net> Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [Kurt...] We agreed that there were uses for both framing and grouping and we agreed to create a combined I-D which supported both styles. The style would be prescribed by the OID associated with the frame/group type (along with other semantics). If you have concerns regarding this "combined" or "dual" framing/grouping approach, please voice them ASAP. Also, we discussed the addition of "manage" frame/group operation (no management semantics are defined). We agreed to add this as well. If you have concerns regarding this addition, please voice them ASAP. [Albert] Currently, the semantics of: http://search.ietf.org/internet-drafts/draft-zeilenga-ldap-grouping-00.txt are as follows: *** 5. Operational Semantics This section needs work. *** When there is something in between the first and last line, (even though the last line is still there), please ask again. This "first call" for a draft that hasn't been written is a bit like a final call for a draft that has been deleted ;-) The wonderful thing about ASN is that one can write out the syntax of a protocol so much more easily than with those horrible "packet formats" and ABNF specs. The whole point of that is to avoid focus on relatively trivial syntax issues and get straight down to the actual protocol. But one still needs some semantics before there actually is a protocol, so that one can even begin to discuss it. Semantics = meaning. The draft currently has no meaning, therefore the question has no meaning. If for example, either a framing or a grouping or a combined framing/grouping protocol was used to transmit "primitives" of an LADP modify operation between replicas it could, just conceivably, distract the attention of a WG from the fact that it has not defined a protocol that preserves the operational semantics of the LDAP change operation. No matter how unlikely that may seem, I can think of an example, not a million miles from here. It could get even worse if somebody were to imagine that by specifying the syntax for applying a set of operations to a set of entries, they have either solved, or made any contribution towards solving, the problems of actually applying that set of operations to that set of entries in a single server system, let alone a multi-master system. Ditto of course for the management of such a system. I am concerned about standardised, combined meaninglessness ;-) Yes, I do understand that a common syntax could be useful as a general framework for many different types of grouping and framing, each with their own specific semantics, and that the approach in this draft of simply adding a cookie could well be common to all. But I'd still like to see concrete example protocols before determining what is common to them. For example it may well be that protocols which require nested groupings (5.1.5) have common requirements for the general framework to carry additional information related to the restrictions on the types of groups being nested and the sequence within which they are to be processed. On the other hand, it may well be that simple framing, or even simple nested framing, does not require a standard at all, since specifying it for any protocol that needs it is just an ordinary use of the built in SEQUENCE and SET facilities of ASN. BTW Please take a close look at the (incomplete) protocol spec in MDCR. It deals with treating a set of operations at different replicas applied to the same entry as a single group with convergence to a common outcome. It turned out to require carrying details of the tree structure of those operations in the protocol. Just ensuring that they do reach a common outcome required two separate sequence numbers, a version number and an originator identifier. Once you consider that there may be more than one grouped operation attempted (even at a single replica), against overlapping different sets of entries, you are essentially dealing with "multi-DUA client operations" of very similar complexity to "multi-master DSA replication" (for very similar reasons - DUAs are independently and concurrently acting on the same data). This is a HARD problem, even when not combining both aspects. That is why neither transactions nor multi-master have been standardized up to now. It doesn't get any simpler by defining a simple syntax. It may become necessary for the protocol syntax to include for example reference to a set of cookies of those other grouped operations that the DUA is participating in or aware of, so that the server(s) can determine whether any overlap is an actual conflict or a recursive nesting. From owner-ietf-ldup@mail.imc.org Sun Aug 6 01:59:06 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29356 for ; Sun, 6 Aug 2000 01:59:05 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id WAA24425 for ietf-ldup-bks; Sat, 5 Aug 2000 22:29:05 -0700 (PDT) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA24420 for ; Sat, 5 Aug 2000 22:29:03 -0700 (PDT) Received: (qmail 17958 invoked from network); 6 Aug 2000 05:27:54 -0000 Received: from cpe-144-132-68-23.vic.bigpond.net.au (HELO w98sysrec) (144.132.68.23) by relay1.pair.com with SMTP; 6 Aug 2000 05:27:54 -0000 X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: "'Kurt D. Zeilenga'" Cc: Subject: RE: reconciliation of mutually exclusive operations Date: Sun, 6 Aug 2000 15:32:56 +1000 Message-ID: <000301bfff67$c6c0c620$17448490@vic.bigpond.net.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 CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <4.3.2.7.0.20000805182150.00afb590@router.boolean.net> Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [Kurt] I agree that multi-master replication will break any and all implementations which rely on X.500/LDAP data consistency properties. Though I agree multi-master replication is useful in many applications of the directory, so is tight data consistency. Minimally, some means must be provided to allow clients to discover the consistency properties offered. However, existing clients which rely on existing consistency properties would have to be redesigned to use this discovery mechanism. I believe LDUP WG should specifically address this and related issues in requirements document. [Albert] Needless to say I agree this should be addressed in requirements, which of course requires addressing the related issue of what the consistency properties to be discovered actually are ;-) I would still love to see an unofficial description of how the discussion on this went, while waiting for the official minutes. Your minimal requirement is partially met by the existence of multi-master specific subentries and a pointer to their existence from the DSA root entry, as this can easily be discovered by clients that are aware of the need to look. To add more than that, I guess one could add something to the bind response. But if the client is already aware of the possibility, it could just look at the existence of the subentries, so this would only be a minor performance enhancement, not a solution to the problem of clients not knowing what they are up against. For existing clients, any such response MUST NOT cause the client to fail as a result of not understanding it. Therefore it MUST be ignored by clients that do not understand it. So, as you point out, it does not actually help solve the problem. Since existing clients, by definition, have NOT been redesigned for multi-master when it is first introduced, I believe the only solution is to send a notification to the email address of any DUA that is given a "success response" which turns out to be incorrect after eventual convergence, unless this has been explicitly turned off (or redirected) by the client, using either an attribute value in the DUA's entry or a control in the bind or the operation request. Note that DUA administrators can turn this off via the DUA entry (and DUAs users can overide the setting either way with explicit controls in the bind or in individual change operations). However there is intentionally NO facility for a replica DSA administrator to turn it off, or not implement it, for DUAs using that replica generally. That is necessary because DUAs cannot be assumed to know the replication configuration of DSAs they get referred to from other DSAs outside a replication area. This is proposed in MDCR, with the necessary machinery to be able to retain the information needed for such notifications. It still has the unsatisfactory result of giving a "success" response that isn't necessarily correct, but it sends a notice ONLY when there is an actual conflict, which should be only for a small proportion of writes, which are only for a small proportion of directory operations. In practice the occurrence of such notifications only draws attention to the fact that multi-master is being used inappropriately, but that does meet the "minimal" requirement. By adding support for confirmations, and integration of non-email notifications with LCUP, real enhanced support can be given to future enhanced clients. With single master, another DUA could of course change the entry immediately afterwards, or between reading an entry and writing a change to it based on that read. Also a DSA could crash just after sending a "success" response and before backup or replication. Once multi-master does maintain atomicity, the problem is simply that such conflict between what DUAs write and what they actually get will be more frequent than with single master, whereas most current applications expect it to hardly ever happen at all. I believe the email notification in MDCR is both necessary and sufficient as a mandatory requirement. Do you agree? PS The current vaguely mentioned approach, is for DUAs to use only the "primary" for operations that require tighter consistency, with no actual mechanism specified to ensure this. Any such mechanism cannot meet this requirement unless it also shuts out DUAs attempting to use any other replica, since existing DUAs are by definition unaware of the mechanism. Shutting them out would of course amount to single master. (There is no concept of DUA specific access controls in ACL standards). I am doubtful that this concept of a "primary" has any value at all (though it may help when attempting grouping or transactions for multiple entries). If and when a mechanism is actually proposed, it could perhaps be integrated with the notifications via options in the controls and DUA settings to generate or suppress a notification only if the replica was bound to a non-primary. There would in fact be no conflicts and therefore no notifications if all the concurrent operations affecting an entry were IN FACT directed to a single replica, *whether or not* that replica is officially designated as a "primary", so I cannot see much actual use for such suppression, but am just mentioning it because it appears that *somebody* must believe "primaries" are somehow relevant to these issues. From owner-ietf-ldup@mail.imc.org Mon Aug 7 09:20:29 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05361 for ; Mon, 7 Aug 2000 09:20:28 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA18211 for ietf-ldup-bks; Mon, 7 Aug 2000 05:44:04 -0700 (PDT) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA18207 for ; Mon, 7 Aug 2000 05:43:59 -0700 (PDT) Received: (qmail 29791 invoked from network); 7 Aug 2000 12:42:53 -0000 Received: from cpe-144-132-68-23.vic.bigpond.net.au (HELO w98sysrec) (144.132.68.23) by relay1.pair.com with SMTP; 7 Aug 2000 12:42:53 -0000 X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: "'Zachary Amsden'" , Cc: Subject: RE: more proposed protocol changes Date: Mon, 7 Aug 2000 22:47:59 +1000 Message-ID: <000501c0006d$b82a7780$17448490@vic.bigpond.net.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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <200008032203.AAA19274@mail.mirapoint.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [Zachary...] In any case, I don't think it is necessary to actually forbid a consumer from taking having concurrent partial updates to the same replica, as it states in the architecture draft. [Albert] The architecture draft may have been written with the assumption that allowing a consumer to take concurrent updates for the same replica would not work because there was no ordering. It MIGHT be possible to allow this when updates are ordered. However you would need to carefully consider what happens in triangular situations etc. If it is possible, the exact method would need to be fully specified rather than just changing MUST NOT to MAY. Note that that even without allowing concurrent update sessions, accepting updates from more than one upstream master is what makes X.500 DISP complicated to implement, despite having a single master further upstream. It would certainly be useful if this restriction could be removed since it severely complicates scheduling. I suspect it cannot be as Active Directory uses ordered updates but has that restriction. If you believe it can be, please draft an explicit mechanism with a semi-formal proof that the update vectors and purge mechanism works correctly, including triangular situations. From owner-ietf-ldup@mail.imc.org Mon Aug 7 15:28:40 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14462 for ; Mon, 7 Aug 2000 15:28:39 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA01835 for ietf-ldup-bks; Mon, 7 Aug 2000 11:48:25 -0700 (PDT) Received: from mail.mirapoint.com (IDENT:mirapoint@mail.mirapoint.com [208.48.74.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA01830 for ; Mon, 7 Aug 2000 11:48:24 -0700 (PDT) Received: from mail.mirapoint.com (localhost.mirapoint.com [127.0.0.1]) by mail.mirapoint.com (Mirapoint) with SMTP id AAA01814; Mon, 7 Aug 2000 11:52:05 -0700 (PDT) Message-Id: <200008071852.AAA01814@mail.mirapoint.com> Received: from 127.0.0.1 by mail.mirapoint.com with HTTPS/1.1; Mon, 7 Aug 2000 11:52:05 -0700 Date: Mon, 7 Aug 2000 11:52:05 -0700 From: Zachary Amsden Subject: Re: 10. "Report propagation sequence" To: Albert.Langer@directory-designs.org Cc: "'Zachary Amsden'" , steven.legg@adacel.com.au, ietf-ldup@imc.org X-Mailer: Mirapoint Webmail Direct 2.7.0.22 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 I'm not sure what benefit the high water mark gives you, if you have separate logs from each supplier, as opposed to logs from each originator. To transmit the minimal set of changes, you need to perform an on the fly merge of each supplier log, so you need a high water mark for each supplier log. You could do this just as easily if the logs were demultiplexed into separate logs for each replica ID, you just keep a pointer into each CSN log. Having the logs muxed by replica ID, and sorted by CSN I think is easier for purging obsolete changes. With separate supplier logs, purging would be much more difficult. Since you don't know ahead of time what CSNs are in which list, you may need to scan every entry just to get rid of the changes. Zach >10. "Report propagation sequence" > >and appending the whole of that section of the original to this, so that >when Steve, Ed or others respond, they can also do so here. > >There was no terminology confusion as your explanation corresponds to >what I thought your implementation was doing. What I did not understand >in the paragraph you responded to, was *why* a log based >implementation would choose to demultiplex the updates it >consumes into separate logs for each originator replicaId. > >That is clearly not necessary in order to transmit updates in the >same sequence that they are received, for each originator replicaId. >You have still not explained what advantages it has. From owner-ietf-ldup@mail.imc.org Tue Aug 8 00:45:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27690 for ; Tue, 8 Aug 2000 00:45:43 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA07932 for ietf-ldup-bks; Mon, 7 Aug 2000 16:52:51 -0700 (PDT) Received: from mail.mirapoint.com (IDENT:mirapoint@mail.mirapoint.com [208.48.74.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA07928 for ; Mon, 7 Aug 2000 16:52:51 -0700 (PDT) Received: from mail.mirapoint.com (localhost.mirapoint.com [127.0.0.1]) by mail.mirapoint.com (Mirapoint) with SMTP id AAA03163; Mon, 7 Aug 2000 16:56:48 -0700 (PDT) Message-Id: <200008072356.AAA03163@mail.mirapoint.com> Received: from 127.0.0.1 by mail.mirapoint.com with HTTPS/1.1; Mon, 7 Aug 2000 16:56:49 -0700 Date: Mon, 7 Aug 2000 16:56:49 -0700 From: Zachary Amsden Subject: RE: 10. "Report propagation sequence" To: Albert.Langer@Directory-Designs.org Cc: "'Zachary Amsden'" , steven.legg@adacel.com.au, ietf-ldup@imc.org X-Mailer: Mirapoint Webmail Direct 2.7.0.22 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 >[Albert] >Likewise there is no difficulty for *any* entry based >implementation in simply maintaining an index of entries by >local record sequence number. > >Therefore I argue that adding a local record sequence number to >enable propagating updates in strict order and using >HighwaterMarks between neighbours should be the architectural >change, rather than only requiring strict ordering within each >originator replicaId. > >Do you now agree? Yes, adding a local sequence number merely requires an in order merge for a log based implementation, and this will be efficient enough when using HighwaterMarks. I would propose instead though for an ordering requirement: propagating updates in strictly increasing CSN order for each replica ID. Note that this does not impose the constraint that we must cycle through each replica, and send all changes from that replica before sending changes from another. It does not forbid it either. So an entry based implementation could simply transmit changes in the order received, and a log based could transmit in-order by replicaID. Both of these transmit orders must produce the same result state for the database, because they can both happen naturally (unless our URP rules are horribly broken). What initially brought me to this discussion was a quite different idea, though. What really worried me about the current phrasing of the draft was the fact that no ordering requirements were made at all within a transmission. This causes severe problems when a replication update is interrupted. I'm not so much worried about bandwidth, but the following scenario: Replica A sends a very long partial update to replica B. Somewhere in the middle of the transfer, the connection is terminated. Since we can get CSNs out of order within a replica ID, we have three options: 1) Save all changes until the transfer is complete, then commit them and send an end replication response. This still worries me because committing the changes may take a very long time, during which our peer may decide we are dead, and drop the connection. 2) Commit changes as we get them. Very problematic, since there is nothing prohibiting LDAP updates to our local replica while we are in a replication session. So when the connection dies, we have no idea what the current update vector for our replica is, and we can't easily back out changes because we may have received updates. 3) Lock down our local replica from updates during the replication process. For some LDAP applications, this will not be an option. We may not know which replica to send update referrals too, or our clients may not be able to chase referrals for any number of reasons. Not only this, but if the connection does die, we can't allow updates until replication is re-established with the same supplier, or we revert all the changes and restore to a known state. Since there isn't actually enough information in a change record to undo the change, any server crash during this process is rather disastrous. This means we need to store a reverse operation for each change as well. These are the kind of warts I would like to avoid in the LDUP protocol. Zach From owner-ietf-ldup@mail.imc.org Tue Aug 8 00:45:45 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27701 for ; Tue, 8 Aug 2000 00:45:45 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA06865 for ietf-ldup-bks; Mon, 7 Aug 2000 15:39:28 -0700 (PDT) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA06857 for ; Mon, 7 Aug 2000 15:39:23 -0700 (PDT) Received: (qmail 19648 invoked from network); 7 Aug 2000 22:38:16 -0000 Received: from cpe-144-132-68-23.vic.bigpond.net.au (HELO w98sysrec) (144.132.68.23) by relay1.pair.com with SMTP; 7 Aug 2000 22:38:16 -0000 X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: "'Zachary Amsden'" Cc: , Subject: RE: 10. "Report propagation sequence" Date: Tue, 8 Aug 2000 08:43:31 +1000 Message-ID: <000a01c000c0$ea222140$17448490@vic.bigpond.net.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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <200008071852.AAA01814@mail.mirapoint.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [Zach] I'm not sure what benefit the high water mark gives you, if you have separate logs from each supplier, as opposed to logs from each originator. To transmit the minimal set of changes, you need to perform an on the fly merge of each supplier log, so you need a high water mark for each supplier log. You could do this just as easily if the logs were demultiplexed into separate logs for each replica ID, you just keep a pointer into each CSN log. [Albert] My understanding is that propagation is relatively simple for log based implementations, but an issue for entry based implementations. The HighwaterMark is primarily for the benefit of entry based implementations. According to the current architecture draft: 10.3.2 State-Based Implementation A state-based implementation might consider each entry of the replica in turn using the Update Vector of the consumer to find all the state changes that need to be transferred. While an implementation "might" do that, it would be grossly inefficient AND result in transmitting updates out of order, with the resulting problems we agree about. The HighwaterMark enables an entry based implementation (whether "state based" or not) to simply maintain an index in local record sequence number, and start the scan from the least of the HighwaterMarks of the consumers it is currently supplying. I agree that this can be done just as easily without a HighwaterMark when logs are demultiplexed by originator replicaId. My point is that for *any* log based implementation, there would be no difficulty just adding a local record sequence number and appending to the log(s) in that sequence. The HighwaterMarks would then be used as a pointer into each log in exactly the same way that you would use the Updated vector (but would be equally applicable for a single common log, or logs based on supplier rather than originator, so there is no need for demultiplexing by originator for propagation). Likewise there is no difficulty for *any* entry based implementation in simply maintaining an index of entries by local record sequence number. Therefore I argue that adding a local record sequence number to enable propagating updates in strict order and using HighwaterMarks between neighbours should be the architectural change, rather than only requiring strict ordering within each originator replicaId. Do you now agree? [Zach] Having the logs muxed by replica ID, and sorted by CSN I think is easier for purging obsolete changes. With separate supplier logs, purging would be much more difficult. Since you don't know ahead of time what CSNs are in which list, you may need to scan every entry just to get rid of the changes. [Albert] Thanks. That answers my question and I believe I now understand why a log based implementation might choose to demultiplex logs based on orginator replica Id - it is useful for purging rather than propagation. The local record/message numbers and HighwaterMark I am proposing are not relevant to purging at all, but only used to speed up internal processing for propagation. My impression is that the difficulty you mention is a major problem for entry based implementations, which may motivate the desire to impose a non-atomic model on LDUP, and hence on LDAP, so that they can be "state based" rather than just "entry based", while still purporting to be LDAP servers. If revised LDUP requirements do not attempt to change the LDAP/X.500 model to suit their desires (or if LDUP is rejected as an IETF standard as a result of unsuccessfully attempting to do so), it will still be necessary to accommodate more legitimate vendor concerns about the performance impact on their entry based implementations as far as that can possibly be done without breaking the existing standardized LDAP/X.500 data model. My understanding is that a major "advantage" of "state based" implementations is that they can essentially avoid the issue of log purging entirely, as they retain only the current entry state and have no logs to purge. eg Active Directory recommends a default deleted entry "tombstone" lifetime of something like 60 or 90 days and seems to have no other purge mechanism. That "advantage" comes at an unacceptable cost of breaking the LDAP/X.500 data model, so when insisting on retaining the current data model expected by applications it is necessary to carefully consider the purging mechanisms. Any replication protocol that maintains atomicity has to retain some kind of additional "history" information rather than just current "state". For log based implementations that is not a problem. For entry based implementations, I have tried to show in MDCR that it would not be a problem either, as only the minimal pointers into the logs necessary to maintain the tree structured history would need to be maintained in RAM, with a guesstimated overhead of only about 12 bytes per concurrent unsummarized update. "Purging", or weeding and summarizing as in MDCR, can then be easily done for the disk records in batch mode outside peak periods without affecting the performance advantages of the multiple worker threads used with more sophisticated databases in entry based implementations. From owner-ietf-ldup@mail.imc.org Tue Aug 8 09:13:56 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02831 for ; Tue, 8 Aug 2000 07:30:14 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA00505 for ietf-ldup-bks; Mon, 7 Aug 2000 23:14:41 -0700 (PDT) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA00499 for ; Mon, 7 Aug 2000 23:14:39 -0700 (PDT) Received: (qmail 5921 invoked from network); 8 Aug 2000 06:13:30 -0000 Received: from cpe-144-132-68-23.vic.bigpond.net.au (HELO w98sysrec) (144.132.68.23) by relay1.pair.com with SMTP; 8 Aug 2000 06:13:30 -0000 X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: "'Zachary Amsden'" Cc: , Subject: RE: 10. "Report propagation sequence" Date: Tue, 8 Aug 2000 16:18:48 +1000 Message-ID: <001301c00100$846ae680$17448490@vic.bigpond.net.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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <200008072356.AAA03163@mail.mirapoint.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit >[Albert] >Likewise there is no difficulty for *any* entry based >implementation in simply maintaining an index of entries by >local record sequence number. > >Therefore I argue that adding a local record sequence number to >enable propagating updates in strict order and using >HighwaterMarks between neighbours should be the architectural >change, rather than only requiring strict ordering within each >originator replicaId. > >Do you now agree? [Zach] Yes, adding a local sequence number merely requires an in order merge for a log based implementation, and this will be efficient enough when using HighwaterMarks. I would propose instead though for an ordering requirement: propagating updates in strictly increasing CSN order for each replica ID. Note that this does not impose the constraint that we must cycle through each replica, and send all changes from that replica before sending changes from another. It does not forbid it either. So an entry based implementation could simply transmit changes in the order received, and a log based could transmit in-order by replicaID. Both of these transmit orders must produce the same result state for the database, because they can both happen naturally (unless our URP rules are horribly broken). [Albert] Ok, as I see it, we are both agreed that adding a local sequence number and HighwaterMarks and requiring propagation in the exact same order as received would not be a problem for either entry based or log based implementations. Likewise we are both agreed that adding HighwaterMarks would improve performance. However you still maintain that it is sufficient to require that the originator sequence numbers for each replicaId be maintained in order, while I maintain that the record numbers of updates should be assigned by the consumer as the local sequence numbers as the updates are received, and then used as the message numbers of updates that are supplied to neighbour consumers, so that the *exact* sequence is preserved. I also maintain that the originator and local sequence number (identical) for any local changes should be assigned from the same sequence number generator, so that local changes are also interleaved into the *exact* propagation sequence. I agree that this does not contribute to saving bandwidth, and that the HighwaterMarks and local sequence numbers alone are sufficient for both improving performance and avoiding restarts on connection failure, without requiring *exact* correlation of the incoming and outgoing sequences. I will now explain the other reasons for maintaining that *exact* correlation below, as it is closely related to the severe problems you discuss below as to what happens when a server crashes. Essentially, I am trying to maintain an *exact* hop by hop sequence which has certain global properties, even though there is no corresponding exact global sequence (because of parallel and transitive routes, multiple sources etc). The obvious global properties include maintaining the sequence within each originator replicaId and also ensuring that parents are created before children (even though children may be created at a different replica). Both of these can be achieved without the *exact* sequence I am proposing, although the second may be simplified by it. The less obvious global property that I am aiming for is that a DSA crash can never result in other DSAs receiving later updates that have been applied to an entry, without also receiving any earlier changes that those later changes were dependent on. I am using "earlier" and "later" in the the context of the version number tree maintained by MDCR, and ensuring a global property of the report propagation sequence that substitutes for the *illusion* of a uniform flow of time reflected in CSNs as used in the current architecture. Up to now we have been discussing restarts and performance issues in a context equally applicable to the current architecture for report propagation. I must now ask you, (and anyone else joining this thread) to carefully study the alternative Coda/Active Directory based report propagation procedures proposed in sections 6 and 7 of my MDCR draft, as they are essential for understanding the issues below. http://www.ietf.org/internet-drafts/draft-langer-ldup-mdcr-00.txt Section 4 should also be read for background. Hmm, I just noticed that there is no section 5, so that is pages 4-12. Note that I am proposing report propagation should be entirely independent of update processing, with all reports delivered to all replicas unaltered, and new reports generated only by originators for local changes but never as a result of applying updates en route. This is equally applicable whether changes are ultimately merged at each replica as with URP, or conflicts are resolved, as with MDCR (section 8). The current architecture does not support any requirement for eventual convergence as it was written oblivious to the facts that DSAs sometimes crash and get restored from backups and that clocks are not necessarily even monotonic. Steve has indicated that he will be drafting report propagation procedures taking those facts into account for URP, but at present the Coda/Active Directory report propagation procedures proposed in MDCR are the only ones available, and they are equally applicable to URP. Assuming that the WG will require eventualy convergence under *all* circumstances, I think it is therefore reasonable to ask people to carefully study the only proposal currently available for achieving that, even though it is not yet on the WG agenda. [Zach] What initially brought me to this discussion was a quite different idea, though. What really worried me about the current phrasing of the draft was the fact that no ordering requirements were made at all within a transmission. This causes severe problems when a replication update is interrupted. I'm not so much worried about bandwidth, but the following scenario: Replica A sends a very long partial update to replica B. Somewhere in the middle of the transfer, the connection is terminated. Since we can get CSNs out of order within a replica ID, we have three options: 1) Save all changes until the transfer is complete, then commit them and send an end replication response. This still worries me because committing the changes may take a very long time, during which our peer may decide we are dead, and drop the connection. [Albert] Likewise my primary concern is not about bandwidth, although this particular thread started from that issue of restarts (and spikes from full replication). The proposal for *exact* sequencing is primarily directed at a purge mechanism that can guarantee eventual convergence. Please review the previous discussion of that primary concern in 4. "Eventual convergence - Version numbers or timestamps": http://www.imc.org/ietf-ldup/mail-archive/msg00616.html and in issue C, "Convergence" of: http://www.imc.org/ietf-ldup/mail-archive/msg00641.html See also 5. "Oscillation", especially: http://www.imc.org/ietf-ldup/mail-archive/msg00650.html I agree with you that option 1 is undesirable and in fact regard it as unacceptable as a general solution. Some other option MUST be available to implementors. [Zach] 2) Commit changes as we get them. Very problematic, since there is nothing prohibiting LDAP updates to our local replica while we are in a replication session. So when the connection dies, we have no idea what the current update vector for our replica is, and we can't easily back out changes because we may have received updates. [Albert] Since both option 1 and option 3 are unacceptable as a general solution, option 2 is the only option that remains for general use, however problematic. With the current architecture, option 2 is not merely "very problematic", but "completely broken". The CSNs generated by any supplier replica and/or expected by any consumer replica may in fact move backwards due to errors in setting time zones and daylight savings. (BTW year 2K testing would have resulted in any test changes becoming stuck until this millenium, if the WG had actually achieved its original timetable for deployment of standards last millenium, as there is no way to get rid of a change with a "future" CSN). A DSA that crashes will normally have local changes that have not been backed up, some of which will have been replicated to some neighbours, and others of which will not have been replicated to any. When it is restored from local backups to an earlier state, it could attempt to resynchronize with its neigbours by a partial replication, but this may fail for any of its own changes that are outside the time window allowed for purging, as a result of a substantial delay before restoration. Thus a full replication to resynchronize becomes necessary, with a consequent bandwidth spike, despite having an available local backup that could have been used to allow a partial replication if the report propagation architecture was not broken. Even if a partial replication to resynchronize is possible, any local changes that were not replicated before the crash, but were backed up, may not replicate to other DSAs, preventing convergence. These complex issues were dealt with in the Coda research adopted by Active Directory which I am proposing should be adopted as the basis for report propagation by this WG. Their solution does require *exact* ordering and I seriously doubt that anybody will come up with a better one that does not. Until somebody does, since we are both agreed that exact ordering would not be a problem for either log based or entry based implementations, can we also agree that it should be tentatively adopted as the design, pending some other alternative that can also be proved to guarantee eventual convergence under *all* circumstances? 3) Lock down our local replica from updates during the replication process. For some LDAP applications, this will not be an option. We may not know which replica to send update referrals too, or our clients may not be able to chase referrals for any number of reasons. Not only this, but if the connection does die, we can't allow updates until replication is re-established with the same supplier, or we revert all the changes and restore to a known state. Since there isn't actually enough information in a change record to undo the change, any server crash during this process is rather disastrous. This means we need to store a reverse operation for each change as well. [Albert] I agree that this is unacceptable. Refusing DUA updates is contemplated in the current architecture (with a "MAY") only for a full replication, which should only be necessary when a DSA is already offline anyway for that replication area (eg due to a crash). I believe that is correct and going offline to DUAs during incremental replication would completely negate the point of multi-master. BTW, by replicating operations rather than primitives, MDCR does carry enough information to be able to reverse changes. [Zach] These are the kind of warts I would like to avoid in the LDUP protocol. [Albert] These warts arise directly from using CSNs based on timestamps instead of version numbers, and from not maintaining an *exact* sequence when replicating. Surgery is required. From owner-ietf-ldup@mail.imc.org Tue Aug 8 11:03:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03102 for ; Tue, 8 Aug 2000 11:03:35 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA29410 for ietf-ldup-bks; Tue, 8 Aug 2000 07:14:47 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA29405 for ; Tue, 8 Aug 2000 07:14:45 -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 KAA03628; Tue, 8 Aug 2000 10:18:55 -0400 (EDT) Message-Id: <200008081418.KAA03628@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-replica-req-03.txt Date: Tue, 08 Aug 2000 10:18:55 -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 : LDAP V3 Replication Requirements Author(s) : R. Weiser, E. Stokes Filename : draft-ietf-ldup-replica-req-03.txt Pages : 15 Date : 07-Aug-00 This document discusses the fundamental requirements for replication of data accessible via the LDAPv3 [RFC2251] protocol. It is intended to be a gathering place for general replication requirements needed to provide interoperability between informational directories. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica-req-03.txt 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-replica-req-03.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-replica-req-03.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: <20000807142313.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-replica-req-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-replica-req-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000807142313.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Tue Aug 8 11:58:38 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09354 for ; Tue, 8 Aug 2000 11:58:37 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA06133 for ietf-ldup-bks; Tue, 8 Aug 2000 08:20:18 -0700 (PDT) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA06127 for ; Tue, 8 Aug 2000 08:20:16 -0700 (PDT) Received: (qmail 17206 invoked from network); 8 Aug 2000 15:19:12 -0000 Received: from cpe-144-132-68-23.vic.bigpond.net.au (HELO w98sysrec) (144.132.68.23) by relay1.pair.com with SMTP; 8 Aug 2000 15:19:12 -0000 X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: Cc: Subject: RE: I-D ACTION:draft-ietf-ldup-replica-req-03.txt Date: Wed, 9 Aug 2000 01:24:36 +1000 Message-ID: <002001c0014c$c3e23ce0$17448490@vic.bigpond.net.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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <200008081418.KAA03628@ietf.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Nope. It's still showing the delete notice when I click that URL. -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, August 09, 2000 12:19 AM To: IETF-Announce: Cc: ietf-ldup@imc.org Subject: I-D ACTION:draft-ietf-ldup-replica-req-03.txt 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 : LDAP V3 Replication Requirements Author(s) : R. Weiser, E. Stokes Filename : draft-ietf-ldup-replica-req-03.txt Pages : 15 Date : 07-Aug-00 This document discusses the fundamental requirements for replication of data accessible via the LDAPv3 [RFC2251] protocol. It is intended to be a gathering place for general replication requirements needed to provide interoperability between informational directories. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica-req-03.txt 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-replica-req-03.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-replica-req-03.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. From owner-ietf-ldup@mail.imc.org Tue Aug 8 14:36:47 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17346 for ; Tue, 8 Aug 2000 14:36:47 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA13088 for ietf-ldup-bks; Tue, 8 Aug 2000 10:54:41 -0700 (PDT) Received: from picard.noroff.no ([212.20.204.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA13083 for ; Tue, 8 Aug 2000 10:54:39 -0700 (PDT) Received: by picard.noroff.no (Postfix, from userid 815) id C3A9122004; Tue, 8 Aug 2000 20:42:53 +0200 (CEST) Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by picard.noroff.no (Postfix) with ESMTP id CA73FB3802 for ; Tue, 8 Aug 2000 20:42:50 +0200 (CEST) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id NAA28981 for ietf-123-outbound.09@ietf.org; Tue, 8 Aug 2000 13:25:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id KAA26808 for ; Tue, 8 Aug 2000 10:19:00 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03628; Tue, 8 Aug 2000 10:18:55 -0400 (EDT) Message-Id: <200008081418.KAA03628@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-replica-req-03.txt Date: Tue, 08 Aug 2000 10:18:55 -0400 X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre2 (http://amavis.org/) 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 : LDAP V3 Replication Requirements Author(s) : R. Weiser, E. Stokes Filename : draft-ietf-ldup-replica-req-03.txt Pages : 15 Date : 07-Aug-00 This document discusses the fundamental requirements for replication of data accessible via the LDAPv3 [RFC2251] protocol. It is intended to be a gathering place for general replication requirements needed to provide interoperability between informational directories. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica-req-03.txt 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-replica-req-03.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-replica-req-03.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: <20000807142313.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-replica-req-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-replica-req-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000807142313.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Tue Aug 8 15:38:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24104 for ; Tue, 8 Aug 2000 15:38:55 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA14210 for ietf-ldup-bks; Tue, 8 Aug 2000 11:58:48 -0700 (PDT) Received: from mail1.ecal.com ([216.150.139.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA14206 for ; Tue, 8 Aug 2000 11:58:46 -0700 (PDT) Received: from pacapple ([216.150.139.10]) by mail1.ecal.com (Post.Office MTA v3.5.2 release 221 ID# 30-55765U3000L300S0V35) with SMTP id com; Tue, 8 Aug 2000 15:02:42 -0400 Reply-To: From: capple@ecal.com (Christopher Apple) To: Cc: Subject: RE: I-D ACTION:draft-ietf-ldup-replica-req-03.txt Date: Tue, 8 Aug 2000 15:02:21 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0006_01C00149.A788E1A0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <002001c0014c$c3e23ce0$17448490@vic.bigpond.net.au> 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_01C00149.A788E1A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Its now accessible using the URL below. If the expiration message still shows up, try clearing your browser's cache and forcing a page reload using whatever mechanism your web browsing client has to peform such functions. Chris Apple capple@ecal.com -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Albert Langer Sent: Tuesday, August 08, 2000 11:25 AM To: Internet-Drafts@ietf.org Cc: ietf-ldup@imc.org Subject: RE: I-D ACTION:draft-ietf-ldup-replica-req-03.txt Nope. It's still showing the delete notice when I click that URL. -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, August 09, 2000 12:19 AM To: IETF-Announce: Cc: ietf-ldup@imc.org Subject: I-D ACTION:draft-ietf-ldup-replica-req-03.txt 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 : LDAP V3 Replication Requirements Author(s) : R. Weiser, E. Stokes Filename : draft-ietf-ldup-replica-req-03.txt Pages : 15 Date : 07-Aug-00 This document discusses the fundamental requirements for replication of data accessible via the LDAPv3 [RFC2251] protocol. It is intended to be a gathering place for general replication requirements needed to provide interoperability between informational directories. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica-req-03.txt 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-replica-req-03.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-replica-req-03.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_000_0006_01C00149.A788E1A0 Content-Type: text/x-vcard; name="Chris Apple.vcf" Content-Disposition: attachment; filename="Chris Apple.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Apple;Chris FN:Chris Apple NICKNAME:capple ORG:eCal Corporation TEL;WORK;VOICE:215-627-5001, ext. 3839 TEL;CELL;VOICE:(267) 977-8333 TEL;WORK;FAX:215-627-0927 ADR;WORK:;;510 Walnut Street;Philadelphia;PA;19106;US LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:510 Walnut = Street=3D0D=3D0APhiladelphia, PA 19106=3D0D=3D0AUS URL: URL:http://www.ecal.com EMAIL;PREF;INTERNET:capple@ecal.com REV:20000725T173628Z END:VCARD ------=_NextPart_000_0006_01C00149.A788E1A0-- From owner-ietf-ldup@mail.imc.org Tue Aug 8 19:17:48 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21609 for ; Tue, 8 Aug 2000 19:17:48 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA17874 for ietf-ldup-bks; Tue, 8 Aug 2000 15:31:50 -0700 (PDT) Received: from mail.mirapoint.com (IDENT:mirapoint@mail.mirapoint.com [208.48.74.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA17870 for ; Tue, 8 Aug 2000 15:31:48 -0700 (PDT) Received: from mail.mirapoint.com (localhost.mirapoint.com [127.0.0.1]) by mail.mirapoint.com (Mirapoint) with SMTP id AAA07189; Tue, 8 Aug 2000 15:35:47 -0700 (PDT) Message-Id: <200008082235.AAA07189@mail.mirapoint.com> Received: from 127.0.0.1 by mail.mirapoint.com with HTTPS/1.1; Tue, 8 Aug 2000 15:35:47 -0700 Date: Tue, 8 Aug 2000 15:35:47 -0700 From: Zachary Amsden Subject: RE: 10. "Report propagation sequence" To: Albert.Langer@directory-designs.org Cc: "'Zachary Amsden'" , steven.legg@adacel.com.au, ietf-ldup@imc.org X-Mailer: Mirapoint Webmail Direct 2.7.0.22 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 >[Albert] >However you still maintain that it is sufficient >to require that the originator sequence numbers for each >replicaId be maintained in order, while I maintain that the >record numbers of updates should be assigned by the consumer >as the local sequence numbers as the updates are received, >and then used as the message numbers of updates that are >supplied to neighbour consumers, so that the *exact* sequence >is preserved. > >I also maintain that the originator and local sequence number >(identical) for any local changes should be assigned from the >same sequence number generator, so that local changes are >also interleaved into the *exact* propagation sequence. >The obvious global properties include maintaining the >sequence within each originator replicaId and also ensuring >that parents are created before children (even though >children may be created at a different replica). Both of >these can be achieved without the *exact* sequence I am >proposing, although the second may be simplified by it. >The less obvious global property that I am aiming for is >that a DSA crash can never result in other DSAs receiving >later updates that have been applied to an entry, without >also receiving any earlier changes that those later changes >were dependent on. I am using "earlier" and "later" in the >the context of the version number tree maintained by MDCR, >and ensuring a global property of the report propagation >sequence that substitutes for the *illusion* of a uniform >flow of time reflected in CSNs as used in the current >architecture. [Zach] Ok, using the ordering we discussed does guarantee those properties. Almost (more below). But with the in-order by replicaID ordering you didn't need a DSA crash for property two to be violated - it could happen naturally due to scheduling or network availability. You can only guarantee either one of these properties if clients are well behaved. If a client converses with multiple masters, and assumes that each master has an identical state, both properties can be violated. Not that I really think clients would be doing that, but sending an update referral worries me. Say a disk crash causes a DSA failure, and a total update is required. Meanwhile, a client who had been conversing with this DSA now gets a referral to another DSA, which may not have the same state. [Albert] >A DSA that crashes will normally have local changes that have not >been backed up, some of which will have been replicated to some >neighbours, and others of which will not have been replicated to >any. When it is restored from local backups to an earlier state, >it could attempt to resynchronize with its neigbours by a partial >replication, but this may fail for any of its own changes that >are outside the time window allowed for purging, as a result of >a substantial delay before restoration. Thus a full replication >to resynchronize becomes necessary, with a consequent bandwidth >spike, despite having an available local backup that could have >been used to allow a partial replication if the report propagation >architecture was not broken. Yes. True for any architecture that allows purging of changes. I don't see this as a problem. >Even if a partial replication to resynchronize is possible, any >local changes that were not replicated before the crash, but were >backed up, may not replicate to other DSAs, preventing convergence. I think it MUST be a requirement that convergence can be reached even if one replica master goes permanently kaput. Of course that convergence will not include any changes generated locally at that replica that were not propogated. I believe that this is inline with your scheme, but I'm not 100% sure what you meant by par 2, pg 11, of MDCR If a failed replica is restored from backups any reports it holds that have already been propagated will not be requested by its neighbours and any that have not been propagated will have also prevented the propagation of later reports from the same originator that have a higher originatorRSN. Of course you can't reach global convergence if this replica was a tie point (new definition: tie point is a non-leaf replica whose linkages are not redundant), since you will have two isolated clusters of masters. But with redundant replication agreements, I think it MUST be possible to reach convergence despite failure of individual DSAs. You may diverge again if the DSAs come back on line and replicate conflicting changes. >These complex issues were dealt with in the Coda research adopted >by Active Directory which I am proposing should be adopted as the >basis for report propagation by this WG. > >Their solution does require *exact* ordering and I seriously doubt >that anybody will come up with a better one that does not. > >Until somebody does, since we are both agreed that exact ordering >would not be a problem for either log based or entry based >implementations, can we also agree that it should be tentatively >adopted as the design, pending some other alternative that can also >be proved to guarantee eventual convergence under *all* circumstances? Yes, I like the ordering idea in the MDCR draft. However, I'm a bit confused by the versioning scheme: " Updates are not changes and do not increment the version. Updates do replace the version with a version that is not smaller, ... The replacement version from an update is usually, but not always larger. Successive versions of an entry are not always consecutive but are always monotonically increasing. The lexical ordering of version, modifyTimestamp and originator of an entry is always strictly monotonically increasing. " This is very open to interpretation. They could actually all be interpreted as mutually exclusive. >[Albert] >BTW, by replicating operations rather than primitives, MDCR does >carry enough information to be able to reverse changes. [Zach] Disagree. How does an LDAP modify operation carry enough information to reverse changes? However, reverting is not necessary with MDCR, since you are always guaranteed a known database state. This is the problem I was trying to correct in the current propagation scheme. Zach From owner-ietf-ldup@mail.imc.org Tue Aug 8 23:57:23 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14806 for ; Tue, 8 Aug 2000 23:57:22 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA05761 for ietf-ldup-bks; Tue, 8 Aug 2000 20:24:11 -0700 (PDT) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA05752 for ; Tue, 8 Aug 2000 20:24:10 -0700 (PDT) Received: (qmail 29722 invoked from network); 9 Aug 2000 03:23:09 -0000 Received: from cpe-144-132-68-23.vic.bigpond.net.au (HELO w98sysrec) (144.132.68.23) by relay1.pair.com with SMTP; 9 Aug 2000 03:23:09 -0000 X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: Cc: Subject: RE: I-D ACTION:draft-ietf-ldup-replica-req-03.txt Date: Wed, 9 Aug 2000 13:28:14 +1000 Message-ID: <000e01c001b1$db1fafe0$17448490@vic.bigpond.net.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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thanks. It's fine here now. Worked first time I clicked, without clearing. I'm pretty sure I forced a page reload before, so it may have been some weirdness in my ISP's proxy cache, which I couldn't bypass on this account, but is ok now. -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Christopher Apple Sent: Wednesday, August 09, 2000 5:02 AM To: Albert.Langer@directory-designs.org Cc: ietf-ldup@imc.org Subject: RE: I-D ACTION:draft-ietf-ldup-replica-req-03.txt Its now accessible using the URL below. If the expiration message still shows up, try clearing your browser's cache and forcing a page reload using whatever mechanism your web browsing client has to peform such functions. Chris Apple capple@ecal.com From owner-ietf-ldup@mail.imc.org Wed Aug 9 23:37:24 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27688 for ; Wed, 9 Aug 2000 23:37:24 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id UAA28548 for ietf-ldup-bks; Wed, 9 Aug 2000 20:09:23 -0700 (PDT) Received: from bird (sero.mf.ejf.hu [193.225.84.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA28140; Wed, 9 Aug 2000 20:05:54 -0700 (PDT) From: nan@quotepool.com Received: from mxspr.mail.accesscomp1.net (host10.4ua.com) by bird with SMTP (1.39.111.2/16.2) id AA067490053; Thu, 10 Aug 2000 03:14:13 +0200 Date: Thu, 10 Aug 2000 03:14:13 +0200 Message-Id: <965875852.cqcoqcngetrm@cqcoqcngetrm.mail.accesscomp1.net> To: cqcoqcngetrm@accesscomp1.net Reply-To: nan@quotepool.com X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en Content-Type: text/html; Charset=us-ascii Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Are you looking for a J.O.B. or Financial Freedom? vyjxg Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit

93% WHO RESPOND TO MY AD DON'T MAKE THE CUT!
(Only highly motivated people should call)

I'm dead serious! Now let me tell you why...

Most people don't have drive! They sit around waiting for something to happen.
They see that other people have nice homes, new cars, and MONEY, but why can't they?
They basically feel sorry for themselves, and I can't help these people!

Another reason people are not qualified...

They are skeptical. BUT, the truth is, they are skeptical of themselves!
They don't have the courage to break their routine.
They are comfortable with their set hours, their set pay, and their set future.
I was not comfortable with someone controlling my future,
and I'm not comfortable working with people who are!

STOP
If you are anything like the above, we won't be able to work together!

WHAT DO THE 7% WHO DO MAKE THE CUT DISCOVER?!

People I select through an "interview like" process are forever changed!
They are opened to a world around them that they didn't know existed.
In fact, it's a world that has existed around them their whole lives,
but was purposely hidden from them!


How would you like to...

- Drastically reduce personal, business and capital gains taxes?
- Protect all assets from any form of seizure, liens, or judgments?
- Create a six figure income every 4 months?

How about...

Restoring and preserving complete personal and financial privacy?
Amassing personal wealth, multiplying it and protecting it?
Realizing a 3 to 6 times greater return on your money?
Legally making yourself and your assets completely judgment-proof,
lien-proof, divorce-proof, attorney-proof, IRS-proof?
I could go on...

TAKE A SERIOUS LOOK AT YOUR LIFE

Do you think you are paid what you are worth?
Will you be set to retire in the next few years?
Do you control the course of your day? ...your life?

The fact is we have many people in our enterprise that earn over 50K per month
from the privacy of their own homes, and are retiring in 2 to 3 years (wealthy)
and have total freedom - both personal and financial!

Many have been conditioned to believe it must be illegal, immoral or unethical
to ever earn any real profits from our efforts.

The sad truth is, it's been designed that way by the ultra-rich
and ultra-powerful since before any of us were born!

Who am I?

I'm a BIG thinker, a BIG dreamer, and I believe that I deserve the best that life has to offer.
I answered an ad much like the one you are reading now,
and was eager to hear what it was about.

I knew that I couldn't invest only a few bucks and spend an hour or two
per week to achieve the results I was looking for. I found the right information
and now I control my own destiny!

If you are interested in radically changing your thoughts and your financial future,
I invite you to call TOLL FREE:

1 800 707 4817

My name is Krystina, and I look forward to working with some of you!

* REMEMBER *

I can't do it for you, but I can show you exactly how I do it.
It's as simple as that!

From owner-ietf-ldup@mail.imc.org Thu Aug 10 17:18:56 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14191 for ; Thu, 10 Aug 2000 17:18:56 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA13465 for ietf-ldup-bks; Thu, 10 Aug 2000 13:37:54 -0700 (PDT) Received: from mail.mirapoint.com (IDENT:mirapoint@mail.mirapoint.com [208.48.74.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13460 for ; Thu, 10 Aug 2000 13:37:53 -0700 (PDT) Received: from mail.mirapoint.com (localhost.mirapoint.com [127.0.0.1]) by mail.mirapoint.com (Mirapoint) with SMTP id AAA15763; Thu, 10 Aug 2000 13:36:42 -0700 (PDT) Message-Id: <200008102036.AAA15763@mail.mirapoint.com> Received: from 127.0.0.1 by mail.mirapoint.com with HTTPS/1.1; Thu, 10 Aug 2000 13:36:49 -0700 Date: Thu, 10 Aug 2000 13:36:49 -0700 From: Zachary Amsden Subject: Re: controlling visability of subentries To: "Kurt D. Zeilenga" Cc: Ed Reed , zach@mirapoint.com, mcs@netscape.com, ietf-ldup@imc.org, ietf-ldapext@netscape.com X-Mailer: Mirapoint Webmail Direct 2.7.0.22 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 >I would suggest the control have a syntax similar to >ManageDsaIT control defined by draft-ietf-ldapext-refer-00.txt >(or draft-zeilenga-ldap-nameref-00.txt) but with semantics of >the X.511 ServiceControls "subentries" option [X.511(97) 5.7f]. > >Kurt How about Control ::= SEQUENCE { controlType = 2.16.840.1.113719.2.142.7.TBD criticality = TRUE controlValue = (not present) } I think it should be critical, since if the server doesn't recognize it, there is no way the request can be processed sucessfully. Zach From owner-ietf-ldup@mail.imc.org Fri Aug 11 14:45:47 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29829 for ; Fri, 11 Aug 2000 14:45:46 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA06100 for ietf-ldup-bks; Fri, 11 Aug 2000 11:06:17 -0700 (PDT) Received: from infidel.boolean.net (root@router.boolean.net [198.144.206.49]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA06096 for ; Fri, 11 Aug 2000 11:06:15 -0700 (PDT) Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [198.144.202.243]) by infidel.boolean.net (8.9.3/8.9.3) with ESMTP id SAA14082; Fri, 11 Aug 2000 18:05:17 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <4.3.2.7.0.20000811105530.00b281e0@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 11 Aug 2000 11:03:44 -0700 To: From: "Kurt D. Zeilenga" Subject: RE: Framing/Grouping Issues Cc: In-Reply-To: <000001bfff5f$077753e0$17448490@vic.bigpond.net.au> References: <4.3.2.7.0.20000804161734.00b0cc40@router.boolean.net> 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: Albert, I've provided draft-zeilenga-ldap-txn-00.txt which defines semantics associated with a particular grouping type. This draft, and the grouping draft, are still a bit rough (in particular in regards to error handling). However, I hope this provides enough information such that we might be able to reach consensus on the two questions I previously noted in regards to the effort to combine the grouping/framing syntactical sugar I-Ds into one I-D. Kurt I wrote: >We (the authors) agreed that there were uses for both framing and >grouping and we agreed to create a combined I-D which supported >both styles. The style would be prescribed by the OID associated >with the frame/group type (along with other semantics). If you >have concerns regarding this "combined" or "dual" framing/grouping >approach, please voice them ASAP. > >Also, we discussed the addition of "manage" frame/group operation >(no management semantics are defined). We agreed to add this as >well. If you have concerns regarding this addition, please voice >them ASAP. From owner-ietf-ldup@mail.imc.org Fri Aug 11 19:05:34 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07628 for ; Fri, 11 Aug 2000 19:05:33 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA14464 for ietf-ldup-bks; Fri, 11 Aug 2000 15:25:05 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA14460 for ; Fri, 11 Aug 2000 15:25:03 -0700 (PDT) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.2.212]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id PAA10076; Fri, 11 Aug 2000 15:24:03 -0700 (PDT) Received: from jstrassnlap ([171.69.108.130]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AKN19297; Fri, 11 Aug 2000 15:23:45 -0700 (PDT) Message-ID: <04b701c003e3$279f8880$826c45ab@cisco.com> Reply-To: "John Strassner" From: "John Strassner" To: Cc: "Chris Apple" , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Ned Freed" , Subject: Draft minutes for LDUP Date: Fri, 11 Aug 2000 15:26:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit are below. Please comment asap. regards, John LDUP WG Meeting, Wednesday August 1, 2000 Meeting minutes recorded by John Strassner 0. Agenda discussed, and no changes were made. 1. "LDAP Replication Requirements" http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica- req-03.txt Editor(s): Russ Weiser, Ellen Stokes This is an expired draft and needs to be republished in order for us to proceed with work on it. By republishing, we mean that the document must be published, with no changes other than an updated revision number. This is necessary so that we can refer to it in the upcoming discussions. This will be done this week Action: republishing to be done this week; see item 12 below. 2. "LDUP Update Reconciliation Procedures" http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-03.t xt Editor(s): Steven Legg, A Payne This draft has undergone a minor revision, having been updated to include the correct use of MUST and MAY as well as a clarification resulting from the discussion with Albert Langer. In addition, the References and Security Considerations sections have also been updated. In summary, it is ready to go to last call, but can't until the requirements document is updated to reflect the discussions with Albert Langer. Action: none, pending resolution of requirements draft - see item 12 3. "LDAP Replication Architecture" http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-04 .txt Editor(s): Ed Reed, U. Srinivasan, John Merrells There were open comments from the mailing list regarding references in this draft to other drafts. We had a synchronization problem with these other drafts, as these normative references were moving and this draft was getting out of sync. This has been corrected, and the normative references removed. The only remaining open issue in this draft is the relationship between access control and the definition of naming context. In LDUP, the naming context is the unit of replication, but in access control, it is slightly different (administration points are defined differently than naming contexts). Once these changes are made, the document will be ready for last call. Action: this draft will be revised by the end of September. Depending on the resolution of the issue above, it may be ready for last call then. 4. "LDUP Replication Information Model" http://www.ietf.org/internet-drafts/draft-ietf-ldup-infomod- 01.txt Editor(s): Ed Reed No changes in this document as of now. Reference to ITU UUID document was found and will be incorporated. General reconciliation with the architecture document is now necessary. One additional point is that access control information needs to be replicated, but we don't want to deal with inherited ACI yet. This issue needs to be taken to the list. Actions: 1) Ed to lead discussion on the list regarding how to handle replication of ACI. 2) The next revision of this draft will be published by the end of October. 5. "LDAP Subentry Schema" http://www.ietf.org/internet-drafts/draft-ietf-ldup-subentry -03.txt Editor(s): Ed Reed Basic problem is that the presence of a subentry causes an administrative area to be defined. So the administrative area may not exactly coincide with the naming context. The subentry document needs to be updated to define what is meant by each of these terms. The management of administrative areas, and how this differs (if at all) from the management of naming contexts, needs to be documented. This challenges us to as to whether replication needs semantic understanding of administrative areas. This seems like a very thorny issue, and it was suggested that we treat this as a version 2 problem in order to make progress with the existing definition of LDUP. This draft will be revised to make scoping of LDUP subentry more clear. Open issue raised by Kurt is to use a control instead of a filter mechanism to make subentries visible. This issue has been posted to the list. Action: The next revision of this draft will be published by the end of October. 6. "The LDUP Replication Update Protocol" http://www.ietf.org/internet-drafts/draft-ietf-ldup-protocol -01.txt Editor(s): G. Good, E. Stokes A few open issues have been raised with respect to the signatures of ReplicationStart and other commands. This will cause the document to be revised. The big problem is whether this document should or should not use framing. This discussion needs to be taken to the list. Actions: 1) Ellen and/or Gordon to lead discussion on the list as to whether this document should use framing. 2) The next revision of this draft will be published by the end of October. 7. "Extended Operations for Framing LDAP Operations" http://www.ietf.org/internet-drafts/draft-ietf-ldup-framing- 00.txt Editor(s): G. Good, E. Stokes, Roger Harrison This work will be subsumed into the grouping operations work being done in LDAPEXT and produce a new framing document (see below). Action: This draft will be updated by the end of Septmeber. 8. Mark Wahl - Grouping operations In Adelaide, work was started on taking the existing LDUP framing document (which LBURP was using) and generalizing it so that other operations could use framing. One possible use of framing was to add transaction support to the directory protocol, but this was decided to be too big to tackle. However, there is interest in the use of framing in other areas (e.g., for the client to request locking on entries, or for certain integrity constraints to be maintained). One of the desired features is to change the referential integrity enforced by a directory server, such that instead of maintaining referential integrity on an operation by operation basis, it instead changes to maintain referential integrity on a set of updates (e.g., enforce it at the end of the operations). Mark believes that we need extended operations for delimiting beginXX and endXXX operations, and need a document to cover these associated semantics. Note that what is being proposed is that there is a generic way of saying Begin and End. So the framing document needs to be generalized so that everyone can use it. This should be done with a joint last call with LDAPEXT. Action: Mark and Roger to work on a revised draft, to be out sometime in October. 9. Some deliverables still missing in action... 9a. Mandatory replica management (Ed Reed). Mark has given us a starting draft; Ed will work with others and try and issue this document in September. 9b. Master-slave and multi-master profile documents are behind schedule. Uppilli will take the lead on this work. Since work has stalled, the question was asked, is it beneficial to have profiles that specify how replication works for single-master vs. multi-master. Actions: 1) Uppilli to lead discussion on the list as to whether we still need separate profiles for (at least) single- vs. multi-master or not. 2) The next revision of this draft will be published by the end of October. 10. Charter Addition for LCUP? "LDAP Client Update Protocol" http://www.ietf.org/internet-drafts/draft-natkovich-ldap-lcu p-01.txt Editor(s): O. Natkovich, M. Smith, M. Armijo The short summary is that LCUP is dirsync, persistent search, triggered search, and LDUP replication. There is an open issues section in the current draft. PLEASE COMMENT! Room was polled, and a large majority of the room was in favor of adding it (no one was actually opposed). Patrik asked if this would conflict with or hold up existing work, and the answer was no, there was already a dedicated group of people ready to work on this that weren't involved in other work. This question will therefore be taken to the list. Actions: 1) Co-chairs to poll the list to ensure that no one objects to adding adding LCUP to the LDUP charter. 2) If no one objects, then co-chairs to propose new charter to list; if acceptable to list, then to work with Ads to get our charter officially amended. 11. Other business (besides discussion of Albert's comments): LBURP We also have an open question of adding LBURP to our charter. This draft has been revised since the last meeting (draft-rharrison-lburp-02.txt). The changes to the -02 version include adding a new operation, LBURPOperationPartialResponse (note name change from slide). This tells you what operations have succeeded, failed, or are still pending. Remaining questions - after a brief discussion, it seems like the ability to defer operations should be taken out, as it causes more problems than it solves. What is the relation between LBURP and the framing document? Roger will try and move this document to keep it in sync with the framing document. Finally, there wasn't a lot of feedback as to whether LBURP should be added to our charter or not. Action: co-chairs to pose the question of adding LBURP to the list or not. 12. Discussion of LDUP Requirements Document Discussion about issues raised by Albert Langer. It was impossible to judge how to proceed, based on the lack of discussion that occurred on the list. So the co-chairs asked for an independent review. This initial work was done by Rick Huber and Ryan Moats. Both will be added as authors of the requirements document as a result of this work. Summary of Objections to Requirements The big four points are as follows: - No requirement for convergence or eventual consistency - No requirement for atomic operations - No requirement to support mandatory operational attributes of LDAP - Definition of updateable replica inconsistent with multi-master replication Taking these objections in order... First point: These seem to be covered by requirements 5.2 and 5.7. But, since the draft goes to the trouble of defining 5 different types of consistency. But, since the draft goes to the trouble of defining five different types of consistency, it would be a Good Thing if the requirements were stated in those terms. Action: Suggest adding a requirement for Eventual Consistency. Second point: there is a requirement for atomicity in LDAPv3 per RFC2251, section 4.6, and the referenced Tim Howes quote. So the real question is whether this is covered in sections 5.2 and 5.7. Action: Suggest adding something more specific, as this would avoid any later confusion. Still on this point, we had an atomicity discussion. Consider the following replication scenario. Servers A, B, and C replicate with each other using multi-master replication. On server A, attributes 1, 2, and 3 of entry E are changed (an atomic operation). On server B, attribute 2 of entry E is changed. Without descending into the religious { ;-) } argument of which method is best, assume for the moment that the change on B has a later time stamp than the change on A. There are three possible options: discard all changes from A, make changes from A and ignore B, or make change from A and then make change from B. Note that this is an example of race conditions. If you want to change attribute 2 based upon the value of attribute 1, then since LDAP doesn't have a true read lock, you can't do this. It was argued that LDAP does have a read lock by virtue of doing a delete-add of the same value (which is basically a test and set). So, what should happen? There are three possibilities: 1. The entire change from A is discarded since it is atomic and was superceded by the change from B. 2. The change from A is made and all attributes reflect the values on A since the change was atomic, and B is deleted. 3. Attributes 1 and 3 reflect the values from A, attribute 2 reflects the value from B. Note that the third case is what would happen in the single-server or single-master case. In addition, the third choice seems to be the most reasonable choice according to the time-honored Principle of Least Astonishment. ;-) There was overwhelming consensus in the room that this last case was indeed what was expected. This boils down to the following problem - if a set of requests were submitted as a group, then the replication system should treat them as an atomic group. However, each operation should be processed on its own for conflict resolution (as opposed to the group). Note that the word atomic causes problems. In the example scenario, we want the value to end up with {1, 2', 3}. It was noted that part of the problem is in viewing this as entry-centric, as opposed to being attribute-centric. Action: this is a good example, summarizing many of Albert's objections, and why it was felt that in this area his objections were not reasonable. It should be included in the new version of the requirements document. The third point is that there was no requirement to support the mandatory operational requirements of LDAP. Ryan and Rick noted that ModifiersName is a MAY in 2251 and a SHOULD in 2252. This is a Bad Thing, and Mark promised to fix this. Action: Mark Wahl, please fix this. ;-) However, it was noted that ModifiersName applies to Entries, not attributes, so it is unclear how this specific example applies. Summary: doesn't affect requirements draft, but does affect LDAPBIS. Action: Also recommended that Mark Wahl post to the list a set of additional requirements on operational attributes that must be maintained during replication. Inconsistent Definitions. It was pointed out by Albert that the definition of an updateable replica conflicts with section 5.6. Action: Change the definition of an updateable replica to: "An authoritative read-write copy of the replicated information". The room seemed happy with this. Summary of issues between URP and MDCR, and resulting action items: 1. Atomicity and related concepts Action: Making some explicit statements about atomicity in the requirements document would clear up this issue. 2. modifiersName and other operational attributes Action: this point is moot 3. Change reports - Use ProtocolOps or Primitives Action: no consensus, need further discussion on the list. It was note that we need to include how each addresses (or doesn't address) atomicity. 4. Eventual convergence - Version numbers or timestamps Action: looks like a religious argument; no consensus reached. 5. Oscillation The claim has been made that MDCR oscillates. Everyone agrees that oscillation is bad. Needs more discussion on the list. 6. Implementation and performance issues Action: There have been claims that URP and MCR have comparable performance and implementation requirements. Suggest that we accept this unless someone can prove that this is not true, and prove it quickly. 7. Revocation notices Action: unclear. MDCR could add them, and they aren't applicable for URP. Suggest dropping this, there are bigger fish to fry. 8. Strong consistency and transactions Action: LDAP doesn't do transactions, so this is out of scope. As a result of this, co-chairs will update the charter to note that transactions are expicitly out of scope. From owner-ietf-ldup@mail.imc.org Mon Aug 14 04:04:19 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01994 for ; Mon, 14 Aug 2000 04:04:18 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA01997 for ietf-ldup-bks; Mon, 14 Aug 2000 00:17:45 -0700 (PDT) Received: from mailweb3.rediffmail.com (IDENT:qmailr@[202.54.124.148]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA01984 for ; Mon, 14 Aug 2000 00:17:21 -0700 (PDT) Received: (qmail 3202 invoked by uid 510); 14 Aug 2000 07:11:53 -0000 Date: 14 Aug 2000 07:11:53 -0000 Message-ID: <20000814071153.3201.qmail@mailweb3.rediffmail.com> MIME-Version: 1.0 To: "ietf-ldup@imc.org" Subject: Re: urgent help From: "rajeev vc" Content-ID: Content-type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Friends, I would like to know any link or docs for IRCD integration with LDAP. thanks and regards rajeev _________________________________________________ Get Your Free Email At, http://www.rediffmail.com Partcipate in crazy Re.1 auctions at http://www.rediff.com/auctions _________________________________________________ Get Your Free Email At, http://www.rediffmail.com Partcipate in crazy Re.1 auctions at http://www.rediff.com/auctions From owner-ietf-ldup@mail.imc.org Mon Aug 14 23:44:15 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24827 for ; Mon, 14 Aug 2000 23:44:14 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id TAA11807 for ietf-ldup-bks; Mon, 14 Aug 2000 19:59:19 -0700 (PDT) Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA11797 for ; Mon, 14 Aug 2000 19:59:15 -0700 (PDT) Received: (qmail 6602 invoked from network); 15 Aug 2000 02:58:59 -0000 Received: from unknown (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 15 Aug 2000 02:58:59 -0000 Reply-To: From: "Steven Legg" To: Cc: , Subject: RE: LDUP Working Group Agenda - Summary of objections to requirements draft Date: Tue, 15 Aug 2000 13:01:37 +1000 Message-ID: <000001c00665$21483de0$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 In-Reply-To: <001701bff8da$1e6110e0$17448490@vic.bigpond.net.au> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Albert, > -----Original Message----- > From: owner-ietf-ldup@mail.imc.org > [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Albert Langer > Sent: Saturday, 29 July 2000 7:24 > To: steven.legg@adacel.com.au > Cc: ietf-ldup@imc.org; ietf-ldapext@netscape.com > Subject: RE: LDUP Working Group Agenda - Summary of objections to > requirements draft [snip] > Work is proceeding, outside LDUP, but within LDAPEXT, on how to group > updates and/or do transactions in a standardized manner. > > Some applications already use existing directory services to add their > own non-standardized transactional semantics, relying only on the > LDAP/X.500 data model which *does* support atomic operations on a > single entry, but does not provide any means for locking a set of > entries or performing an operation atomically on that set. > > Methods include writing transaction identifiers to special > attributes in each of the set of entries, then checking that nobody > else did so, to any of them, after updating all the entries. > This requires > that only DUAs cooperating in a transactional application have write > access to all relevant attributes of the entries. > > This sort of thing can work in a single master environment, > but becomes > more complex in a multi-master environment. It is still possible > provided attributes as a whole are replicated atomically, even > though updates to different attributes of a single entry may be > merged - as shown by the fact that Active Directory applications can > do this, clumsily, using "consistency guids" and "child counts". > > However it becomes much more difficult, and perhaps impossible, with > URP, because even concurrent changes to individual attribute values of > a single attribute may be merged. If the required behaviour is for only one or the other of two concurrent updates to an attribute to be retained, instead of the values being merged, then this can be achieved by using the replace attribute alternative in an LDAP modify or by defining the attribute in question to be single-valued. [snip] > [Issue C - Convergence] > > SUMMARY OF OBJECTIONS TO REQUIREMENTS DRAFT > > > > The three key points are: > > > > 1) There is no requirement for convergence or "eventual > consistency". > > > > This looks like just poor expression, but in fact the LDUP > > architecture and > > Update Reconciliation Procedures do specify proposed standards that > > guarantee long term divergence by relying on timestamps > > [Steve] > The timestamp in the CSN is just a version number that happens > to increment without visible update activity. A version number > scheme that leaves gaps in the runs of version numbers isn't > broken as long as the version numbers from a server are > monotonically increasing. The LDUP CSN is monotonically > increasing too. > The only difference with the LDUP CSN is that the gaps just happen > to have a correlation to elapsed time. > > > and > > allowing DSAs to > > transmit changes out of order and drop changes when clocks > > are out of sync. > > This is easily fixed, once a requirement to fix it is agreed on. > > > > Details on how to fix it based on the Coda replication > protocols also > > adopted by Active Directory, and a semi-formal proof that the > > fix would be > > robust in the face of DSAs crashing and being restored from > > backups, network > > partitioning etc etc, is included in my draft below. > > Your proof neglects the effects of the purging mechanism. Restoring > a crashed DSA from a backup works if no change information is ever > removed. However if a backup restores a DSA to a state prior to the > purge point of any of the other replicas there exists the possibility > that the other DSAs have forgotten changes that the restored DSA > needs to bring it up to date and consistent with the others. > > I have a procedure for solving the replica consistency problems of > restored replicas and rejoined partitions but it is written in terms > of a log-based implementation using a different purging mechanism. > I'm still in the process of recasting it in state-based terms with > an update vector. > > [snip] > > [Albert] > My reference to "relying on timestamps and allowing DSAs to > transmit changes out of order and drop changes when clocks are out > of sync" should be read as a single sentence. Clocks are not > necessarily even monotonically increasing because they sometimes > jump around when administrators make mistakes, eg with time zone > and daylight savings settings. You should read section 5.1 of draft-ietf-ldup-urp-03.txt again. The CSNs aren't always generated straight from the system clock. URP imposes constraints on the generation of CSNs so that they are monotonically increasing from replication session to replication session despite a system clock that isn't. The references in the architecture draft to rejecting update operations need a bit of work. There is some confusion and ambiguity there about whether client updates or replication updates or both are being rejected. Eventual consistency can't be guaranteed if any replication updates are just arbitrarily dropped. We can reject a whole replication session if there are seriously different CSNs appearing provided no Update Vectors are revised, and provided we have an administrative procedure for repairing the situation. In effect the rogue server is shunned and the purge point stops advancing until corrective action is taken. The action to be taken would need to covered in the draft on replica administration. Servers are only permitted to send changes from a particular server out of order within the same replication session. All changes from that server in earlier sessions must have had lower CSNs and all changes reported in later sessions must have higher CSNs. Some LDUPers didn't want to require in order sending within a session and I'm okay with that since we can allow for it without breaking consistency. Any of the following replication consumer strategies will ensure eventual consistency. 1) Receive the primitives into temporary storage, sort them, then start applying them in order, progressively updating the Update Vector, and committing to the database after each group of primitives with the same CSN (i.e. each operation). Send the final Update Vector back to the supplier at the end. If there is a failure part way through the consumer will start from where it got up to, on the next replication session. 2) Run the replication session as a single local transaction. Apply the primitives as they arrive, but don't commit the transaction until the end. The new Update Vector is committed as part of the transaction before being sent back to the supplier. If there is a failure part way through, the transaction is rolled back (or not recovered on restart). The consumer will start from the same point as the previous (failed) session, on the next replication session. 3) Apply the primitives as they arrive, committing after each operation group, but don't change the Update Vector until the end. If there is a failure part way through, the consumer's Update Vector won't have changed, so the supplier will send the same set of primitives on the next replication session. URP handles primitives that are repeated or out of sequence so the correct final outcome will be reached. The consumer must not send any primitives from a failed session to any other server but that is easy to prevent. These primitives will have CSNs greater than the current local Update Vector. 4) Receive the primitives into persistent temporary storage and return a revised Update Vector straight away. The consumer then applies the primitives to the DIB at its leisure. In any subsequent replication session where it acts as the supplier the server would have to be able to send primitives still residing only in the temporary store. [snip] > My proposal, based on a similar vector to the current LDUP drafts, > does take account of the purging mechanism - it > prevents a purge at *any* replica until after *every* replica has > received the change. It does so, precisely for the reason you > mentioned. But if you restore any server from an old backup then the correctness of the purging mechanism is compromised because you have introduced a server that appears as though it hasn't received changes that the other servers were previously told it had. Suppose some entry E is at version 1 when I take backups of a set of replicas. As time passes, entry E is progressively updated and successive versions eventually become durable. Let's suppose that the durable version of E is version 53 when one of the replicas dies, forcing a restore. In its restored database, entry E has the version 1. The restored server will now receive changes referencing version 54+. I could see nothing in MDCR that would allow the restored server to bridge the gap between version 1 and version 53 of entry E. The sequence of changes up to version 53 have been lost to purging. > > The solution I proposed is based on existing implementations > (Coda and AD) that have been thoroughly researched and tested > and are known to work and to have a number of advantages. For > marketing purposes, AD also describes that as "state based" > rather than "log based", by coyly calling the log an "index". I prefer > to stick to the technical necessities and leave marketing doubletalk > to others. > > That proposal separates report propagation from update > processing and so > would be equally applicable to URP or MDCR. It also enables a natural > transition from single master to multi-master implementations > instead of > attempting to force implementation of multi-master as the current LDUP > proposals do. > > The Coda mechanism relies on the fact that change reports are > transmitted > in order and relies on version numbers rather than timestamps. > > If it used timestamps it would not work because clocks cannot be > guaranteed monotonic. > > If you have some other mechanism that can also be proved to > work, but is > somehow able to do it using timestamps and changes > transmitted in random > order, > that's quite an achievement as the Coda research was quite a > major project. > I look forward to reading the draft but repeat my > recommendation that you > study the Coda research. > > As already stated, I do not believe this is a fundamental problem > inherent in URP, since URP need not rely on timestamps. > > There may well be other and better ways to do it, as long as we are > agreed that it MUST be done. My description was certainly incomplete, > as a protocol for determining which replicas are currently active > and which are excluded is necessary for any method. I wrote it > because in the current proposals the mechanism was not merely > incomplete but absent, and there was explicit language about > dropping updates. When I checked back to the requirements I found > that what I thought was common ground in assuming a requirement for > eventual convergence, was so vague that simply dropping updates > and leaving replicas with different states for the same entries > could arguably be consistent with the stated requirements. [snip] > The current wording says the scope includes two models, "Eventual > Consistency" and "Limited Effort Eventual Consistency", defining the > latter as "where replicas may purge updates therefore dropping > propagation changes when some replica time boundary is exceeded, thus > leaving some changes replicated to a portion of the replica topology". > > Instead of ruling out the second, it explicitly says "LADP replication > should be flexible enough to cover the above range of capabilities". > The actual current drafts do "purge updates therefore > dropping propagation > changes when some replica time boundary is exceeded, thus leaving some > changes replicated to a portion of the replica topology." > > A requirement "to be flexible enough to cover this" is "simply > absurd". That is really an understatement. > > Are we agreed that the final requirements draft should unambiguously > require eventual convergence under ALL circumstances? I agree. It's been my working assumption from the beginning. [snip] > [Issue E - modifiersName] [snip] > You've over estimated the utility of the modifiersName attribute. > It only tells you who last changed something, not what they changed. > > [snip] > > [Albert] > On a single master system, "modifiersName" tells you that what they > changed is what was in the entry immediately before the change and > what they could have read before making that change. If it wasn't > broken before, then it broke because of that change by that DUA. Not necessarily. There could have been any number of updates prior to the latest one identifying the modifiersName. Any one of these could be responsible for "breaking" the entry. [snip] Regards, Steven From owner-ietf-ldup@mail.imc.org Tue Aug 15 01:53:36 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01872 for ; Tue, 15 Aug 2000 01:53:35 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id WAA22273 for ietf-ldup-bks; Mon, 14 Aug 2000 22:27:46 -0700 (PDT) Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA22268 for ; Mon, 14 Aug 2000 22:27:43 -0700 (PDT) Received: (qmail 18270 invoked from network); 15 Aug 2000 05:27:40 -0000 Received: from unknown (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 15 Aug 2000 05:27:40 -0000 Reply-To: From: "Steven Legg" To: "'Zachary Amsden'" , Cc: Subject: RE: 10. "Report propagation sequence" Date: Tue, 15 Aug 2000 15:30:16 +1000 Message-ID: <000601c00679$e5464110$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 In-Reply-To: <200008072356.AAA03163@mail.mirapoint.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Zach, > What really worried me about the current phrasing of the draft > was the fact that no ordering requirements were made at all > within a transmission. This causes severe problems when a > replication update is interrupted. > > I'm not so much worried about bandwidth, but the following > scenario: > > Replica A sends a very long partial update to replica B. > Somewhere in the middle of the transfer, the connection is > terminated. Since we can get CSNs out of order within a > replica ID, we have three options: > 1) Save all changes until the transfer is complete, then > commit them and send an end replication response. This > still worries me because committing the changes may > take a very long time, during which our peer may decide > we are dead, and drop the connection. The ReplicationUpdate operations aren't individually acknowledged (as far as I can see) so the supplier isn't going to see much difference whether the consumer sucks in all changes and then applies them, or applies them one at a time. In fact, applying all the changes in one database transaction will probably be faster overall. Suppliers really have to assume that consumer processing will take significantly longer than supplier processing. Even if the connection is dropped the consumer can continue to process the changes and revise the Update Vector appropriately if the EndReplicationRequest has been received. The supplier will find out the new vector on the next replication session and will avoid resending any already applied changes. > 2) Commit changes as we get them. Very problematic, since > there is nothing prohibiting LDAP updates to our local > replica while we are in a replication session. So when > the connection dies, we have no idea what the current > update vector for our replica is, and we can't easily > back out changes because we may have received updates. If changes are applied in delivery order then the update vector must not be revised with respect to the received changes until the end of the replication session. However, the update vector would still be revised for each locally executed LDAP update. If the connection fails then the update vector is what it was at the start of the session except for the server's own record in the vector, which may have higher CSNs. > 3) Lock down our local replica from updates during the > replication process. For some LDAP applications, this > will not be an option. We may not know which replica > to send update referrals too, or our clients may not > be able to chase referrals for any number of reasons. > Not only this, but if the connection does die, we can't > allow updates until replication is re-established with > the same supplier, or we revert all the changes and > restore to a known state. > > Since there isn't actually enough information in a change > record to undo the change, any server crash during this > process is rather disastrous. This means we need to store a > reverse operation for each change as well. Isn't this the same problem as a crash during an LDAP client update ? There is a set of changes to be applied atomically to the local database. Either all the changes occur or none do. Do you have a problem scaling this up to encompass a whole replication session ? Or is this option describing a solution that doesn't have atomic commits to the underlying database. That's scary to me even without replication. > > These are the kind of warts I would like to avoid in the LDUP > protocol. > > Zach > Regards, Steven From owner-ietf-ldup@mail.imc.org Tue Aug 15 19:47:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00585 for ; Tue, 15 Aug 2000 19:47:56 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA17874 for ietf-ldup-bks; Tue, 15 Aug 2000 16:24:29 -0700 (PDT) Received: from mail.mirapoint.com (IDENT:mirapoint@mail.mirapoint.com [208.48.74.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA17869 for ; Tue, 15 Aug 2000 16:24:27 -0700 (PDT) Received: from mail.mirapoint.com (localhost.mirapoint.com [127.0.0.1]) by mail.mirapoint.com (Mirapoint) with SMTP id AAA33740; Tue, 15 Aug 2000 16:23:43 -0700 (PDT) Message-Id: <200008152323.AAA33740@mail.mirapoint.com> Received: from 127.0.0.1 by mail.mirapoint.com with HTTPS/1.1; Tue, 15 Aug 2000 16:23:44 -0700 Date: Tue, 15 Aug 2000 16:23:44 -0700 From: Zachary Amsden Subject: RE: 10. "Report propagation sequence" To: steven.legg@adacel.com.au Cc: "'Zachary Amsden'" , Albert.Langer@directory-designs.org, ietf-ldup@imc.org X-Mailer: Mirapoint Webmail Direct 2.7.0.22 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 ---- Original message ---- >Date: Tue, 15 Aug 2000 15:30:16 +1000 >From: "Steven Legg" >Subject: RE: 10. "Report propagation sequence" >To: "'Zachary Amsden'" , >Cc: >> What really worried me about the current phrasing of the draft >> was the fact that no ordering requirements were made at all >> within a transmission. This causes severe problems when a >> replication update is interrupted. >> >> I'm not so much worried about bandwidth, but the following >> scenario: >> >> Replica A sends a very long partial update to replica B. >> Somewhere in the middle of the transfer, the connection is >> terminated. Since we can get CSNs out of order within a >> replica ID, we have three options: >> 1) Save all changes until the transfer is complete, then >> commit them and send an end replication response. This >> still worries me because committing the changes may >> take a very long time, during which our peer may decide >> we are dead, and drop the connection. > >The ReplicationUpdate operations aren't individually acknowledged >(as far as I can see) so the supplier isn't going to see much difference >whether the consumer sucks in all changes and then applies them, or >applies them one at a time. In fact, applying all the changes in >one database transaction will probably be faster overall. Suppliers >really have to assume that consumer processing will take significantly >longer than supplier processing. >Even if the connection is dropped the consumer can continue to process >the changes and revise the Update Vector appropriately if the >EndReplicationRequest has been received. The supplier will find out >the new vector on the next replication session and will avoid resending >any already applied changes. Agree, but there are other problems with approach 1, which I discuss below. >> 2) Commit changes as we get them. Very problematic, since >> there is nothing prohibiting LDAP updates to our local >> replica while we are in a replication session. So when >> the connection dies, we have no idea what the current >> update vector for our replica is, and we can't easily >> back out changes because we may have received updates. > >If changes are applied in delivery order then the update vector must >not be revised with respect to the received changes until the end of the >replication session. However, the update vector would still be revised >for each locally executed LDAP update. If the connection fails then >the update vector is what it was at the start of the session except >for the server's own record in the vector, which may have higher CSNs. If changes are applied in delivery order, then there is no issue. The update vector on the supplier is of no concern, since we send our vector at the beginning of a replication session. If, however, changes have no particular ordering, then 2 is not an option. >> 3) Lock down our local replica from updates during the >> replication process. For some LDAP applications, this >> will not be an option. We may not know which replica >> to send update referrals too, or our clients may not >> be able to chase referrals for any number of reasons. >> Not only this, but if the connection does die, we can't >> allow updates until replication is re-established with >> the same supplier, or we revert all the changes and >> restore to a known state. >> >> Since there isn't actually enough information in a change >> record to undo the change, any server crash during this >> process is rather disastrous. This means we need to store a >> reverse operation for each change as well. > >Isn't this the same problem as a crash during an LDAP client update ? >There is a set of changes to be applied atomically to the local >database. Either all the changes occur or none do. Do you have >a problem scaling this up to encompass a whole replication session ? >Or is this option describing a solution that doesn't have >atomic commits to the underlying database. That's scary to me even >without replication. Well yes, there is a problem scaling that up to encompass an entire (total) replication session. That isn't the real issue, and that is fixable. What isn't fixable is that during a total update, none of the data is available for read during replication. We would like the database to be live (albeit read-only) during a total update. Perhaps allowing read-write access during a total update is possible, but that would be a future step. We've hashed over the ordering issue, and I don't think there are any problems transmitting changes in delivery order for any server implementation. Not only that, but using ordering gives you a number of other properites (read access of changes during update, parents created before children, easy recovery from aborted updates, better DSA crash recovery), which make any implementation either easier or more robust. I'd like to know if we have a concensus that changes, whatever format they may be transmitted in, should be ordered by delivery order. Zach From owner-ietf-ldup@mail.imc.org Tue Aug 15 22:42:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05107 for ; Tue, 15 Aug 2000 22:42:56 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id TAA00458 for ietf-ldup-bks; Tue, 15 Aug 2000 19:15:09 -0700 (PDT) Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA00441 for ; Tue, 15 Aug 2000 19:15:04 -0700 (PDT) Received: (qmail 21353 invoked from network); 16 Aug 2000 02:15:13 -0000 Received: from unknown (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 16 Aug 2000 02:15:13 -0000 Reply-To: From: "Steven Legg" To: "'Zachary Amsden'" Cc: , Subject: RE: 10. "Report propagation sequence" Date: Wed, 16 Aug 2000 12:17:40 +1000 Message-ID: <000101c00728$28291080$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 In-Reply-To: <200008152323.AAA33740@mail.mirapoint.com> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V4.72.2120.0 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Zach, > -----Original Message----- > From: Zachary Amsden [mailto:zach@mirapoint.com] > Sent: Wednesday, 16 August 2000 9:24 > To: steven.legg@adacel.com.au > Cc: 'Zachary Amsden'; Albert.Langer@directory-designs.org; > ietf-ldup@imc.org > Subject: RE: 10. "Report propagation sequence" > > > ---- Original message ---- > >Date: Tue, 15 Aug 2000 15:30:16 +1000 > >From: "Steven Legg" > >Subject: RE: 10. "Report propagation sequence" > >To: "'Zachary Amsden'" , > > >Cc: > > >> What really worried me about the current phrasing of the draft > >> was the fact that no ordering requirements were made at all > >> within a transmission. This causes severe problems when a > >> replication update is interrupted. > >> > >> I'm not so much worried about bandwidth, but the following > >> scenario: > >> > >> Replica A sends a very long partial update to replica B. > >> Somewhere in the middle of the transfer, the connection is > >> terminated. Since we can get CSNs out of order within a > >> replica ID, we have three options: > >> 1) Save all changes until the transfer is complete, then > >> commit them and send an end replication response. This > >> still worries me because committing the changes may > >> take a very long time, during which our peer may decide > >> we are dead, and drop the connection. > > > >The ReplicationUpdate operations aren't individually acknowledged > >(as far as I can see) so the supplier isn't going to see > much difference > >whether the consumer sucks in all changes and then applies them, or > >applies them one at a time. In fact, applying all the changes in > >one database transaction will probably be faster overall. Suppliers > >really have to assume that consumer processing will take > significantly > >longer than supplier processing. > > >Even if the connection is dropped the consumer can continue > to process > >the changes and revise the Update Vector appropriately if the > >EndReplicationRequest has been received. The supplier will find out > >the new vector on the next replication session and will > avoid resending > >any already applied changes. > > Agree, but there are other problems with approach 1, which I > discuss below. > > >> 2) Commit changes as we get them. Very problematic, since > >> there is nothing prohibiting LDAP updates to our local > >> replica while we are in a replication session. So when > >> the connection dies, we have no idea what the current > >> update vector for our replica is, and we can't easily > >> back out changes because we may have received updates. > > > >If changes are applied in delivery order then the update vector must > >not be revised with respect to the received changes until > the end of the > >replication session. However, the update vector would still > be revised > >for each locally executed LDAP update. If the connection fails then > >the update vector is what it was at the start of the session except > >for the server's own record in the vector, which may have > higher CSNs. > > If changes are applied in delivery order, then there is no issue. Delivery order is the order the consumer sees them, which in the current proposals is unsorted. It was unsorted delivery that I was addressing. > The > update vector on the supplier is of no concern, since we send > our vector at > the beginning of a replication session. I wasn't talking about the supplier's Update Vector. All the references to the Update Vector in my comments following option 2 were about the consumer's update vector. > If, however, changes have no > particular ordering, then 2 is not an option. Option 2 is viable with unordered changes in the way I've described. It just requires some care in revising the consumer's Update Vector. > > >> 3) Lock down our local replica from updates during the > >> replication process. For some LDAP applications, this > >> will not be an option. We may not know which replica > >> to send update referrals too, or our clients may not > >> be able to chase referrals for any number of reasons. > >> Not only this, but if the connection does die, we can't > >> allow updates until replication is re-established with > >> the same supplier, or we revert all the changes and > >> restore to a known state. > >> > >> Since there isn't actually enough information in a change > >> record to undo the change, any server crash during this > >> process is rather disastrous. This means we need to store a > >> reverse operation for each change as well. > > > >Isn't this the same problem as a crash during an LDAP client update ? > >There is a set of changes to be applied atomically to the local > >database. Either all the changes occur or none do. Do you have > >a problem scaling this up to encompass a whole replication session ? > >Or is this option describing a solution that doesn't have > >atomic commits to the underlying database. That's scary to me even > >without replication. > > Well yes, there is a problem scaling that up to encompass an > entire (total) > replication session. That isn't the real issue, and that is > fixable. What > isn't fixable is that during a total update, none of the data > is available > for read during replication. Which is a good reason for applying and committing the replication changes (total or incremental) a little at a time. Local reads and updates can then be interleaved with the replication processing. However this can be achieved regardless of whether the replicated changes are ordered. > We would like the database to > be live (albeit > read-only) during a total update. Perhaps allowing read-write access > during a total update is possible, but that would be a future step. > > We've hashed over the ordering issue, and I don't think there are any > problems transmitting changes in delivery order for any server > implementation. Not only that, but using ordering gives you > a number of > other properites (read access of changes during update, Local read and update access during replication sessions can be provided either way. > parents created > before children, To guarantee that changes adding a parent arrive before changes adding a child, the suppliers would have to send changes in the same order they were received or executed locally. It wouldn't be enough to send changes in order per replica ID. Implementors with state-based servers won't like the extra overhead of preserving that order. URP easily handles children that arrive before the parent so it's not a serious concern anyway. > easy recovery from aborted updates, better DSA crash > recovery), which make any implementation either easier or more robust. I don't see a significant difference in implementation either way. It all comes down to a question of when the consumer's Update Vector is revised, and whether outgoing changes are tested against the current Update Vector. There is a difference in the amount of traffic following interrupted sessions but I expect those to be rare events, and of no concern where the replication agreements specify on-change replication. > I'd like to know if we have a concensus that changes, > whatever format they > may be transmitted in, should be ordered by delivery order. There would seem to be four choices: 1) unordered within session, 2) ordered on CSN per replica ID, 3) ordered on CSN, 4) ordered on supplier receipt order. Those vendors wanting unordered transmission should speak up now. I'm happy with 1, 2 or 3. > > Zach > Regards, Steven From owner-ietf-ldup@mail.imc.org Tue Aug 15 23:15:46 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05482 for ; Tue, 15 Aug 2000 23:15:46 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id TAA04409 for ietf-ldup-bks; Tue, 15 Aug 2000 19:52:54 -0700 (PDT) Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA04394 for ; Tue, 15 Aug 2000 19:52:50 -0700 (PDT) Received: (qmail 24189 invoked from network); 16 Aug 2000 02:52:55 -0000 Received: from unknown (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 16 Aug 2000 02:52:55 -0000 Reply-To: From: "Steven Legg" To: "'Zachary Amsden'" , Cc: Subject: RE: more proposed protocol changes Date: Wed, 16 Aug 2000 12:55:22 +1000 Message-ID: <000201c0072d$6c41fac0$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 In-Reply-To: <200008032203.AAA19274@mail.mirapoint.com> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V4.72.2120.0 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Zach, > -----Original Message----- > From: owner-ietf-ldup@mail.imc.org > [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Zachary Amsden > Sent: Friday, 4 August 2000 8:03 > To: d.w.chadwick@salford.ac.uk > Cc: ietf-ldup@imc.org > Subject: Re: more proposed protocol changes > > > You are correct. That is why I explicitly specified that you > would also need a semantical change, "under no circumstances > should the update vector passed from a consumer to a supplier > via a startReplicationResponse be interpreted as the current > update vector of that consumer". Rather, it is an "update > vector request". You can instead use the update vector > returned from either a replicationUpdateResponse, or an > endReplicationResponse. It actually makes more sense to use > that value anyway, since you will need to commit that update > vector as your known update vector for that consumer, since > you need to have confirmation that the consumer has committed > all the changes sent to it. I don't like this idea of passing on vectors to other suppliers because it creates a dependency between concurrent replication sessions. If the first supplier's replication session fails then the second and subsequent suppliers' replication sessions must also fail because they will have omitted changes that the consumer didn't end up getting from the first supplier. Furthermore, the consumer must not revise it's Update Vector due to the processing of changes from the second and subsequent suppliers until the first supplier's replication session is successfully concluded (so the other replication sessions can't finish until after the first one does). I think it is better for each supplier to send all the required changes so that their sessions can independently succeed or fail. This is an issue of traffic volume rather than consumer load since URP quickly dispenses with replication primitives that make no change to the DIB because they have been processed before (e.g. through one of the other sessions). > In any case, I don't think it is necessary to actually forbid > a consumer from taking having concurrent partial updates to > the same replica, as it states in the architecture draft. I don't think we need to forbid concurrent replication sessions either, though implementations should have the option to decline a second replication session. Regards, Steven > > ---- Original message ---- > >Date: Thu, 3 Aug 2000 13:38:55 +0100 > >From: "David Chadwick" > >Subject: Re: more proposed protocol changes > >To: Zachary Amsden , ietf-ldup@imc.org > >Cc: > > > >Date sent: Mon, 31 Jul 2000 17:05:30 -0700 > >From: Zachary Amsden > >Subject: more proposed protocol changes > >To: ietf-ldup@imc.org > > > >> To accomodate simultanaeous LDUP partial updates to > >> the same replica, it would make sense to allow the sender > to > >> optionally send an update vector containing describing the > >> CSNs it is about to send. This could be passed back to > other > >> suppliers for the same replica in the > startReplicationResponse > >> while the original replication is proceeding. > > > >Zachary > > > >I worry about this sort of procedure, since the consumer is > saying > >to the other suppliers that it has received the updates (from > the first > >supplier) before it actually has. Once these suppliers store > that > >update vector they will never attempt to update the consumer > with > >these updates. Worse than that, if the connection with the > first > >supplier breaks, the consumer now does not have the updates > it > >has told everyone (except the first supplier) that it does > have. What > >if the first supplier replicates with say the third supplier > and gets the > >update vector from it before it restarts it link to the > consumer. The > >first will now think that the consumer has the updates, wont > it? > > > >David > From owner-ietf-ldup@mail.imc.org Thu Aug 17 01:14:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10366 for ; Thu, 17 Aug 2000 01:14:06 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id VAA10208 for ietf-ldup-bks; Wed, 16 Aug 2000 21:44:00 -0700 (PDT) Received: from mail.mirapoint.com (IDENT:mirapoint@mail.mirapoint.com [208.48.74.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA10200 for ; Wed, 16 Aug 2000 21:43:54 -0700 (PDT) Received: from mail.mirapoint.com (localhost.mirapoint.com [127.0.0.1]) by mail.mirapoint.com (Mirapoint) with SMTP id AAB05120; Wed, 16 Aug 2000 21:43:20 -0700 (PDT) Message-Id: <200008170443.AAB05120@mail.mirapoint.com> Received: from 127.0.0.1 by mail.mirapoint.com with HTTPS/1.1; Wed, 16 Aug 2000 21:43:23 -0700 Date: Wed, 16 Aug 2000 21:43:23 -0700 From: Zachary Amsden Subject: RE: 10. "Report propagation sequence" To: steven.legg@adacel.com.au Cc: "'Zachary Amsden'" , Albert.Langer@directory-designs.org, ietf-ldup@imc.org X-Mailer: Mirapoint Webmail Direct 2.7.0.25 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 >> >If changes are applied in delivery order then the update vector must >> >not be revised with respect to the received changes until >> the end of the >> >replication session. However, the update vector would still >> be revised >> >for each locally executed LDAP update. If the connection fails then >> >the update vector is what it was at the start of the session except >> >for the server's own record in the vector, which may have >> higher CSNs. >Option 2 is viable with unordered changes in the way I've described. >It just requires some care in revising the consumer's Update Vector. So the consumer doesn't change it's update vector, and ignores duplicate CSNs which it encounters. Ok, that works, but seems to violate intuition. It seems to me that the update vector is a snapshot of the database sync state. Having higher CSNs in the database than the update vector doesn't fit that model. Allowing out of sync CSNs in the database seems to be inviting conflicts, and adding unneeded complexity. >To guarantee that changes adding a parent arrive before changes >adding a child, the suppliers would have to send changes in the >same order they were received or executed locally. It wouldn't be >enough to send changes in order per replica ID. Implementors with >state-based servers won't like the extra overhead of preserving >that order. URP easily handles children that arrive before the >parent so it's not a serious concern anyway. If they have no index of changed entries, then they need to walk the entire database for each replication. I seriously doubt anyone is going to do that. If they do have an index, that can easily be extended to preserve order. Actually, all you need are two records: last-change and first-change. Each change contains the key of the next change. Then local updates update last-change, and replication walks from either first change, or a per-replica high-water mark. >> easy recovery from aborted updates, better DSA crash >> recovery), which make any implementation either easier or more robust. > >I don't see a significant difference in implementation either way. It all >comes down to a question of when the consumer's Update Vector is revised, >and whether outgoing changes are tested against the current Update Vector. >There is a difference in the amount of traffic following interrupted >sessions but I expect those to be rare events, and of no concern where >the replication agreements specify on-change replication. I'm not really concerned with traffic either. I am concerned that sending unordered changes seriously adds to the complexity of URP, testing and debugging the whole thing. >> I'd like to know if we have a concensus that changes, >> whatever format they >> may be transmitted in, should be ordered by delivery order. > >There would seem to be four choices: >1) unordered within session, >2) ordered on CSN per replica ID, >3) ordered on CSN, >4) ordered on supplier receipt order. If you can order on CSN, how much harder can it be to order on local receipt order? >Those vendors wanting unordered transmission should speak up now. >I'm happy with 1, 2 or 3. I'm very unhappy with 1, only moderately happy with 2 or 3. Zach From owner-ietf-ldup@mail.imc.org Thu Aug 17 13:47:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01329 for ; Thu, 17 Aug 2000 13:47:17 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA26629 for ietf-ldup-bks; Thu, 17 Aug 2000 10:08:29 -0700 (PDT) Received: from mail.yourdomain.com (m319-mp1-cvx1a.man.ntl.com [62.252.197.63]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA26173; Thu, 17 Aug 2000 09:58:55 -0700 (PDT) From: announce@leisurewebcams.com Message-Id: <200008171658.JAA26173@ns.secondary.com> Date: Thu, 17 Aug 2000 14:23:35 Subject: LeisureWebcams.com - See the World Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: LeisureWebcams.com is a recently launched website specialising in providing free LIVE access to over 1,500 webcams and 2,000 Tourist Offices world wide. Check it out:- http://www.leisurewebcams.com/ This offers you the chance to check out live and frequently updated images of your chosen location through the webcams and get detailed local knowledge through the Tourist Offices. Along with booking holidays direct through our travel partner, there is the opportunity to sell your unwanted clothes and equipment through our free Swap Shop. There is a lot to see, so if you have enjoyed your trip through our site, do tell your friends and let us know through 'Your Views'. If you have any suggestions for the site, or queries, please feel free to contact me at cy@LeisureWebcams.com. I look forward to hearing from you. Kind regards, Charlie Yates MARKETING DIRECTOR LeisureWebcams.com From owner-ietf-ldup@mail.imc.org Sun Aug 20 21:58:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13002 for ; Sun, 20 Aug 2000 21:58:20 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id SAA07509 for ietf-ldup-bks; Sun, 20 Aug 2000 18:01:00 -0700 (PDT) Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA07502 for ; Sun, 20 Aug 2000 18:00:57 -0700 (PDT) Received: (qmail 3769 invoked from network); 21 Aug 2000 01:01:56 -0000 Received: from unknown (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 21 Aug 2000 01:01:56 -0000 Reply-To: From: "Steven Legg" To: "'Zachary Amsden'" Cc: Subject: RE: 10. "Report propagation sequence" Date: Mon, 21 Aug 2000 11:03:58 +1000 Message-ID: <000001c00b0b$b0b45d10$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: <200008170443.AAB05120@mail.mirapoint.com> Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Zach, > -----Original Message----- > From: Zachary Amsden [mailto:zach@mirapoint.com] > Sent: Thursday, 17 August 2000 14:43 > To: steven.legg@adacel.com.au > Cc: 'Zachary Amsden'; Albert.Langer@directory-designs.org; > ietf-ldup@imc.org > Subject: RE: 10. "Report propagation sequence" > > > >> >If changes are applied in delivery order then the update > vector must > >> >not be revised with respect to the received changes until > >> the end of the > >> >replication session. However, the update vector would still > >> be revised > >> >for each locally executed LDAP update. If the connection > fails then > >> >the update vector is what it was at the start of the > session except > >> >for the server's own record in the vector, which may have > >> higher CSNs. > > >Option 2 is viable with unordered changes in the way I've described. > >It just requires some care in revising the consumer's Update Vector. > > So the consumer doesn't change it's update vector, and > ignores duplicate > CSNs which it encounters. Ok, that works, but seems to > violate intuition. > It seems to me that the update vector is a snapshot of the > database sync > state. Having higher CSNs in the database than the update > vector doesn't > fit that model. Allowing out of sync CSNs in the database seems to be > inviting conflicts, and adding unneeded complexity. I look at the update vector as only a change propagation mechanism. I tells us that the contiguous set of changes from a replica up to the CSN in the vector have been received. We may have received later changes but we can't yet guarantee there are no gaps in the sequence for those. > > >To guarantee that changes adding a parent arrive before changes > >adding a child, the suppliers would have to send changes in the > >same order they were received or executed locally. It wouldn't be > >enough to send changes in order per replica ID. Implementors with > >state-based servers won't like the extra overhead of preserving > >that order. URP easily handles children that arrive before the > >parent so it's not a serious concern anyway. > > If they have no index of changed entries, then they need to > walk the entire > database for each replication. I seriously doubt anyone is > going to do > that. If they do have an index, that can easily be extended > to preserve > order. Actually, all you need are two records: last-change and > first-change. Each change contains the key of the next > change. Then local > updates update last-change, and replication walks from either > first change, > or a per-replica high-water mark. Where ever the information on receipt order is stored it has to be part of the persistent database state. If it is only in the index then that index must be part of the persistent database. With options 2 and 3 there is enough information from the data stored anyway for URP processing to build the index. A state-based implementation could choose to keep the index in temporary memory and rebuild it on restarts by walking the database. > > >> easy recovery from aborted updates, better DSA crash > >> recovery), which make any implementation either easier or > more robust. > > > >I don't see a significant difference in implementation > either way. It all > >comes down to a question of when the consumer's Update > Vector is revised, > >and whether outgoing changes are tested against the current > Update Vector. > >There is a difference in the amount of traffic following interrupted > >sessions but I expect those to be rare events, and of no > concern where > >the replication agreements specify on-change replication. > > I'm not really concerned with traffic either. I am concerned > that sending > unordered changes seriously adds to the complexity of URP, testing and > debugging the whole thing. URP is designed to deal with out-of-order changes from different servers, which is inevitable for multi-master replication. Handling out-of-order changes from the one server isn't a significantly different problem. I can't think of anything in URP that could be simplified by insisting that changes are in some order. Insisting on receipt order would prevent children arriving before parents but that situation is seamlessly handled by the more general support for orphaned entries and conflicting move operations. No ordering would make it possible to eliminate the support for orphaned entries and conflicting moves, so knowing that parents will arrive before children doesn't change anything. > > >> I'd like to know if we have a concensus that changes, > >> whatever format they > >> may be transmitted in, should be ordered by delivery order. > > > >There would seem to be four choices: > >1) unordered within session, > >2) ordered on CSN per replica ID, > >3) ordered on CSN, > >4) ordered on supplier receipt order. > > If you can order on CSN, how much harder can it be to order on local > receipt order? I don't like option 4 because it requires extra information (beyond URP) to be persistently stored in the database, but doesn't provide any real advantage from doing so. > > >Those vendors wanting unordered transmission should speak up now. > >I'm happy with 1, 2 or 3. > > I'm very unhappy with 1, only moderately happy with 2 or 3. Does that mean you are happiest with 4 ? Regards, Steven > > Zach > From owner-ietf-ldup@mail.imc.org Wed Aug 30 04:30:45 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22243 for ; Wed, 30 Aug 2000 04:30:44 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id BAA01804 for ietf-ldup-bks; Wed, 30 Aug 2000 01:01:28 -0700 (PDT) Received: from sendflowersamerica.com ([206.168.43.194]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA01618; Wed, 30 Aug 2000 01:00:01 -0700 (PDT) From: sfaquestions@sendflowersamerica.com Subject: FlowerFunds - Fund Raising Program Date: Wed, 30 Aug 2000 01:32:17 Message-Id: <620.108063.29555@sendflowersamerica.com> Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: SendFlowersAmerica is proud to introduce FlowerFunds-- This unique new concept will provide an income flow for your organization for years to come. Your organization is invited to explore the possibilities of participating in FlowerFunds. $FlowerFunds is an individualized fund raising program for non-profit organizations and schools. $FlowerFunds are cash rebates that are paid to your organization each and every time an order is placed by your members and supporters. $The best part is that it costs your organization nothing to participate!! How it works: 1. When your members and supporters order flowers or gifts through sendflowersamerica they determine the price they want to pay; be it $30, $40, $50 or $1000. Since your members and supporters determine the price, they all can participate in this program. 2. Your organization receives 20% of the purchase price of the order. Say a husband buys his wife a $50 bouquet. Your organization will receive a $10 cash rebate. Nice. This program never ends. Each and every time there is an order placed by your memebers and supporters, your organization will receive the 20% cash rebate. That's a lot of FlowerFunds, and your organization stands to benefit from a findraiser unlike any other fundraiser. For more information call 1 800 SEND 123 or http://www.sendflowersamerica.com Imagine earning money for your organization by making someone smile :-)