From owner-ietf-ldup@mail.imc.org Sun Jul 2 21:33: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 VAA12164 for ; Sun, 2 Jul 2000 21:33:07 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id SAA19075 for ietf-ldup-bks; Sun, 2 Jul 2000 18:01:03 -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 SAA19060 for ; Sun, 2 Jul 2000 18:01:00 -0700 (PDT) Received: (qmail 9430 invoked from network); 3 Jul 2000 01:01:54 -0000 Received: from softdnserror (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 3 Jul 2000 01:01:54 -0000 Reply-To: From: "Steven Legg" To: "'Haripriya S'" Cc: , Subject: RE: various comments (was Re: What's going on? - Status ofRequirements...) Date: Mon, 3 Jul 2000 11:04:35 +1000 Message-ID: <000301bfe48a$a8280cc0$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: Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, The remaining (N - M) replicas would not be allowed to perform any strong consistency updates because they wouldn't be able to obtain a quorum of M replicas: M > N/2 implies (N-M) < M . However, loose consistency updates would be allowed at the (N-M) replicas, which might invalidate strong consistency updates performed by the M replicas. I would regard this as a case of one application stomping over another application because it is unaware/uncaring of the second application's semantics and constraints. This sort of thing is a problem even in the single master case, though admittedly the multi-master case raises some situations that wouldn't occur on a single master. My original thought was to allow applications to request whether or not their operations should be executed with strong consistency, but I think it would also be useful if applications and/or administrators could register what entries or attributes they want the server(s) to protect by insisting that ALL operations against those directory items, even those explicitly requesting loose consistency, are performed with strong consistency. In this way an application could block loose consistency updates in any currently inaccessable (N-M) subset of the replicas. Regards, Steven > -----Original Message----- > From: Haripriya S [mailto:SHARIPRIYA@novell.com] > Sent: Friday, 30 June 2000 16:08 > To: steven.legg@adacel.com.au > Subject: RE: various comments (was Re: What's going on? - Status > ofRequirements...) > > > Hi, > > What happens in this case where there are N replicas and only > M are connected to the given primary at this time? In this > case, will it not be the case that the remaining N - M > replicas could have changed an entry in the transaction with > a later timestamp, and could also be servicing a client for > this data? Or am I missing something? > > Thanks and Regards, > Haripriya S. > > [snip] > > This is the sequence of events for a user update request requiring or > requesting strong consistency: > > The receiving replica (let's call it the primary) opens a session with > each of the other replicas and sends a request for all update > primitives > up to and including the latest change to the target entry. > This is just a > variation on a regular LDUP session. However the other > replicas will also > lock the target entry to prevent any local changes to it. Some sort of > deadlock detection will be necessary. > > The primary replica applies all the primitives it has > received and then > attempts the user request. If it fails with an error the sessions with > the other replicas are closed and they drop the locks on the > target entry. > If the request succeeds the primary server sends > the primitives up to and including the ones generated from the current > user request, then closes the sessions causing the locks to be > released. If the primary doesn't send the latest primitives the other > replicas will just import them the next time they action a strong > consistency update on the same entry. Two-phase commit isn't required. > > Handling transactions is straightforward. The initial request from the > primary replica specifies a range of affected entries (maybe with > something like a search filter) instead of just the one target entry. > The primary is also allowed to send multiple requests within the same > session since it won't generally know all the entries affected by > a transaction at the beginning. > > The above scheme requires all updatable replicas to be > available to perform > a strong consistency update but there is a more general scheme that > allows some of the replicas to be unavailable. If there are N replicas > then it is only necessary to contact M (M > N/2) of them to > make an update > provided N-M+1 of them are contacted before evaluating any strong > consistency query. The original description was the special > case of M = N. > > [snip] > > > From owner-ietf-ldup@mail.imc.org Mon Jul 3 13:03: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 NAA04916 for ; Mon, 3 Jul 2000 13:03:45 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA23727 for ietf-ldup-bks; Mon, 3 Jul 2000 09:24:35 -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 JAA23723 for ; Mon, 3 Jul 2000 09:24:34 -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 QAA26345; Mon, 3 Jul 2000 16:25:34 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <4.3.2.7.0.20000703085803.00af9a60@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 03 Jul 2000 09:25:32 -0700 To: ietf-ldapext@netscape.com From: "Kurt D. Zeilenga" Subject: LDAP subentry alignment with X.500 subentry Cc: Ed_Reed@novell.com, ietf-ldup@imc.org 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 believe 'LDAPsubentry' should be replaced with with 'subentry' and defined such that it closely modelled after X.500. 1) subentries should have a subtree specifier such that they are more useful for specification of ACI subentries. 2) subentries should be visible based upon presence of a subentries control, not a filter components. For example: (|(&(objectclass=LDAPsubentry)(!(cn=*))(objectclass=*)) Should the subentry be visible or not? There are reasonable arguments for both yes and no. I primarily make these suggestions because I believe these changes would make subentries within LDAP more usable, in particular, when used in support of the access control model. Kurt From owner-ietf-ldup@mail.imc.org Thu Jul 6 07:19:09 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 HAA11993 for ; Thu, 6 Jul 2000 07:19:09 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA15554 for ietf-ldup-bks; Thu, 6 Jul 2000 03:43:17 -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 DAA15550 for ; Thu, 6 Jul 2000 03:43:15 -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 GAA11070; Thu, 6 Jul 2000 06:44:39 -0400 (EDT) Message-Id: <200007061044.GAA11070@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldup-urp-03.txt Date: Thu, 06 Jul 2000 06:44:39 -0400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF. Title : LDUP Update Reconciliation Procedures Author(s) : S. Legg, A. Payne Filename : draft-ietf-ldup-urp-03.txt Pages : 29 Date : 05-Jul-00 This document describes the procedures used by directory servers to reconcile updates performed by autonomously operating directory servers in a distributed, replicated directory service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-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-urp-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-urp-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: <20000705121334.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-urp-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-urp-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000705121334.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Fri Jul 7 11:51: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 LAA00558 for ; Fri, 7 Jul 2000 11:51:48 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA16487 for ietf-ldup-bks; Fri, 7 Jul 2000 08:08:00 -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 IAA16483 for ; Fri, 7 Jul 2000 08:07:58 -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 e67F0ig21616 for ; Fri, 7 Jul 2000 08:00:44 -0700 (PDT) Received: from netscape.com ([192.18.121.200]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FXC22Y02.APB; Fri, 7 Jul 2000 08:08:58 -0700 Message-ID: <3965F2EC.EFE5B84C@netscape.com> Date: Fri, 07 Jul 2000 08:10:36 -0700 From: mcs@netscape.com (Mark C Smith) X-Mailer: Mozilla 4.73 [en]C-AOLNSCP (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-ldapext@netscape.com, ietf-ldup@imc.org, Ed Reed Subject: Re: LDAP subentry alignment with X.500 subentry References: <4.3.2.7.0.20000703085803.00af9a60@infidel.boolean.net> 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 "Kurt D. Zeilenga" wrote: > > I believe 'LDAPsubentry' should be replaced with with 'subentry' and > defined such that it closely modelled after X.500. > > 1) subentries should have a subtree specifier such that they are more > useful for specification of ACI subentries. The X.500 subtree specifier is rich and therefore fairly complex to implement. That doesn't mean we shouldn't adopt it, but it does mean we should consider the impact. > 2) subentries should be visible based upon presence of a subentries control, > not a filter components. For example: > (|(&(objectclass=LDAPsubentry)(!(cn=*))(objectclass=*)) > > Should the subentry be visible or not? There are reasonable arguments > for both yes and no. But controls are of course more costly for clients and servers to implement. What problem are you trying to solve? As currently defined, clients that have knowledge of LDAPsubentries can retrieve them and those that do not won't. That meets my needs. > I primarily make these suggestions because I believe these changes would > make subentries within LDAP more usable, in particular, when used in > support of the access control model. Interesting. Before we throw out the simple LDAPsubentry that Ed has defined, I think someone should list the additional requirements that are needed for the access control effort to successfully use subentries. -- Mark Smith iPlanet From owner-ietf-ldup@mail.imc.org Fri Jul 7 12:32:26 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 MAA02620 for ; Fri, 7 Jul 2000 12:32:24 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA20988 for ietf-ldup-bks; Fri, 7 Jul 2000 09:00: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 JAA20979 for ; Fri, 7 Jul 2000 09:00:47 -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 QAA40303; Fri, 7 Jul 2000 16:01:39 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <4.3.2.7.0.20000707083711.00b1aa00@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 07 Jul 2000 09:01:37 -0700 To: mcs@netscape.com (Mark C Smith) From: "Kurt D. Zeilenga" Subject: Re: LDAP subentry alignment with X.500 subentry Cc: ietf-ldapext@netscape.com, ietf-ldup@imc.org, Ed Reed In-Reply-To: <3965F2EC.EFE5B84C@netscape.com> References: <4.3.2.7.0.20000703085803.00af9a60@infidel.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: At 08:10 AM 7/7/00 -0700, Mark C Smith wrote: >"Kurt D. Zeilenga" wrote: >> >> I believe 'LDAPsubentry' should be replaced with with 'subentry' and >> defined such that it closely modelled after X.500. >> >> 1) subentries should have a subtree specifier such that they are more >> useful for specification of ACI subentries. > >The X.500 subtree specifier is rich and therefore fairly complex to >implement. That doesn't mean we shouldn't adopt it, but it does mean we >should consider the impact. We should consider the impact of implementing something different. LDAP is an access protocol to an X.500 directory. Each divergence from the X.500 information/service models makes increasing difficult to implement servers which supports both LDAP and DAP and gateways between LDAP and DAP. >> 2) subentries should be visible based upon presence of a subentries control, >> not a filter components. For example: >> (|(&(objectclass=LDAPsubentry)(!(cn=*))(objectclass=*)) >> >> Should the subentry be visible or not? There are reasonable arguments >> for both yes and no. > >But controls are of course more costly for clients and servers to >implement. I disagree. A control is actually quite simple to implement and rather cheap (as demonstrated by ManageDsaIT). Interpeting filter side effects in complex and often leads to inconsistent implementations due to ambiguity in the specification of these side effects (as demonstrated by matched-00). The advantage of a control is it provides an unambiguous mechanism to enable the behavior. > What problem are you trying to solve? In terms of the filter comment: ambiguity of specification, consistency of implementation. In terms of subentry v. entry comment: unnecessary incompatible divergence from X.500. >As currently defined, >clients that have knowledge of LDAPsubentries can retrieve them and >those that do not won't. Does the filter above have the side effect of making subentries visible or not? >> I primarily make these suggestions because I believe these changes would >> make subentries within LDAP more usable, in particular, when used in >> support of the access control model. > >Interesting. Before we throw out the simple LDAPsubentry that Ed has >defined, I think someone should list the additional requirements that >are needed for the access control effort to successfully use subentries. To turn the tables a bit, before we through out X.500 subentry, I think someone should list LDUP (or other) requirements which the X.500 subentry mechanism is inadequate. From owner-ietf-ldup@mail.imc.org Fri Jul 7 14:29:37 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 OAA08971 for ; Fri, 7 Jul 2000 14:29:36 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA25030 for ietf-ldup-bks; Fri, 7 Jul 2000 10:53:48 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA25026 for ; Fri, 7 Jul 2000 10:53:47 -0700 (PDT) Received: from sunfra.France.Sun.COM ([129.157.188.1]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA05786; Fri, 7 Jul 2000 10:55:02 -0700 (PDT) Received: from odin.France.Sun.COM (odin [129.157.192.2]) by sunfra.France.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.7) with SMTP id TAA20958; Fri, 7 Jul 2000 19:55:00 +0200 (MET DST) Received: from france.sun.com by odin.France.Sun.COM (SMI-8.6/SMI-SVR4) id TAA09785; Fri, 7 Jul 2000 19:54:59 +0200 Message-ID: <3966195F.E13E6B30@france.sun.com> Date: Fri, 07 Jul 2000 19:54:39 +0200 From: Rob Byrne - Sun Microsystems Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Mark C Smith CC: "Kurt D. Zeilenga" , ietf-ldapext@netscape.com, ietf-ldup@imc.org, Ed Reed Subject: Re: LDAP subentry alignment with X.500 subentry References: <4.3.2.7.0.20000703085803.00af9a60@infidel.boolean.net> <3965F2EC.EFE5B84C@netscape.com> 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 Mark, I would say that the complexity of the X.500 style specifier would be a barrier to it's adoption for the LDAP access control model. So I would say some simplified subtree specifier would be preferable (base, onelevel, subtree ?). Even ignoring the subtree specifier there are cons associated with putting acis into subentries compared to just storing them as attributes--for example you need to control access to the subentries which, becuase subentries do not behave like ordinary entries, requires at least one additional aci attribute (something like entryACI or subEntryACI). Rob. Mark C Smith wrote: > > > I primarily make these suggestions because I believe these changes would > > make subentries within LDAP more usable, in particular, when used in > > support of the access control model. > > Interesting. Before we throw out the simple LDAPsubentry that Ed has > defined, I think someone should list the additional requirements that > are needed for the access control effort to successfully use subentries. > > -- > Mark Smith > iPlanet From owner-ietf-ldup@mail.imc.org Sun Jul 9 23:40: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 XAA15847 for ; Sun, 9 Jul 2000 23:40:35 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA09017 for ietf-ldup-bks; Sun, 9 Jul 2000 20:03:20 -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 UAA09011 for ; Sun, 9 Jul 2000 20:03:17 -0700 (PDT) Received: (qmail 20542 invoked from network); 10 Jul 2000 03:04:46 -0000 Received: from softdnserror (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 10 Jul 2000 03:04:46 -0000 Reply-To: From: "Steven Legg" To: "'Rob Byrne - Sun Microsystems'" , "'Mark C Smith'" Cc: "'Kurt D. Zeilenga'" , , , "'Ed Reed'" Subject: RE: LDAP subentry alignment with X.500 subentry Date: Mon, 10 Jul 2000 13:07:22 +1000 Message-ID: <000601bfea1b$f83f0740$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: <3966195F.E13E6B30@france.sun.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 Rob, > -----Original Message----- > From: owner-ietf-ldup@mail.imc.org > [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Rob Byrne - Sun > Microsystems > Sent: Saturday, 8 July 2000 3:55 > To: Mark C Smith > Cc: Kurt D. Zeilenga; ietf-ldapext@netscape.com; ietf-ldup@imc.org; Ed > Reed > Subject: Re: LDAP subentry alignment with X.500 subentry > > > > Mark, > > I would say that the complexity of the X.500 style specifier > would be a barrier > to it's adoption for the LDAP access control model. > So I would say some simplified subtree specifier would be > preferable (base, > onelevel, subtree ?). Would it be acceptable to use the X.500 SubtreeSpecification but constrain it for use in LDAP ? I would rather deal with a subset of existing functionality than a separate mechanism to do the same thing. It would also provide an obvious upgrade path in future versions of LDAP by relaxing the constraints, if it proves desirable. The simple subtree specifier above would be equivalent to providing only the "minimum" or "maximum" component of a ChopSpecification, e.g. base equates to "{ maximum 0 }" onelevel equates to "{ minimum 1, maximum 1 }" or maybe "{ maximum 1 }" subtree equates to "{ }" All other fields being absent. Regards, Steven > > Even ignoring the subtree specifier there are cons associated > with putting acis > into subentries compared to just storing them as > attributes--for example you need > to control access to the subentries which, becuase subentries > do not behave like > ordinary entries, requires at least one additional aci > attribute (something like > entryACI or subEntryACI). > > Rob. > > Mark C Smith wrote: > > > > > > I primarily make these suggestions because I believe > these changes would > > > make subentries within LDAP more usable, in particular, > when used in > > > support of the access control model. > > > > Interesting. Before we throw out the simple LDAPsubentry > that Ed has > > defined, I think someone should list the additional > requirements that > > are needed for the access control effort to successfully > use subentries. > > > > -- > > Mark Smith > > iPlanet > > From owner-ietf-ldup@mail.imc.org Mon Jul 10 05:32:33 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 FAA01186 for ; Mon, 10 Jul 2000 05:32:32 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id BAA17102 for ietf-ldup-bks; Mon, 10 Jul 2000 01:50:05 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA17098 for ; Mon, 10 Jul 2000 01:50:04 -0700 (PDT) Received: from sunfra.France.Sun.COM ([129.157.188.1]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA05125; Mon, 10 Jul 2000 01:51:41 -0700 (PDT) Received: from odin.France.Sun.COM (odin [129.157.192.2]) by sunfra.France.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.7) with SMTP id KAA00883; Mon, 10 Jul 2000 10:51:40 +0200 (MET DST) Received: from france.sun.com by odin.France.Sun.COM (SMI-8.6/SMI-SVR4) id KAA05489; Mon, 10 Jul 2000 10:51:39 +0200 Message-ID: <39698E86.EF4B7470@france.sun.com> Date: Mon, 10 Jul 2000 10:51:18 +0200 From: Rob Byrne - Sun Microsystems Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: steven.legg@adacel.com.au CC: "'Mark C Smith'" , "'Kurt D. Zeilenga'" , ietf-ldapext@netscape.com, ietf-ldup@imc.org, "'Ed Reed'" Subject: Re: LDAP subentry alignment with X.500 subentry References: <000601bfea1b$f83f0740$b05508cb@osmium.adacel.com.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 Stephen, If we were to use subentries to store aci items then your "restriction" proposal sounds like a good approach. However, it could be argued that it would be useful to extend the X.500 subtree specifier to allow the refinement to be a generic filter (not just on the objectclass attribute). So, on the subject of a subtree specifier for LDAP, then wrt the X.500 specifier I would venture something like: drop the chops (in favour of a start point and base, onelevel and subtree) and allow the refinement to be a generic filter (not just on the objectclass). However, I would also like to see a discussion of why we should put acis into subentries rather than just store them as ldapACI attributes in entries. What are the pros and cons ? Cheers, Rob. Steven Legg wrote: > Rob, > > > -----Original Message----- > > From: owner-ietf-ldup@mail.imc.org > > [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Rob Byrne - Sun > > Microsystems > > Sent: Saturday, 8 July 2000 3:55 > > To: Mark C Smith > > Cc: Kurt D. Zeilenga; ietf-ldapext@netscape.com; ietf-ldup@imc.org; Ed > > Reed > > Subject: Re: LDAP subentry alignment with X.500 subentry > > > > > > > > Mark, > > > > I would say that the complexity of the X.500 style specifier > > would be a barrier > > to it's adoption for the LDAP access control model. > > So I would say some simplified subtree specifier would be > > preferable (base, > > onelevel, subtree ?). > > Would it be acceptable to use the X.500 SubtreeSpecification but > constrain it for use in LDAP ? I would rather deal with a subset of > existing functionality than a separate mechanism to do the same thing. > It would also provide an obvious upgrade path in future versions of LDAP > by relaxing the constraints, if it proves desirable. > > The simple subtree specifier above would be equivalent to providing > only the "minimum" or "maximum" component of a ChopSpecification, e.g. > > base equates to "{ maximum 0 }" > onelevel equates to "{ minimum 1, maximum 1 }" or maybe "{ maximum 1 }" > subtree equates to "{ }" > > All other fields being absent. > > Regards, > Steven > > > > > Even ignoring the subtree specifier there are cons associated > > with putting acis > > into subentries compared to just storing them as > > attributes--for example you need > > to control access to the subentries which, becuase subentries > > do not behave like > > ordinary entries, requires at least one additional aci > > attribute (something like > > entryACI or subEntryACI). > > > > Rob. > > > > Mark C Smith wrote: > > > > > > > > > I primarily make these suggestions because I believe > > these changes would > > > > make subentries within LDAP more usable, in particular, > > when used in > > > > support of the access control model. > > > > > > Interesting. Before we throw out the simple LDAPsubentry > > that Ed has > > > defined, I think someone should list the additional > > requirements that > > > are needed for the access control effort to successfully > > use subentries. > > > > > > -- > > > Mark Smith > > > iPlanet > > > > From owner-ietf-ldup@mail.imc.org Mon Jul 10 06:05: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 GAA01462 for ; Mon, 10 Jul 2000 06:05:21 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA17835 for ietf-ldup-bks; Mon, 10 Jul 2000 02:28:44 -0700 (PDT) Received: from aspams52.cai.com (aspams52.cai.com [155.35.248.76]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA17830 for ; Mon, 10 Jul 2000 02:28:42 -0700 (PDT) Received: by aspams52.cai.com with Internet Mail Service (5.5.2650.21) id ; Mon, 10 Jul 2000 19:29:50 +1000 Message-ID: <11981F9F5649D411BC92009027D0D18C4B4D8C@aspams01.cai.com> From: "Lloyd, Alan" To: Rob Byrne - Sun Microsystems , steven.legg@adacel.com.au Cc: "'Mark C Smith'" , "'Kurt D. Zeilenga'" , ietf-ldapext@netscape.com, ietf-ldup@imc.org, "'Ed Reed'" Subject: RE: LDAP subentry alignment with X.500 subentry Date: Mon, 10 Jul 2000 19:29:43 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The reason for ACI in subentries is that one can support the nested directory admin model and make domain based ACI decisions over distributed (X.500) DSAs. Whereas entry level ACI - may let a user do operations on the directory using the directory resources only to find they are denied to do these at the entry level (and on millions of other entries.. ie entry level ACI is easy to implement - but a rally bad way of working in terms of system level resource protection, large scale protected distributed systems - and operationally hard to configure and manage.. ie. configuring entry level ACI for millions of entries - across many servers - at the entry level takes time ... This process is also open to having errors introduced where back door holes might be the result of misconfiguration. If one adopts admin points and rules based configuration and deals with large scale distributed directory entries - then the nested admin model is best - simply becuase it does scale and is easier to operate with rules - This approach also align with conventional management models used by business ie top down. If an entry level aci is used - one must consider the cost to configure and test, the use of directory resource before making the actual ACI decision, the hierarchy of entries, their denials and permissions and any alias derefencing... as an example - say one has a distributed directory with 250 million entries in it and one wanted to apply a new rule for a new set of users and business services - for each entry... if an entry takes even half a minute to configure.. the job will be a life time career... regards alan Stephen, snip However, I would also like to see a discussion of why we should put acis into subentries rather than just store them as ldapACI attributes in entries. What are the pros and cons ? Cheers, Rob. snip From owner-ietf-ldup@mail.imc.org Mon Jul 10 06:30:17 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 GAA01697 for ; Mon, 10 Jul 2000 06:30:16 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA18087 for ietf-ldup-bks; Mon, 10 Jul 2000 02:48:42 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA18083 for ; Mon, 10 Jul 2000 02:48:41 -0700 (PDT) Received: from sunfra.France.Sun.COM ([129.157.188.1]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA24683; Mon, 10 Jul 2000 02:50:02 -0700 (PDT) Received: from odin.France.Sun.COM (odin [129.157.192.2]) by sunfra.France.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.7) with SMTP id LAA04777; Mon, 10 Jul 2000 11:50:00 +0200 (MET DST) Received: from france.sun.com by odin.France.Sun.COM (SMI-8.6/SMI-SVR4) id LAA06153; Mon, 10 Jul 2000 11:49:59 +0200 Message-ID: <39699C32.7EB36556@france.sun.com> Date: Mon, 10 Jul 2000 11:49:38 +0200 From: Rob Byrne - Sun Microsystems Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Lloyd, Alan" CC: steven.legg@adacel.com.au, "'Mark C Smith'" , "'Kurt D. Zeilenga'" , ietf-ldapext@netscape.com, ietf-ldup@imc.org, "'Ed Reed'" Subject: Re: LDAP subentry alignment with X.500 subentry References: <11981F9F5649D411BC92009027D0D18C4B4D8C@aspams01.cai.com> 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 Hi Alan, Thanks for that...but I think I was not precise enough in my question. The current proposal for ldapACI does put them in entries but they come with a built in scope rule, which can be "subtree". So, I suppose my question is rather, "apart from leveraging the scoping rule of subentries what is the big plus we get from putting acis into subentries ?". Thanks, Rob. "Lloyd, Alan" wrote: > The reason for ACI in subentries is that one can support the nested > directory admin model and make domain based ACI decisions over distributed > (X.500) DSAs. Whereas entry level ACI - may let a user do operations on the > directory using the directory resources only to find they are denied to do > these at the entry level (and on millions of other entries.. ie entry level > ACI is easy to implement - but a rally bad way of working in terms of system > level resource protection, large scale protected distributed systems - and > operationally hard to configure and manage.. > > ie. configuring entry level ACI for millions of entries - across many > servers - at the entry level takes time ... This process is also open to > having errors introduced where back door holes might be the result of > misconfiguration. > > If one adopts admin points and rules based configuration and deals with > large scale distributed directory entries - then the nested admin model is > best - simply becuase it does scale and is easier to operate with rules - > This approach also align with conventional management models used by > business ie top down. If an entry level aci is used - one must consider the > cost to configure and test, the use of directory resource before making the > actual ACI decision, the hierarchy of entries, their denials and permissions > and any alias derefencing... > > as an example - say one has a distributed directory with 250 million entries > in it and one wanted to apply a new rule for a new set of users and business > services - for each entry... if an entry takes even half a minute to > configure.. the job will be a life time career... > > regards alan > > Stephen, > > snip > > However, I would also like to see a discussion of why we should put acis > into subentries rather than just store them as ldapACI attributes in > entries. What are the pros and cons ? > > Cheers, > Rob. > > snip From owner-ietf-ldup@mail.imc.org Mon Jul 10 06:41: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 GAA02660 for ; Mon, 10 Jul 2000 06:41:07 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA18343 for ietf-ldup-bks; Mon, 10 Jul 2000 03:06:54 -0700 (PDT) Received: from aspams52.cai.com (aspams52.cai.com [155.35.248.76]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA18339 for ; Mon, 10 Jul 2000 03:06:52 -0700 (PDT) Received: by aspams52.cai.com with Internet Mail Service (5.5.2650.21) id ; Mon, 10 Jul 2000 20:08:06 +1000 Message-ID: <11981F9F5649D411BC92009027D0D18C4B4E8D@aspams01.cai.com> From: "Lloyd, Alan" To: Rob Byrne - Sun Microsystems Cc: steven.legg@adacel.com.au, "'Mark C Smith'" , "'Kurt D. Zeilenga'" , ietf-ldapext@netscape.com, ietf-ldup@imc.org, "'Ed Reed'" Subject: RE: LDAP subentry alignment with X.500 subentry Date: Mon, 10 Jul 2000 20:08:01 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: No worries - but the real issue to me is an administrative plane in a directory for schema, collectives, security, aci, etc means that these entries can be partitioned into their own regime - in that there is administrative security applied to these entries and they get named seperately from the "user entry plane"..ie does the ACI on ORG x get its ACI properties from a management plane of named entries (which have their own ACI regime - distinct from the user ACI regime ) or are they coupled because it all exists as one compound entry. There are five aspects to ACI..that is coupled to the User authentication process.. these are The Operation The Name Space The Object Class of the entry The attribute type/value within OC/entry and the Time the operation is allowed. Given that very strong ACI code (in terms of vetting) can be applied to the directory operation and name space of the entry and its OC. Having named subentries for management is a much more trustworthy approach than compound OCs that exist under a User "named" DIT. In addition if entries are renamed becuase of business, service and user changes, it may means the ACI management model has to be recalculated re its security. Whereas the named entry for management - admin model is still the ACI and schema reference point in the directory. Naturally this discussion can be lengthy - but one area that one looks at in military security - is "seperation of duty" - and how operations that change one thing affect others.. An explicit "named" management and security information model with its own privileges and ACI - to me is much better than a compound one - that can be accidentally affected by such things a user information name changes.. I hope this "helps".. regards alan -----Original Message----- From: Rob Byrne - Sun Microsystems [mailto:Robert.Byrne@france.sun.com] Sent: Monday, July 10, 2000 7:50 PM To: Lloyd, Alan Cc: steven.legg@adacel.com.au; 'Mark C Smith'; 'Kurt D. Zeilenga'; ietf-ldapext@netscape.com; ietf-ldup@imc.org; 'Ed Reed' Subject: Re: LDAP subentry alignment with X.500 subentry Hi Alan, Thanks for that...but I think I was not precise enough in my question. The current proposal for ldapACI does put them in entries but they come with a built in scope rule, which can be "subtree". So, I suppose my question is rather, "apart from leveraging the scoping rule of subentries what is the big plus we get from putting acis into subentries ?". Thanks, Rob. "Lloyd, Alan" wrote: > The reason for ACI in subentries is that one can support the nested > directory admin model and make domain based ACI decisions over distributed > (X.500) DSAs. Whereas entry level ACI - may let a user do operations on the > directory using the directory resources only to find they are denied to do > these at the entry level (and on millions of other entries.. ie entry level > ACI is easy to implement - but a rally bad way of working in terms of system > level resource protection, large scale protected distributed systems - and > operationally hard to configure and manage.. > > ie. configuring entry level ACI for millions of entries - across many > servers - at the entry level takes time ... This process is also open to > having errors introduced where back door holes might be the result of > misconfiguration. > > If one adopts admin points and rules based configuration and deals with > large scale distributed directory entries - then the nested admin model is > best - simply becuase it does scale and is easier to operate with rules - > This approach also align with conventional management models used by > business ie top down. If an entry level aci is used - one must consider the > cost to configure and test, the use of directory resource before making the > actual ACI decision, the hierarchy of entries, their denials and permissions > and any alias derefencing... > > as an example - say one has a distributed directory with 250 million entries > in it and one wanted to apply a new rule for a new set of users and business > services - for each entry... if an entry takes even half a minute to > configure.. the job will be a life time career... > > regards alan > > Stephen, > > snip > > However, I would also like to see a discussion of why we should put acis > into subentries rather than just store them as ldapACI attributes in > entries. What are the pros and cons ? > > Cheers, > Rob. > > snip From owner-ietf-ldup@mail.imc.org Mon Jul 10 15:09: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 PAA23931 for ; Mon, 10 Jul 2000 15:09:08 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA06638 for ietf-ldup-bks; Mon, 10 Jul 2000 11:26:46 -0700 (PDT) Received: from inet-smtp3.oracle.com (inet-smtp3.oracle.com [205.227.43.23]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA06634 for ; Mon, 10 Jul 2000 11:26:43 -0700 (PDT) Received: from gmgw01.us.oracle.com (gmgw01.us.oracle.com [130.35.61.190]) by inet-smtp3.oracle.com (8.9.3/8.9.3) with ESMTP id LAA08566 for ; Mon, 10 Jul 2000 11:25:56 -0700 (PDT) Received: from oracle.com (usirniva-lap.us.oracle.com [144.25.112.241]) by gmgw01.us.oracle.com (8.8.8+Sun/8.8.8) with ESMTP id LAA28715 for ; Mon, 10 Jul 2000 11:25:56 -0700 (PDT) Message-ID: <396A1503.44F67697@oracle.com> Date: Mon, 10 Jul 2000 11:25:07 -0700 From: Uppili Srinivasan X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ldup@imc.org Subject: Test - please ignore! 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 From owner-ietf-ldup@mail.imc.org Tue Jul 11 03:16:14 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 DAA21572 for ; Tue, 11 Jul 2000 03:16:14 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA12356 for ietf-ldup-bks; Mon, 10 Jul 2000 23:36: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 XAA12347 for ; Mon, 10 Jul 2000 23:36:16 -0700 (PDT) Received: (qmail 21529 invoked from network); 11 Jul 2000 06:33:27 -0000 Received: from cpe-144-132-68-23.vic.bigpond.net.au (HELO w98sysrec) (144.132.68.23) by relay1.pair.com with SMTP; 11 Jul 2000 06:33:27 -0000 X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: "'Rob Byrne - Sun Microsystems'" , Cc: "'Mark C Smith'" , "'Kurt D. Zeilenga'" , , , "'Ed Reed'" Subject: RE: LDAP subentry alignment with X.500 subentry Date: Tue, 11 Jul 2000 16:37:04 +1000 Message-ID: <000601bfeb02$6e45e6c0$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: <39698E86.EF4B7470@france.sun.com> 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 [RB] Stephen, If we were to use subentries to store aci items then your "restriction" proposal sounds like a good approach. However, it could be argued that it would be useful to extend the X.500 subtree specifier to allow the refinement to be a generic filter (not just on the objectclass attribute). So, on the subject of a subtree specifier for LDAP, then wrt the X.500 specifier I would venture something like: drop the chops (in favour of a start point and base, onelevel and subtree) and allow the refinement to be a generic filter (not just on the objectclass). However, I would also like to see a discussion of why we should put acis into subentries rather than just store them as ldapACI attributes in entries. What are the pros and cons ? Cheers, Rob. [AL] Extending X.500 subtree specifier to allow a generic filter (not just on objectclass attribute) would be a bad idea, for reasons explained below. I agree with Steve's proposal to use a subset of X.500, not a superset. This subset should be the minimum necessary to support replication subentries (which isn't much), but using the generic standard so that implementors needing more (eg for ACI) don't have to duplicate effort. First, apologies to all, and especially to Steve, for long delay responding to Steve's careful response re MDCR etc. Will be replying in detail but had to put it aside and will still have to do so for at least another week due to other priorities. (Got an excuse though, also waiting for authors reply re requirements ;-) Meanwhile, a quick point re this thread, as I can write about ACI and subentries from off the top of my head, whereas multi-master replication is HARD. From above and other messages I suspect there may be some talking at cross purposes re implementation issues vs protocol issues. X.500 style subentries with chop sepecifications (by minimum and maximum depth, plus named lower boundaries, plus arbitrary boolean filters on object class only, can be implemented either by logic applied to traversal of the path from the (administrative point of) the subentry or by logic applied to COPIES of the subentry aci physically stored with the affected entry aci as part of the entry. Both implementation methods can conform to the same protocol standards that separate the administration of entry aci from the administration of subentry aci. The second method has all the administrative advantages mentioned by Alan, because the subentry aci stored within an entry is administered from the subentry point, independently of the entry aci. But it provides much greater efficiency for read dominated directories at the expense of slower application of changes to subentry aci (which are relatively infrequent). eg Active Directory uses inheritance (from Admin points, not true named subentries) to propagate the admin point aci downwards from the minimum depth of the chop spec (limited to 0 or 1), to the maximum depth (limited to 0, 1 or infinite) with limited specification of object classes. Whenever the inherited aci is changed, a write has to be made to EVERY affected entry, which can be very slow for changes applied from high up, but the whole idea of delegation is that such changes should be infrequent. This is effectively the same as "base, one level and subtree" but with the important addition of "below one level only". That enables the vitally important specification of ACI that does not become effective until propagated BELOW the point of application - effectively allowing a form of unaffected subentries even when applied from an admin point (because subentries have their own object class). The mechanism used in Active Directory simply uses a bit to specify whether inherited aci is "inherit only", in which case it is "dead" at the entry but becomes "live" when copied to entries below. By changing this to an integer instead of a bit you would get a chop min. Likewise a "don't propagate" bit cuts off further copying for inheritance below. Changing that to an integer would give a chop max. There is no reason why the same general "inheritance by copy" approach could not be used for true named subentry ACI (calculating inheritance from the base instead of the subentry, even though the specification is named by the subentry). Also the Active Directory limitation on chop specs and object class filters seems related to transition from historical* NT/DCE security descriptors rather than any inherent limitation in this model. (* Your spelling of "historical" may vary, however the use of admin points instead of named subentries can only be spelled one way, "hysterical"). The first method also has all the administrative advantages mentioned by Alan, is simpler to implement and allows much faster changes since a change only has to be written once, where it is physically stored only at the subentry (or admin point). However it slows down reads and writes and especially searches to the affected entries themselves and is therefore in my view precisely the wrong optimization for directories. (Except where there is so little delegation that all the non-entry ACI can be kept in RAM anyway, as with many LDAP servers based on the U Michigan release with highly centralized administration, even editing config files to change ACI). It is also very intertwined with the naming structure. A regexp on naming path for access control in a search would severely complicate the use of aliases. That is why X.500 specifies ACI controls based on the unique primary distinguished name of an entry, not on path names. LDAP standards must not unnecessarily limit implementation choices. Filter specifications on object classes work with either model, since every entry knows its object classes and can easily calculate an arbitrary filter on them quickly when determining visibility during searches. General filters really only work with a traversal based implementation and are basically just an attempt to substitute regexp evaluation on path names familiar to centralized web administrators for a serious admin model that can actually be delegated. The apparant additional flexibility is illusory since it doesn't scale with real delegation, whereas the combination of min and max depth, base, named lower bounds and object class filters does allow for adequate delegation of directory access control domains independently of the naming structure. Independence from the naming structure is essential for scalable delegation. This is also relevant to replication management issues when we move beyond current scope and need to support opportunistic delegated replication agreements for subsets of a replicated area, as mentioned in Alison's contribution. Most of this thread is more related to LDAP ACI extensions than to replication. However the mechanism used for replication subentries should be consistent with that used for any other purpose and should therefore be a subset, not a superset. Also, the generalization of subentries to families of related entries is very relevant to dealing with atomicity and replication granularity issues. As mentioned in MDCR attributes that need to be changeable independently and concurrently at multiple replicas can be in separate subentries or child entries of a parent family entry. Any such generalization of subentries need only rely on object classes. Most importantly, the multi-master replication of subentries MUST have sufficient consistency properties to support their use for ACI. If the replication mechanism is so broken that one has to rely on per replica subentries to administer it, I don't see how it could possibly support replicated access controls of any useful kind at all. This was also mentioned in MDCR: http://www.ietf.org/internet-drafts/draft-langer-ldup-mdcr-00.txt From owner-ietf-ldup@mail.imc.org Tue Jul 11 07:09:05 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 HAA25259 for ; Tue, 11 Jul 2000 07:09:05 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA27499 for ietf-ldup-bks; Tue, 11 Jul 2000 03:31:31 -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 DAA27495 for ; Tue, 11 Jul 2000 03:31:30 -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 GAA23756; Tue, 11 Jul 2000 06:32:42 -0400 (EDT) Message-Id: <200007111032.GAA23756@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-model-04.txt Date: Tue, 11 Jul 2000 06:32:42 -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 Replication Architecture Author(s) : J. Merrells, E. Reed, U. Srinivasan Filename : draft-ietf-ldup-model-04.txt Pages : 48 Date : 10-Jul-00 This architectural document outlines a suite of schema and protocol extensions to LDAPv3 that enables the robust, reliable, server-to-server exchange of directory content and changes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-04.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-model-04.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-model-04.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: <20000710151707.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-model-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-model-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000710151707.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Wed Jul 12 18:45: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 SAA17478 for ; Wed, 12 Jul 2000 18:45:24 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA05106 for ietf-ldup-bks; Wed, 12 Jul 2000 15:07:46 -0700 (PDT) Received: from dir1.control.att.com ([135.207.251.15]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA05102 for ; Wed, 12 Jul 2000 15:07:45 -0700 (PDT) Received: from att.com (pest.control.att.com [135.207.251.76]) by dir1.control.att.com (Postfix) with ESMTP id DFB417205 for ; Wed, 12 Jul 2000 18:09:37 -0400 (EDT) Message-ID: <396CEC30.D4BF0BBF@att.com> Date: Wed, 12 Jul 2000 18:07:44 -0400 From: Chris Apple Organization: AT&T Labs X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ldup@imc.org Subject: I-D Cut-Off Reminder 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 This is a reminder to send revised Internet Drafts to the I-D Editor no later than Friday, July 14, 2000 1700 ET. -- ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Service Internet Directory Group http://www.anywho.com AT&T Labs capple@control.att.com +1 973 236 6470 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ From owner-ietf-ldup@mail.imc.org Thu Jul 13 02:40: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 CAA08845 for ; Thu, 13 Jul 2000 02:40:49 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA02021 for ietf-ldup-bks; Wed, 12 Jul 2000 23:05:53 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA02017 for ; Wed, 12 Jul 2000 23:05:52 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 13 Jul 2000 00:07:07 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 13 Jul 2000 00:06:52 -0600 From: "Haripriya S" To: Cc: , Subject: RE: various comments (was Re: What's going on? - Status ofRequirements...) 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 XAA02018 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Steven, The remaining (N - M) replicas would not be allowed to perform any strong consistency updates because they wouldn't be able to obtain a quorum of M replicas: M > N/2 implies (N-M) < M . However, loose consistency updates would be allowed at the (N-M) replicas, which might invalidate strong consistency updates performed by the M replicas. I would regard this as a case of one application stomping over another application because it is unaware/uncaring of the second application's semantics and constraints. This sort of thing is a problem even in the single master case, though admittedly the multi-master case raises some situations that wouldn't occur on a single master. - As transaction is an add-on for a directory, it should work even in cases a client is not aware of strong or weak consistency. One model that can be followed is: - reads are weakly consistent unless the client knows and asks for strong consistency. - writes even if not specified by client should result in strong consistency. - One way in which this can be done is i. use a normal read in case of no or weak consistency reads. ii. use the quorum based aproach you mentioned if client requests strong consistency read. iii. use a timestamps based approach for atomicity of writes. - if a transaction makes n modifies to the directory (add, modify or del) all these n modifies should have consecutive or same CSNs. The CSNs will have the time at which the transaction ended.Thus if server 1 makes changes to n items in set N by a transaction beginning at time t1 and ending at t2, and server 2 makes change to item n1 belonging to set N at time t3, then if t2 > t3, then the effect of the change at t2 will be overridden by the transaction at server 1. If t2 is less that t3, then it is as if the lone change to n1 came after the transaction completed, so the result is as expected. This approach could be used even if some of the servers are down or inaccessible at the moment. My original thought was to allow applications to request whether or not their operations should be executed with strong consistency, but I think it would also be useful if applications and/or administrators could register what entries or attributes they want the server(s) to protect by insisting that ALL operations against those directory items, even those explicitly requesting loose consistency, are performed with strong consistency. In this way an application could block loose consistency updates in any currently inaccessable (N-M) subset of the replicas. - Specifying a set of entries or attributes as forming a transaction group may be difficult. Imagine the case where the transaction's need is to preserve consistency between a user and its group object at all times. if the user has a groupmembership attribute, and the group has a member attribute, these have to be changed together for the change to be consistent. But it is difficult to specify this relationship in terms of entry names because it has to be said like "if entry e1 is the value of a member attribute of a group g1, and e1 is a user, then the groupmembership attribute of e1 should be updated along with the member attribute of g1", which is difficult. Regards, Steven - Thanks and Regards, - Haripriya From owner-ietf-ldup@mail.imc.org Thu Jul 13 08:24:31 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 IAA15323 for ; Thu, 13 Jul 2000 08:24:31 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id EAA19766 for ietf-ldup-bks; Thu, 13 Jul 2000 04:50:56 -0700 (PDT) Received: from mail.tfsint.com (mail.tfsint.com [63.67.211.199]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA19761 for ; Thu, 13 Jul 2000 04:50:54 -0700 (PDT) Received: from ThirdFederal.com (groupwise [128.1.42.218]) by mail.tfsint.com (8.9.3/8.9.3) with SMTP id HAA14644 for ; Thu, 13 Jul 2000 07:52:54 -0400 Received: from GATEWAY-Message_Server by ThirdFederal.com with Novell_GroupWise; Thu, 13 Jul 2000 07:52:48 -0400 Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Thu, 13 Jul 2000 07:52:06 -0400 From: "Jerry Roman" To: steven.legg@adacel.com.au, SHARIPRIYA@novell.com Cc: ietf-ldup@imc.org, alison.payne@team.telstra.com Subject: RE: various comments (was Re: What's going on? - StatusofRequirements...) 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 EAA19763 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Can I please be taken off this distribution list? Thanks Jerry Roman Third Federal Savings Information Systems (216)429-5065 >>> "Haripriya S" 07/13 2:06 AM >>> Steven, The remaining (N - M) replicas would not be allowed to perform any strong consistency updates because they wouldn't be able to obtain a quorum of M replicas: M > N/2 implies (N-M) < M . However, loose consistency updates would be allowed at the (N-M) replicas, which might invalidate strong consistency updates performed by the M replicas. I would regard this as a case of one application stomping over another application because it is unaware/uncaring of the second application's semantics and constraints. This sort of thing is a problem even in the single master case, though admittedly the multi-master case raises some situations that wouldn't occur on a single master. - As transaction is an add-on for a directory, it should work even in cases a client is not aware of strong or weak consistency. One model that can be followed is: - reads are weakly consistent unless the client knows and asks for strong consistency. - writes even if not specified by client should result in strong consistency. - One way in which this can be done is i. use a normal read in case of no or weak consistency reads. ii. use the quorum based aproach you mentioned if client requests strong consistency read. iii. use a timestamps based approach for atomicity of writes. - if a transaction makes n modifies to the directory (add, modify or del) all these n modifies should have consecutive or same CSNs. The CSNs will have the time at which the transaction ended.Thus if server 1 makes changes to n items in set N by a transaction beginning at time t1 and ending at t2, and server 2 makes change to item n1 belonging to set N at time t3, then if t2 > t3, then the effect of the change at t2 will be overridden by the transaction at server 1. If t2 is less that t3, then it is as if the lone change to n1 came after the transaction completed, so the result is as expected. This approach could be used even if some of the servers are down or inaccessible at the moment. My original thought was to allow applications to request whether or not their operations should be executed with strong consistency, but I think it would also be useful if applications and/or administrators could register what entries or attributes they want the server(s) to protect by insisting that ALL operations against those directory items, even those explicitly requesting loose consistency, are performed with strong consistency. In this way an application could block loose consistency updates in any currently inaccessable (N-M) subset of the replicas. - Specifying a set of entries or attributes as forming a transaction group may be difficult. Imagine the case where the transaction's need is to preserve consistency between a user and its group object at all times. if the user has a groupmembership attribute, and the group has a member attribute, these have to be changed together for the change to be consistent. But it is difficult to specify this relationship in terms of entry names because it has to be said like "if entry e1 is the value of a member attribute of a group g1, and e1 is a user, then the groupmembership attribute of e1 should be updated along with the member attribute of g1", which is difficult. Regards, Steven - Thanks and Regards, - Haripriya From owner-ietf-ldup@mail.imc.org Thu Jul 13 09:27: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 JAA17950 for ; Thu, 13 Jul 2000 09:27:40 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA22863 for ietf-ldup-bks; Thu, 13 Jul 2000 05:50:01 -0700 (PDT) Received: from relay1.mail.uk.psi.net (relay1.mail.uk.psi.net [154.32.105.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA22858 for ; Thu, 13 Jul 2000 05:50:00 -0700 (PDT) Received: from [193.123.145.3] (helo=enigma.eema.org) by relay1.mail.uk.psi.net with esmtp (Exim 2.12 #2) id 13CiTA-0004mR-00 for ietf-ldup@imc.org; Thu, 13 Jul 2000 13:52:00 +0100 Received: by ENIGMA with Internet Mail Service (5.5.2650.21) id <3MD79FMP>; Thu, 13 Jul 2000 14:01:20 +0100 Message-ID: <81CD2C66CCA5D311ACC1009027AA4C0D08AF15@ENIGMA> From: "Hebson, Jane" To: ietf-ldup@imc.org Subject: Have you managed to keep track of all the latest RFCs and Interne t-drafts related to LDAP? Date: Thu, 13 Jul 2000 14:01:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Have you managed to keep track of all the latest RFCs and Internet-drafts related to LDAP? If not, EEMA are pleased to offer the following document as a guide to the current state of play http://www.eema.org/interest/displayrecent.asp?ID=68 If you have any comments on this paper which will be maintained on a regular basis, then please contact me - thanks Jane Jane Hebson EEMA Interest and Special Project Manager Direct Line +44 1527 837596 Office +44 1386 793028 http://www.eema.org/ ISSE2000 - The second Information Security Solutions Europe Conference & Exhibition 27-29th September, Barcelona, Spain Visit our web site http://www.eema.org/isse or contact info@eema.org , Register now to secure your place Please put these dates in your diary NOW ! From owner-ietf-ldup@mail.imc.org Thu Jul 13 13:08:31 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 NAA29679 for ; Thu, 13 Jul 2000 13:08:31 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA29156 for ietf-ldup-bks; Thu, 13 Jul 2000 08:42:40 -0700 (PDT) Received: from REED.oncalldba.com (pipeline.oncalldba.com [166.70.104.49] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA29137 for ; Thu, 13 Jul 2000 08:42:38 -0700 (PDT) Received: from RMINC_DOM-Message_Server by REED.oncalldba.com with Novell_GroupWise; Thu, 13 Jul 2000 09:44:30 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Thu, 13 Jul 2000 09:43:59 -0600 From: "Ed Reed" To: , Cc: , Subject: Re: LDAP subentry alignment with X.500 subentry 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 IAA29148 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Kurt - I disagree with your proposal to replace LDAPsubentry with X.500 subentry, mainly for reasons already expressed on the list: 1) the subtree specifier is omitted because: a) it introduces what seems to be a lot of complexity to determining which entries a subentry would refer to, b) it introduces what seems to be a lot of complexity to determining which subentries apply to a particular entry, c) it introduces what seems to be a lot of complex thinking for administrators who want to understand how to tell their system to do something, and to understand what their system is trying to do d) the author (me) has not been exposed to many (any) real-world problems solved by the subtree specifier which are not or can not be as well handled in some other fashion. 2) As Steven Legg pointed out, X.500 vendors who wish to use the same mechanism to implement subentry and LDAPsubentry may treat LDAPsubentry as a limited subset (for the most part, see below) of the X.500 subentry, with an implicit subtree specification. The one place I'm aware of that the LDAP subentry is not a proper subset of the X.500 subentry is that the LDAPsubentry MAY be nested, whereas the X.500 subentry may not - but that's really just a structure rule variation, isn't it? Of those reasons, the first three of 1 are the qualitative reasons. As for the fourth - informal conversations I've had with vendors who HAVE implemented the subentry suggest that it IS complex to implement, it IS hard to use correctly in operational environments (because of a, b, and c) and it's NOT widely used. I've no objection to extending LDAPsubentry at somepoint in the future to have full X.500 semantic subentry behavior - but I'd rather let those of you who think it's worth while do the expansion and let the market place of real-world operations provide the compelling reason the make that the standard, rather than try to force it on lots of folks who don't see the need, today. Or put another way, I have no problem watching LDAPsubentry attrophy from lack of use if the X.500 subentry is over= whelmingly adopted by the LDAP community at large. Ed ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM >>> "Kurt D. Zeilenga" 07/03/00 10:25AM >>> I believe 'LDAPsubentry' should be replaced with with 'subentry' and defined such that it closely modelled after X.500. 1) subentries should have a subtree specifier such that they are more useful for specification of ACI subentries. 2) subentries should be visible based upon presence of a subentries control, not a filter components. For example: (|(&(objectclass=LDAPsubentry)(!(cn=*))(objectclass=*)) Should the subentry be visible or not? There are reasonable arguments for both yes and no. I primarily make these suggestions because I believe these changes would make subentries within LDAP more usable, in particular, when used in support of the access control model. Kurt From owner-ietf-ldup@mail.imc.org Thu Jul 13 13:11:58 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 NAA29882 for ; Thu, 13 Jul 2000 13:11:57 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA00814 for ietf-ldup-bks; Thu, 13 Jul 2000 08:54:11 -0700 (PDT) Received: from REED.oncalldba.com (pipeline.oncalldba.com [166.70.104.49] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA00807 for ; Thu, 13 Jul 2000 08:54:08 -0700 (PDT) Received: from RMINC_DOM-Message_Server by REED.oncalldba.com with Novell_GroupWise; Thu, 13 Jul 2000 09:56:04 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Thu, 13 Jul 2000 09:55:49 -0600 From: "Ed Reed" To: , Cc: , , Subject: LDAP subentry schema request for last call 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 IAA00811 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit After reviewing the recent comments on LDAPsubentry (and posting my reply), and reviewing where the March 9 version of the doc (as posted on the LDUP wg web site) stands with regard to MUST/MAY (cn) and naming, I think the document, as published, should go forward for last call. With regard to naming, the doc says LDAPsubentry MAY be named by cn, which is where I think the concensus of the list now resides. With regard to MUST/MAY {cn} as an attribute, the document now says MAY, and leaves the class as a STRUCTURAL class. Of course, that means that a naming rule will need to use CN as it's naming attribute if no other attributes are defined on the class, which pretty much turns it into a MUST in those cases, but when other classes are derived from LDAPsubentry other attributes may also be defined, and then cn need not be used as a naming attribute. I think we could also make it be MUST {cn} and require cns to be populated, even if they're not being used to name the LDAPsubentry, and I'll be happy to make that change after last call if needed. I just don't see the need to bother, now. With regard to making LDAPsubentry fully compatible with the X.500 subentry, it's been pointed out that people wanting to use the X.500 subentry should feel free to do so - it's incorporated by reference in the base LDAP definitions. The purpose of this proposal is to define a subset of the X.500 functionality (and extend the structural rules by allowing nesting of LDAPsubentries) for use by certain LDAP applications which find the subset functionality a useful simplification. So - Please, put out the last call for the draft as posted on the LDUP WG IETF Charter page, document draft-ietf-ldup-subentry-02.txt, dated 9 March 2000. Ed ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM From owner-ietf-ldup@mail.imc.org Thu Jul 13 15:31: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 PAA06673 for ; Thu, 13 Jul 2000 15:31:52 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA06793 for ietf-ldup-bks; Thu, 13 Jul 2000 11:58:43 -0700 (PDT) Received: from REED.oncalldba.com (pipeline.oncalldba.com [166.70.104.49] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA06789 for ; Thu, 13 Jul 2000 11:58:41 -0700 (PDT) Received: from RMINC_DOM-Message_Server by REED.oncalldba.com with Novell_GroupWise; Thu, 13 Jul 2000 13:00:34 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Thu, 13 Jul 2000 13:00:10 -0600 From: "Ed Reed" To: Cc: , , , , , Subject: Re: LDAP subentry schema request for last call - Further 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 LAA06790 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Thanks for the direction - will do. ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM >>> Mark Wahl 07/13/00 12:58PM >>> > I'm sorry I found this note in the minutes after I'd already > said the doc was ready to go to last call. I'll make the change, > as described here in the version that goes to the RFC editor. > Does that work? Not that way. After review by the Working groups, the document is reviewed by the IETF as a whole and the IESG. The IETF as a whole and the IESG read the doc as presented in the I-D archive. Therefore if you want to make a technical change, you should make it before the document completes Working Group last call, so that it will be there before it enters IETF-wide last call. Since the WG chairs have not sent out the last call announcement, I'd recommend you make your change now. Mark Wahl, Directory Architect, Service Provider/Infrastructure Sun Microsystems, Inc. iPlanet Alliance From owner-ietf-ldup@mail.imc.org Thu Jul 13 15:41: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 PAA07095 for ; Thu, 13 Jul 2000 15:41:44 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA06760 for ietf-ldup-bks; Thu, 13 Jul 2000 11:56:31 -0700 (PDT) Received: from gate.innosoft.com (SYSTEM@GATE.INNOSOFT.COM [192.160.253.77]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA06756 for ; Thu, 13 Jul 2000 11:56:30 -0700 (PDT) Received: from threadgill.austin.innosoft.com (threadgill.austin.innosoft.com [207.8.108.5]) by GATE.INNOSOFT.COM (PMDF V6.0-24 #10099) with ESMTP id <01JRPUI1Q9GK0004A0@GATE.INNOSOFT.COM> for ietf-ldup@imc.org; Thu, 13 Jul 2000 11:57:52 -0700 (PDT) Received: from threadgill.austin.innosoft.com (threadgill.austin.innosoft.com [207.8.108.5]) by austin.innosoft.com (PMDF V6.0-24 #36555) with SMTP id <0FXN006ABGODQ2@austin.innosoft.com>; Thu, 13 Jul 2000 13:57:49 -0500 (CDT) Date: Thu, 13 Jul 2000 13:57:49 -0500 From: Mark Wahl Subject: Re: LDAP subentry schema request for last call - Further In-reply-to: "Your message of Thu, 13 Jul 2000 12:51:47 MDT." To: Ed Reed Cc: kurt@boolean.net, johns@cisco.com, capple@control.att.com, ietf-ldup@imc.org, ietf-ldapext@netscape.com, Kurt@OpenLDAP.org Message-id: <9615.963514669@threadgill.austin.innosoft.com> Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > I'm sorry I found this note in the minutes after I'd already > said the doc was ready to go to last call. I'll make the change, > as described here in the version that goes to the RFC editor. > Does that work? Not that way. After review by the Working groups, the document is reviewed by the IETF as a whole and the IESG. The IETF as a whole and the IESG read the doc as presented in the I-D archive. Therefore if you want to make a technical change, you should make it before the document completes Working Group last call, so that it will be there before it enters IETF-wide last call. Since the WG chairs have not sent out the last call announcement, I'd recommend you make your change now. Mark Wahl, Directory Architect, Service Provider/Infrastructure Sun Microsystems, Inc. iPlanet Alliance From owner-ietf-ldup@mail.imc.org Thu Jul 13 16:14: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 QAA11835 for ; Thu, 13 Jul 2000 16:14:44 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA06593 for ietf-ldup-bks; Thu, 13 Jul 2000 11:50:11 -0700 (PDT) Received: from REED.oncalldba.com (pipeline.oncalldba.com [166.70.104.49] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA06588 for ; Thu, 13 Jul 2000 11:50:09 -0700 (PDT) Received: from RMINC_DOM-Message_Server by REED.oncalldba.com with Novell_GroupWise; Thu, 13 Jul 2000 12:51:59 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Thu, 13 Jul 2000 12:51:47 -0600 From: "Ed Reed" To: , , , "Kurt D. Zeilenga" , Cc: , , Subject: Re: LDAP subentry schema request for last call - Further 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 LAA06589 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit After further reviewing the minutes from Australia, the LDUP meeting minutes called for a discussion on use of Auxilliary classes with LDAPsubentry in favor of deriving new classes from LDAPsubentry, as a general rule, and the LDUP minutes asked that the document be revised to include that advisory direction to readers. However, it was noted there that naming is an issue again, when AUX classes don't resolve. The draft on the web site doesn't address this. Section 3.1 begins with the following statement: "The class ldapSubEntry is intended to be used as a super class when defining other structural classes to be used as LDAP Subentries. The presence of ldapSubEntry in the list of super-classes of an entry in the directory makes that entry an LDAP Subentry. Object classes derived from ldapSubEntry are themselves considered ldapSubEntry classes, for the purpose of this discussion." We could elaborate on the request, here, such as... "The class ldapSubEntry is intended to be used as a super- class when defining other structural classes to be used as LDAP Subentries, and as the structural class to which Auxilliary classes may be added for application specific subentry information. Where possible, the use of Auxilliary classes to extend ldapSubEntries is strongly preferred. The presence of ldapSubEntry in the list..." I think that would leave the naming issue (not using cn to name the subentry) as an excersize for the Auxilliary class definer, which might be a cruel booby-prize...but if Kurt and others find it acceptible, fine. I'm sorry I found this note in the minutes after I'd already said the doc was ready to go to last call. I'll make the change, as described here in the version that goes to the RFC editor. Does that work? Ed ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM >>> "Ed Reed" 07/13/00 09:55AM >>> After reviewing the recent comments on LDAPsubentry (and posting my reply), and reviewing where the March 9 version of the doc (as posted on the LDUP wg web site) stands with regard to MUST/MAY (cn) and naming, I think the document, as published, should go forward for last call. With regard to naming, the doc says LDAPsubentry MAY be named by cn, which is where I think the concensus of the list now resides. With regard to MUST/MAY {cn} as an attribute, the document now says MAY, and leaves the class as a STRUCTURAL class. Of course, that means that a naming rule will need to use CN as it's naming attribute if no other attributes are defined on the class, which pretty much turns it into a MUST in those cases, but when other classes are derived from LDAPsubentry other attributes may also be defined, and then cn need not be used as a naming attribute. I think we could also make it be MUST {cn} and require cns to be populated, even if they're not being used to name the LDAPsubentry, and I'll be happy to make that change after last call if needed. I just don't see the need to bother, now. With regard to making LDAPsubentry fully compatible with the X.500 subentry, it's been pointed out that people wanting to use the X.500 subentry should feel free to do so - it's incorporated by reference in the base LDAP definitions. The purpose of this proposal is to define a subset of the X.500 functionality (and extend the structural rules by allowing nesting of LDAPsubentries) for use by certain LDAP applications which find the subset functionality a useful simplification. So - Please, put out the last call for the draft as posted on the LDUP WG IETF Charter page, document draft-ietf-ldup-subentry-02.txt, dated 9 March 2000. Ed ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM From owner-ietf-ldup@mail.imc.org Thu Jul 13 17:00:17 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 RAA27768 for ; Thu, 13 Jul 2000 17:00:16 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA07253 for ietf-ldup-bks; Thu, 13 Jul 2000 12:10:49 -0700 (PDT) Received: from REED.oncalldba.com (pipeline.oncalldba.com [166.70.104.49] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA07247 for ; Thu, 13 Jul 2000 12:10:44 -0700 (PDT) Received: from RMINC_DOM-Message_Server by REED.oncalldba.com with Novell_GroupWise; Thu, 13 Jul 2000 13:12:38 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Thu, 13 Jul 2000 13:12:29 -0600 From: "Ed Reed" To: Cc: , , , , Subject: Please publish draft-ietf-ldup-subentry-03.txt - correct dates in headers and footers Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_9DC5C7B6.D8B9D5CA" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=_9DC5C7B6.D8B9D5CA Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable This document is going out for a joint last call to both the LDAPEXT and = LDUP working groups. Abstract: This document describes an object class called ldapSubEntry=20 which MAY be used to indicate operations and management=20 related entries in the directory, called LDAP Subentries. =20 This version of this document is updated with an assigned=20 OID for the ldapSubEntry object class. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM --=_9DC5C7B6.D8B9D5CA Content-Type: text/plain Content-Disposition: attachment; filename="draft-ietf-ldup-subentry-03.txt" Content-Transfer-Encoding: base64 DQoNCg0KDQoNCg0KSU5URVJORVQtRFJBRlQgDQpkcmFmdC1pZXRmLWxkdXAtc3ViZW50cnktMDMu dHh0IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEVkIFJlZWQgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUmVlZC1N YXR0aGV3cywgSW5jLiANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBKdWx5IDEzLCAyMDAwIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQpMREFQIFN1YmVudHJ5IFNjaGVtYSANCg0KDQoxLiBT dGF0dXMgb2YgdGhpcyBNZW1vIA0KDQpUaGlzIGRvY3VtZW50IGlzIGFuIEludGVybmV0LURyYWZ0 IGFuZCBpcyBpbiBmdWxsIA0KY29uZm9ybWFuY2Ugd2l0aCBhbGwgcHJvdmlzaW9ucyBvZiBTZWN0 aW9uIDEwIG9mIFJGQzIwMjYuIA0KIA0KSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3Vt ZW50cyBvZiB0aGUgSW50ZXJuZXQgDQpFbmdpbmVlcmluZyBUYXNrIEZvcmNlIChJRVRGKSwgaXRz IGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgDQpncm91cHMuIE5vdGUgdGhhdCBvdGhlciBncm91cHMg bWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIA0KZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0 cy4gIA0KIA0KSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEg bWF4aW11bSBvZiANCnNpeCBtb250aHMgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Ig b2Jzb2xldGVkIGJ5IA0Kb3RoZXIgZG9jdW1lbnRzIGF0IGFueSB0aW1lLiBJdCBpcyBpbmFwcHJv cHJpYXRlIHRvIHVzZSANCkludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UgbWF0ZXJpYWwgb3Ig dG8gY2l0ZSB0aGVtIG90aGVyIA0KdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iICANCiANClRo ZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdCANCmh0 dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dC4gIA0KIA0KVGhlIGxpc3Qg b2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSANCmFjY2Vzc2VkIGF0 IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuIA0KIA0KVGhpcyBJbnRlcm5ldC1EcmFm dCBleHBpcmVzIG9uIFNlcHRlbWJlciA5LCAyMDAwLiANCg0KDQoyLiBBYnN0cmFjdCANCg0KVGhp cyBkb2N1bWVudCBkZXNjcmliZXMgYW4gb2JqZWN0IGNsYXNzIGNhbGxlZCBsZGFwU3ViRW50cnkg DQp3aGljaCBNQVkgYmUgdXNlZCB0byBpbmRpY2F0ZSBvcGVyYXRpb25zIGFuZCBtYW5hZ2VtZW50 IA0KcmVsYXRlZCBlbnRyaWVzIGluIHRoZSBkaXJlY3RvcnksIGNhbGxlZCBMREFQIFN1YmVudHJp ZXMuICANClRoaXMgdmVyc2lvbiBvZiB0aGlzIGRvY3VtZW50IGlzIHVwZGF0ZWQgd2l0aCBhbiBh c3NpZ25lZCANCk9JRCBmb3IgdGhlIGxkYXBTdWJFbnRyeSBvYmplY3QgY2xhc3MuIA0KDQpUaGUg a2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgDQoiU0hB TEwgTk9UIiwgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIA0K YW5kICAiT1BUSU9OQUwiIGluIHRoaXMgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFz IA0KZGVzY3JpYmVkIGluIFJGQyAyMTE5IFtSRkMyMTE5XS4gVGhlIHNlY3Rpb25zIGJlbG93IA0K cmVpdGVyYXRlIHRoZXNlIGRlZmluaXRpb25zIGFuZCBpbmNsdWRlIHNvbWUgYWRkaXRpb25hbCAN Cm9uZXMuIA0KDQoNClJlZWQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMV0gDQogICAgICAgICAgICAgICAgICAgICAgIEV4 cGlyZXMgSmFudWFyeSAxNywgMjAwMSANDA0KDQoNCklOVEVSTkVULURSQUZUICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDE3IEp1bHkgMjAwMCANCiAgICAgICAgICAg ICAgICAgICBMREFQIFN1YmVudHJ5IFNjaGVtYSANCg0KMy4gRGVmaW5pdGlvbiANCg0KDQozLjEg bGRhcFN1YkVudHJ5IENsYXNzIA0KDQooIDIuMTYuODQwLjEuMTEzNzE5LjIuMTQyLjYuMS4xIE5B TUUgJ2xkYXBTdWJFbnRyeScgIA0KICAgREVTQyAnTERBUCBTdWJlbnRyeSBjbGFzcywgdmVyc2lv biAxJyAgDQogICAgIFNVUCB0b3AgU1RSVUNUVVJBTCAgDQogICAgIE1BWSAoIGNuICkgKSAgDQoN ClRoZSBjbGFzcyBsZGFwU3ViRW50cnkgaXMgaW50ZW5kZWQgdG8gYmUgdXNlZCBhcyBhIHN1cGVy LSANCmNsYXNzIHdoZW4gZGVmaW5pbmcgb3RoZXIgc3RydWN0dXJhbCBjbGFzc2VzIHRvIGJlIHVz ZWQgDQphcyBMREFQIFN1YmVudHJpZXMsIGFuZCBhcyB0aGUgc3RydWN0dXJhbCBjbGFzcyB0byB3 aGljaCANCkF1eGlsaWFyeSBjbGFzc2VzIG1heSBiZSBhZGRlZCBmb3IgYXBwbGljYXRpb24gc3Bl Y2lmaWMgDQpzdWJlbnRyeSBpbmZvcm1hdGlvbi4gIFdoZXJlIHBvc3NpYmxlLCB0aGUgdXNlIG9m IEF1eGlsaWFyeSANCmNsYXNzZXMgdG8gZXh0ZW5kIGxkYXBTdWJFbnRyaWVzIGlzIHN0cm9uZ2x5 IHByZWZlcnJlZC4gDQogDQpUaGUgcHJlc2VuY2Ugb2YgbGRhcFN1YkVudHJ5IGluIHRoZSBsaXN0 IG9mIHN1cGVyLWNsYXNzZXMgDQpvZiBhbiBlbnRyeSBpbiB0aGUgZGlyZWN0b3J5IG1ha2VzIHRo YXQgZW50cnkgYW4gTERBUCANClN1YmVudHJ5LiAgT2JqZWN0IGNsYXNzZXMgZGVyaXZlZCBmcm9t IGxkYXBTdWJFbnRyeSBhcmUgDQp0aGVtc2VsdmVzIGNvbnNpZGVyZWQgbGRhcFN1YkVudHJ5IGNs YXNzZXMsIGZvciB0aGUgcHVycG9zZSANCm9mIHRoaXMgZGlzY3Vzc2lvbi4gDQoNCkxEQVAgU3Vi ZW50cmllcyBNQVkgYmUgbmFtZWQgYnkgdGhlaXIgY29tbW9uTmFtZSBhdHRyaWJ1dGUgDQpbTERB UHYzXS4gIE90aGVyIG5hbWluZyBhdHRyaWJ1dGVzIGFyZSBhbHNvIHBlcm1pdHRlZC4gDQoNCkxE QVAgU3ViZW50cmllcyBNQVkgYmUgY29udGFpbmVycywgdW5saWtlIHRoZWlyIFtYLjUwMV0gDQpj b3VudGVycGFydHMuIA0KDQpMREFQIFN1YmVudHJpZXMgTUFZIGJlIGNvbnRhaW5lZCBieSwgYW5k IHdpbGwgdXN1YWxseSBiZSANCmxvY2F0ZWQgaW4gdGhlIGRpcmVjdG9yeSBpbmZvcm1hdGlvbiB0 cmVlIGltbWVkaWF0ZWx5IA0Kc3Vib3JkaW5hdGUgdG8sIGFkbWluaXN0cmF0aXZlIHBvaW50cyBh bmQvb3IgbmFtaW5nIA0KY29udGV4dHMuICBGdXJ0aGVyICh1bmxpa2UgWC41MDAgc3ViZW50cmll cyksIExEQVAgDQpTdWJlbnRyaWVzIE1BWSBiZSBjb250YWluZWQgYnkgb3RoZXIgTERBUCBTdWJl bnRyaWVzICh0aGUgDQp3YXkgb3JnYW5pemF0aW9uYWwgdW5pdHMgbWF5IGJlIGNvbnRhaW5lZCBi eSBvdGhlciANCm9yZ2FuaXphdGlvbmFsIHVuaXRzKS4gIERlZXAgbmVzdGluZ3Mgb2YgTERBUCBT dWJlbnRyaWVzIA0KYXJlIGRpc2NvdXJhZ2VkLCBidXQgbm90IHByb2hpYml0ZWQuIA0KDQpMREFQ IFN1YmVudHJpZXMgU0hPVUxEIGJlIHRyZWF0ZWQgYXMgIm9wZXJhdGlvbmFsIG9iamVjdHMiIA0K aW4gbXVjaCB0aGUgc2FtZSB3YXkgdGhhdCAib3BlcmF0aW9uYWwgYXR0cmlidXRlcyIgYXJlIG5v dCANCnJlZ3VsYXJseSBwcm92aWRlZCBpbiBzZWFyY2ggcmVzdWx0cyBhbmQgcmVhZCBvcGVyYXRp b25zIA0Kd2hlbiBvbmx5IHVzZXIgYXR0cmlidXRlcyBhcmUgcmVxdWVzdGVkKS4gICAgDQoNCkxE QVAgc2VydmVycyBTSE9VTEQgaW1wbGVtZW50IHRoZSBmb2xsb3dpbmcgc3BlY2lhbCANCmhhbmRs aW5nIG9mIGxkYXBTdWJFbnRyeSBlbnRyaWVzOiANCg0KYSkgc2VhcmNoIG9wZXJhdGlvbnMgd2hp Y2ggaW5jbHVkZSBhIG1hdGNoaW5nIGNyaXRlcmlhIA0KIm9iamVjdGNsYXNzPWxkYXBTdWJFbnRy eSIgTVVTVCBpbmNsdWRlIGVudHJpZXMgZGVyaXZlZCANCg0KUmVlZCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMl0gDQogICAgICAgICAg ICAgICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSAxNywgMjAwMSANCiANDA0KDQoNCklOVEVSTkVU LURSQUZUICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDE3IEp1bHkg MjAwMCANCiAgICAgICAgICAgICAgICAgICBMREFQIFN1YmVudHJ5IFNjaGVtYSANCg0KZnJvbSB0 aGUgbGRhcFN1YkVudHJ5IGNsYXNzIGluIHRoZSBzY29wZSBvZiB0aGVpciANCm9wZXJhdGlvbnM7 ICAgDQoNCmIpIHNlYXJjaCBvcGVyYXRpb25zIHdoaWNoIGRvIG5vdCBpbmNsdWRlIGEgbWF0Y2hp bmcgDQpjcml0ZXJpYSAib2JqZWN0Y2xhc3M9bGRhcFN1YkVudHJ5IiBNVVNUIElHTk9SRSBlbnRy aWVzIA0KZGVyaXZlZCBmcm9tIHRoZSBsZGFwU3ViRW50cnkgY2xhc3MsIGFuZCBleGNsdWRlIHRo ZW0gZnJvbSANCnRoZSBzY29wZSBvZiB0aGVpciBvcGVyYXRpb25zLiANCg0KVGhlIGNvbWJpbmF0 aW9uIG9mIFNIT1VMRCBhbmQgTVVTVCBpbiB0aGUgc3BlY2lhbCBoYW5kbGluZyANCmluc3RydWN0 aW9ucywgYWJvdmUsIGFyZSBtZWFudCB0byBjb252ZXkgdGhpczogIFNlcnZlcnMgDQpTSE9VTEQg c3VwcG9ydCB0aGlzIHNwZWNpYWwgaGFuZGxpbmcsIGFuZCBpZiB0aGV5IGRvIHRoZXkgDQpNVVNU IGRvIGl0IGFzIGRlc2NyaWJlZCwgYW5kIG5vdCBzb21lIG90aGVyIHdheS4gDQoNCg0KDQo0LiBT ZWN1cml0eSBDb25zaWRlcmF0aW9ucyANCg0KTERBUCBTdWJlbnRyaWVzIHdpbGwgZnJlcXVlbnRs eSBiZSB1c2VkIHRvIGhvbGQgZGF0YSB3aGljaCANCnJlZmxlY3RzIGVpdGhlciB0aGUgYWN0dWFs IG9yIGludGVuZGVkIGJlaGF2aW9yIG9mIHRoZSANCmRpcmVjdG9yeSBzZXJ2aWNlLiAgQXMgc3Vj aCwgcGVybWlzc2lvbiB0byByZWFkIHN1Y2ggDQplbnRyaWVzIE1BWSBuZWVkIHRvIGJlIHJlc3Ry aWN0ZWQgdG8gYXV0aG9yaXplZCB1c2Vycy4gIA0KTW9yZSBpbXBvcnRhbnRseSwgSUYgYSBkaXJl Y3Rvcnkgc2VydmljZSB0cmVhdHMgdGhlIA0KaW5mb3JtYXRpb24gaW4gYW4gTERBUCBTdWJlbnRy eSBhcyB0aGUgYXV0aG9yaXRhdGl2ZSBzb3VyY2UgDQpvZiBwb2xpY3kgdG8gYmUgdXNlZCB0byBj b250cm9sIHRoZSBiZWhhdmlvciBvZiB0aGUgDQpkaXJlY3RvcnksIHRoZW4gcGVybWlzc2lvbiB0 byBjcmVhdGUsIG1vZGlmeSwgb3IgZGVsZXRlIA0Kc3VjaCBlbnRyaWVzIE1VU1QgYmUgY2FyZWZ1 bGx5IHJlc3RyaWN0ZWQgdG8gYXV0aG9yaXplZCANCmFkbWluaXN0cmF0b3JzLiANCg0KDQoNCjUu IFJlZmVyZW5jZXMgDQoNCltMREFQdjNdIFMuIEtpbGxlLCBNLiBXYWhsLCBhbmQgVC4gSG93ZXMs ICJMaWdodHdlaWdodCANCkRpcmVjdG9yeSBBY2Nlc3MgUHJvdG9jb2wgKHYzKSIsIFJGQyAyMjUx LCBEZWNlbWJlciAxOTk3IA0KDQpbWC41MDFdIElUVS1UIFJlYy4gWC41MDEsICJUaGUgRGlyZWN0 b3J5OiBNb2RlbHMiLCAxOTkzIA0KDQoNCg0KNi4gQ29weXJpZ2h0IE5vdGljZSANCg0KQ29weXJp Z2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMTk5OSkuIEFsbCBSaWdodHMgDQpSZXNlcnZl ZC4gIA0KIA0KVGhpcyBkb2N1bWVudCBhbmQgdHJhbnNsYXRpb25zIG9mIGl0IG1heSBiZSBjb3Bp ZWQgYW5kIA0KZnVybmlzaGVkIHRvIG90aGVycywgYW5kIGRlcml2YXRpdmUgd29ya3MgdGhhdCBj b21tZW50IG9uIA0Kb3Igb3RoZXJ3aXNlIGV4cGxhaW4gaXQgb3IgYXNzaXN0IGluIGl0cyBpbXBs ZW1lbnRhdGlvbiBtYXkgDQpiZSBwcmVwYXJlZCwgY29waWVkLCBwdWJsaXNoZWQgYW5kIGRpc3Ry aWJ1dGVkLCBpbiB3aG9sZSBvciANCg0KUmVlZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgM10gDQogICAgICAgICAgICAgICAgICAgICAg IEV4cGlyZXMgSmFudWFyeSAxNywgMjAwMSANCiANDA0KDQoNCklOVEVSTkVULURSQUZUICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDE3IEp1bHkgMjAwMCANCiAgICAg ICAgICAgICAgICAgICBMREFQIFN1YmVudHJ5IFNjaGVtYSANCg0KaW4gcGFydCwgd2l0aG91dCBy ZXN0cmljdGlvbiBvZiBhbnkga2luZCwgcHJvdmlkZWQgdGhhdCB0aGUgDQphYm92ZSBjb3B5cmln aHQgbm90aWNlIGFuZCB0aGlzIHBhcmFncmFwaCBhcmUgaW5jbHVkZWQgb24gDQphbGwgc3VjaCBj b3BpZXMgYW5kIGRlcml2YXRpdmUgd29ya3MuIEhvd2V2ZXIsIHRoaXMgDQpkb2N1bWVudCBpdHNl bGYgbWF5IG5vdCBiZSBtb2RpZmllZCBpbiBhbnkgd2F5LCBzdWNoIGFzIGJ5IA0KcmVtb3Zpbmcg dGhlIGNvcHlyaWdodCBub3RpY2Ugb3IgcmVmZXJlbmNlcyB0byB0aGUgSW50ZXJuZXQgDQpTb2Np ZXR5IG9yIG90aGVyIEludGVybmV0IG9yZ2FuaXphdGlvbnMsIGV4Y2VwdCBhcyBuZWVkZWQgDQpm b3IgdGhlIHB1cnBvc2Ugb2YgZGV2ZWxvcGluZyBJbnRlcm5ldCBzdGFuZGFyZHMgaW4gd2hpY2gg DQpjYXNlIHRoZSBwcm9jZWR1cmVzIGZvciBjb3B5cmlnaHRzIGRlZmluZWQgaW4gdGhlIEludGVy bmV0IA0KU3RhbmRhcmRzIHByb2Nlc3MgbXVzdCBiZSBmb2xsb3dlZCwgb3IgYXMgcmVxdWlyZWQg dG8gDQp0cmFuc2xhdGUgaXQgaW50byBsYW5ndWFnZXMgb3RoZXIgdGhhbiBFbmdsaXNoLiANCiAN ClRoZSBsaW1pdGVkIHBlcm1pc3Npb25zIGdyYW50ZWQgYWJvdmUgYXJlIHBlcnBldHVhbCBhbmQg DQp3aWxsIG5vdCBiZSByZXZva2VkIGJ5IHRoZSBJbnRlcm5ldCBTb2NpZXR5IG9yIGl0cyANCnN1 Y2Nlc3NvcnMgb3IgYXNzaWducy4gDQogDQpUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3JtYXRp b24gY29udGFpbmVkIGhlcmVpbiBpcyANCnByb3ZpZGVkIG9uIGFuICJBUyBJUyIgYmFzaXMgYW5k IFRIRSBJTlRFUk5FVCBTT0NJRVRZIEFORCANClRIRSBJTlRFUk5FVCBFTkdJTkVFUklORyBUQVNL IEZPUkNFIERJU0NMQUlNUyBBTEwgDQpXQVJSQU5USUVTLCBFWFBSRVNTIE9SIElNUExJRUQsIElO Q0xVRElORyBCVVQgTk9UIExJTUlURUQgDQpUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9G IFRIRSBJTkZPUk1BVElPTiBIRVJFSU4gV0lMTCANCk5PVCBJTkZSSU5HRSBBTlkgUklHSFRTIE9S IEFOWSBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgDQpNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBG T1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuIiANCg0KDQo3LiBBY2tub3dsZWRnZW1lbnRzIA0KDQpU aGUgdXNlIG9mIHN1YkVudHJ5IG9iamVjdCBjbGFzcyB0byBzdG9yZSBSZXBsaWNhIGFuZCANClJl cGxpY2F0aW9uIEFncmVlbWVudCBpbmZvcm1hdGlvbiBpcyBkdWUgcHJpbWFyaWx5IHRvIHRoZSAN Cmx1Y2lkIGV4cGxhbmF0aW9uIGJ5IE1hcmsgV2FobCwgSW5ub3NvZnQsIG9mIGhvdyB0aGV5IGNv dWxkIA0KYmUgdXNlZCBhbmQgZXh0ZW5kZWQuIA0KIA0KVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRp b24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSANCm9mIGFueSBpbnRlbGxlY3R1YWwg cHJvcGVydHkgb3Igb3RoZXIgcmlnaHRzIHRoYXQgbWlnaHQgYmUgDQpjbGFpbWVkIHRvIHBlcnRh aW4gdG8gdGhlIGltcGxlbWVudGF0aW9uIG9yIHVzZSBvZiB0aGUgDQp0ZWNobm9sb2d5IGRlc2Ny aWJlZCBpbiB0aGlzIGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8gDQp3aGljaCBhbnkgbGljZW5z ZSB1bmRlciBzdWNoIHJpZ2h0cyBtaWdodCBvciBtaWdodCBub3QgYmUgDQphdmFpbGFibGU7IG5l aXRoZXIgZG9lcyBpdCByZXByZXNlbnQgdGhhdCBpdCBoYXMgbWFkZSBhbnkgDQplZmZvcnQgdG8g aWRlbnRpZnkgYW55IHN1Y2ggcmlnaHRzLiBJbmZvcm1hdGlvbiBvbiB0aGUgDQpJRVRGJ3MgcHJv Y2VkdXJlcyB3aXRoIHJlc3BlY3QgdG8gcmlnaHRzIGluIHN0YW5kYXJkcy10cmFjayANCmFuZCBz dGFuZGFyZHMtcmVsYXRlZCBkb2N1bWVudGF0aW9uIGNhbiBiZSBmb3VuZCBpbiBCQ1AtMTEuIA0K Q29waWVzIG9mIGNsYWltcyBvZiByaWdodHMgbWFkZSBhdmFpbGFibGUgZm9yIHB1YmxpY2F0aW9u IA0KYW5kIGFueSBhc3N1cmFuY2VzIG9mIGxpY2Vuc2VzIHRvIGJlIG1hZGUgYXZhaWxhYmxlLCBv ciB0aGUgDQpyZXN1bHQgb2YgYW4gYXR0ZW1wdCBtYWRlIHRvIG9idGFpbiBhIGdlbmVyYWwgbGlj ZW5zZSBvciANCnBlcm1pc3Npb24gZm9yIHRoZSB1c2Ugb2Ygc3VjaCBwcm9wcmlldGFyeSByaWdo dHMgYnkgDQppbXBsZW1lbnRvcnMgb3IgdXNlcnMgb2YgdGhpcyBzcGVjaWZpY2F0aW9uIGNhbiBi ZSBvYnRhaW5lZCANCmZyb20gdGhlIElFVEYgU2VjcmV0YXJpYXQuIA0KIA0KDQoNClJlZWQgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDRd IA0KICAgICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTcsIDIwMDEgDQogDQwN Cg0KDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAxNyBKdWx5IDIwMDAgDQogICAgICAgICAgICAgICAgICAgTERBUCBTdWJlbnRyeSBTY2hl bWEgDQoNClRoZSBJRVRGIGludml0ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8g aXRzIA0KYXR0ZW50aW9uIGFueSBjb3B5cmlnaHRzLCBwYXRlbnRzIG9yIHBhdGVudCBhcHBsaWNh dGlvbnMsIA0Kb3Igb3RoZXIgcHJvcHJpZXRhcnkgcmlnaHRzIHdoaWNoIG1heSBjb3ZlciB0ZWNo bm9sb2d5IHRoYXQgDQptYXkgYmUgcmVxdWlyZWQgdG8gcHJhY3RpY2UgdGhpcyBzdGFuZGFyZC4g UGxlYXNlIGFkZHJlc3MgDQp0aGUgaW5mb3JtYXRpb24gdG8gdGhlIElFVEYgRXhlY3V0aXZlIERp cmVjdG9yLiANCg0KDQo4LiBBdXRob3IncyBBZGRyZXNzIA0KDQogICAgIEVkd2FyZHMgRS4gUmVl ZCANCiAgICAgUmVlZC1NYXR0aGV3cywgSW5jLiANCiAgICAgMTA2NCBFIDE0MCBOb3J0aCANCiAg ICAgTGluZG9uLCBVVCAgODQwNDIgDQogICAgIFVTQSANCiAgICAgRS1tYWlsOiBlZXJAb25jYWxs ZGJhLmNvbSAgDQogICAgICANCiAgICAgTERVUCBNYWlsaW5nIExpc3Q6IGlldGYtbGR1cEBpbWMu b3JnICANCiAgICAgTERBUEVYVCBNYWlsaW5nIExpc3Q6IGlldGYtbGRhcGV4dEBuZXRzY2FwZS5j b20gDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNClJlZWQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFtQYWdlIDVdIA0KICAgICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEphbnVh cnkgMTcsIDIwMDEgDQogDQwNCg== --=_9DC5C7B6.D8B9D5CA-- From owner-ietf-ldup@mail.imc.org Thu Jul 13 17:13:37 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 RAA03376 for ; Thu, 13 Jul 2000 17:13:37 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA07073 for ietf-ldup-bks; Thu, 13 Jul 2000 12:05:50 -0700 (PDT) Received: from REED.oncalldba.com (pipeline.oncalldba.com [166.70.104.49] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA07069 for ; Thu, 13 Jul 2000 12:05:47 -0700 (PDT) Received: from RMINC_DOM-Message_Server by REED.oncalldba.com with Novell_GroupWise; Thu, 13 Jul 2000 13:07:36 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Thu, 13 Jul 2000 13:07:06 -0600 From: "Ed Reed" To: Cc: , , , , Subject: Please publish draft-ietf-ldup-subentry-03.txt (true sequence number) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_441C1E68.D1B0DCC3" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=_441C1E68.D1B0DCC3 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable This document is going out for a joint last call to both the LDAPEXT and = LDUP working groups. Abstract: This document describes an object class called ldapSubEntry=20 which MAY be used to indicate operations and management=20 related entries in the directory, called LDAP Subentries. =20 This version of this document is updated with an assigned=20 OID for the ldapSubEntry object class. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM --=_441C1E68.D1B0DCC3 Content-Type: text/plain Content-Disposition: attachment; filename="draft-ietf-ldup-subentry-03.txt" Content-Transfer-Encoding: base64 DQoNCg0KDQoNCg0KSU5URVJORVQtRFJBRlQgDQpkcmFmdC1pZXRmLWxkdXAtc3ViZW50cnktMDMu dHh0IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEVkIFJlZWQgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUmVlZC1N YXR0aGV3cywgSW5jLiANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBKdWx5IDEzLCAyMDAwIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQpMREFQIFN1YmVudHJ5IFNjaGVtYSANCg0KDQoxLiBT dGF0dXMgb2YgdGhpcyBNZW1vIA0KDQpUaGlzIGRvY3VtZW50IGlzIGFuIEludGVybmV0LURyYWZ0 IGFuZCBpcyBpbiBmdWxsIA0KY29uZm9ybWFuY2Ugd2l0aCBhbGwgcHJvdmlzaW9ucyBvZiBTZWN0 aW9uIDEwIG9mIFJGQzIwMjYuIA0KIA0KSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3Vt ZW50cyBvZiB0aGUgSW50ZXJuZXQgDQpFbmdpbmVlcmluZyBUYXNrIEZvcmNlIChJRVRGKSwgaXRz IGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgDQpncm91cHMuIE5vdGUgdGhhdCBvdGhlciBncm91cHMg bWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIA0KZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0 cy4gIA0KIA0KSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEg bWF4aW11bSBvZiANCnNpeCBtb250aHMgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Ig b2Jzb2xldGVkIGJ5IA0Kb3RoZXIgZG9jdW1lbnRzIGF0IGFueSB0aW1lLiBJdCBpcyBpbmFwcHJv cHJpYXRlIHRvIHVzZSANCkludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UgbWF0ZXJpYWwgb3Ig dG8gY2l0ZSB0aGVtIG90aGVyIA0KdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iICANCiANClRo ZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdCANCmh0 dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dC4gIA0KIA0KVGhlIGxpc3Qg b2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSANCmFjY2Vzc2VkIGF0 IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuIA0KIA0KVGhpcyBJbnRlcm5ldC1EcmFm dCBleHBpcmVzIG9uIFNlcHRlbWJlciA5LCAyMDAwLiANCg0KDQoyLiBBYnN0cmFjdCANCg0KVGhp cyBkb2N1bWVudCBkZXNjcmliZXMgYW4gb2JqZWN0IGNsYXNzIGNhbGxlZCBsZGFwU3ViRW50cnkg DQp3aGljaCBNQVkgYmUgdXNlZCB0byBpbmRpY2F0ZSBvcGVyYXRpb25zIGFuZCBtYW5hZ2VtZW50 IA0KcmVsYXRlZCBlbnRyaWVzIGluIHRoZSBkaXJlY3RvcnksIGNhbGxlZCBMREFQIFN1YmVudHJp ZXMuICANClRoaXMgdmVyc2lvbiBvZiB0aGlzIGRvY3VtZW50IGlzIHVwZGF0ZWQgd2l0aCBhbiBh c3NpZ25lZCANCk9JRCBmb3IgdGhlIGxkYXBTdWJFbnRyeSBvYmplY3QgY2xhc3MuIA0KDQpUaGUg a2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgDQoiU0hB TEwgTk9UIiwgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIA0K YW5kICAiT1BUSU9OQUwiIGluIHRoaXMgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFz IA0KZGVzY3JpYmVkIGluIFJGQyAyMTE5IFtSRkMyMTE5XS4gVGhlIHNlY3Rpb25zIGJlbG93IA0K cmVpdGVyYXRlIHRoZXNlIGRlZmluaXRpb25zIGFuZCBpbmNsdWRlIHNvbWUgYWRkaXRpb25hbCAN Cm9uZXMuIA0KDQoNClJlZWQNICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDFdIA0KICAgICAgICAgICAgICAgICAgICAgIEV4 cGlyZXMgU2VwdGVtYmVyIDksIDIwMDAgDQwNCg0KDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA5IE1hcmNoIDIwMDAgDQogICAgICAgICAg ICAgICAgICAgTERBUCBTdWJlbnRyeSBTY2hlbWEgDQoNCjMuIERlZmluaXRpb24gDQoNCg0KMy4x IGxkYXBTdWJFbnRyeSBDbGFzcyANCg0KKCAyLjE2Ljg0MC4xLjExMzcxOS4yLjE0Mi42LjEuMSBO QU1FICdsZGFwU3ViRW50cnknICANCiAgIERFU0MgJ0xEQVAgU3ViZW50cnkgY2xhc3MsIHZlcnNp b24gMScgIA0KICAgICBTVVAgdG9wIFNUUlVDVFVSQUwgIA0KICAgICBNQVkgKCBjbiApICkgIA0K DQpUaGUgY2xhc3MgbGRhcFN1YkVudHJ5IGlzIGludGVuZGVkIHRvIGJlIHVzZWQgYXMgYSBzdXBl ci0gDQpjbGFzcyB3aGVuIGRlZmluaW5nIG90aGVyIHN0cnVjdHVyYWwgY2xhc3NlcyB0byBiZSB1 c2VkIA0KYXMgTERBUCBTdWJlbnRyaWVzLCBhbmQgYXMgdGhlIHN0cnVjdHVyYWwgY2xhc3MgdG8g d2hpY2ggDQpBdXhpbGlhcnkgY2xhc3NlcyBtYXkgYmUgYWRkZWQgZm9yIGFwcGxpY2F0aW9uIHNw ZWNpZmljIA0Kc3ViZW50cnkgaW5mb3JtYXRpb24uICBXaGVyZSBwb3NzaWJsZSwgdGhlIHVzZSBv ZiBBdXhpbGlhcnkgDQpjbGFzc2VzIHRvIGV4dGVuZCBsZGFwU3ViRW50cmllcyBpcyBzdHJvbmds eSBwcmVmZXJyZWQuIA0KIA0KVGhlIHByZXNlbmNlIG9mIGxkYXBTdWJFbnRyeSBpbiB0aGUgbGlz dCBvZiBzdXBlci1jbGFzc2VzIA0Kb2YgYW4gZW50cnkgaW4gdGhlIGRpcmVjdG9yeSBtYWtlcyB0 aGF0IGVudHJ5IGFuIExEQVAgDQpTdWJlbnRyeS4gIE9iamVjdCBjbGFzc2VzIGRlcml2ZWQgZnJv bSBsZGFwU3ViRW50cnkgYXJlIA0KdGhlbXNlbHZlcyBjb25zaWRlcmVkIGxkYXBTdWJFbnRyeSBj bGFzc2VzLCBmb3IgdGhlIHB1cnBvc2UgDQpvZiB0aGlzIGRpc2N1c3Npb24uIA0KDQpMREFQIFN1 YmVudHJpZXMgTUFZIGJlIG5hbWVkIGJ5IHRoZWlyIGNvbW1vbk5hbWUgYXR0cmlidXRlIA0KW0xE QVB2M10uICBPdGhlciBuYW1pbmcgYXR0cmlidXRlcyBhcmUgYWxzbyBwZXJtaXR0ZWQuIA0KDQpM REFQIFN1YmVudHJpZXMgTUFZIGJlIGNvbnRhaW5lcnMsIHVubGlrZSB0aGVpciBbWC41MDFdIA0K Y291bnRlcnBhcnRzLiANCg0KTERBUCBTdWJlbnRyaWVzIE1BWSBiZSBjb250YWluZWQgYnksIGFu ZCB3aWxsIHVzdWFsbHkgYmUgDQpsb2NhdGVkIGluIHRoZSBkaXJlY3RvcnkgaW5mb3JtYXRpb24g dHJlZSBpbW1lZGlhdGVseSANCnN1Ym9yZGluYXRlIHRvLCBhZG1pbmlzdHJhdGl2ZSBwb2ludHMg YW5kL29yIG5hbWluZyANCmNvbnRleHRzLiAgRnVydGhlciAodW5saWtlIFguNTAwIHN1YmVudHJp ZXMpLCBMREFQIA0KU3ViZW50cmllcyBNQVkgYmUgY29udGFpbmVkIGJ5IG90aGVyIExEQVAgU3Vi ZW50cmllcyAodGhlIA0Kd2F5IG9yZ2FuaXphdGlvbmFsIHVuaXRzIG1heSBiZSBjb250YWluZWQg Ynkgb3RoZXIgDQpvcmdhbml6YXRpb25hbCB1bml0cykuICBEZWVwIG5lc3RpbmdzIG9mIExEQVAg U3ViZW50cmllcyANCmFyZSBkaXNjb3VyYWdlZCwgYnV0IG5vdCBwcm9oaWJpdGVkLiANCg0KTERB UCBTdWJlbnRyaWVzIFNIT1VMRCBiZSB0cmVhdGVkIGFzICJvcGVyYXRpb25hbCBvYmplY3RzIiAN CmluIG11Y2ggdGhlIHNhbWUgd2F5IHRoYXQgIm9wZXJhdGlvbmFsIGF0dHJpYnV0ZXMiIGFyZSBu b3QgDQpyZWd1bGFybHkgcHJvdmlkZWQgaW4gc2VhcmNoIHJlc3VsdHMgYW5kIHJlYWQgb3BlcmF0 aW9ucyANCndoZW4gb25seSB1c2VyIGF0dHJpYnV0ZXMgYXJlIHJlcXVlc3RlZCkuICAgIA0KDQpM REFQIHNlcnZlcnMgU0hPVUxEIGltcGxlbWVudCB0aGUgZm9sbG93aW5nIHNwZWNpYWwgDQpoYW5k bGluZyBvZiBsZGFwU3ViRW50cnkgZW50cmllczogDQoNCmEpIHNlYXJjaCBvcGVyYXRpb25zIHdo aWNoIGluY2x1ZGUgYSBtYXRjaGluZyBjcml0ZXJpYSANCiJvYmplY3RjbGFzcz1sZGFwU3ViRW50 cnkiIE1VU1QgaW5jbHVkZSBlbnRyaWVzIGRlcml2ZWQgDQoNClJlZWQgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAyXSANCiAgICAgICAg ICAgICAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciA5LCAyMDAwIA0KIA0MDQoNCg0KSU5URVJO RVQtRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOSBNYXJj aCAyMDAwIA0KICAgICAgICAgICAgICAgICAgIExEQVAgU3ViZW50cnkgU2NoZW1hIA0KDQpmcm9t IHRoZSBsZGFwU3ViRW50cnkgY2xhc3MgaW4gdGhlIHNjb3BlIG9mIHRoZWlyIA0Kb3BlcmF0aW9u czsgICANCg0KYikgc2VhcmNoIG9wZXJhdGlvbnMgd2hpY2ggZG8gbm90IGluY2x1ZGUgYSBtYXRj aGluZyANCmNyaXRlcmlhICJvYmplY3RjbGFzcz1sZGFwU3ViRW50cnkiIE1VU1QgSUdOT1JFIGVu dHJpZXMgDQpkZXJpdmVkIGZyb20gdGhlIGxkYXBTdWJFbnRyeSBjbGFzcywgYW5kIGV4Y2x1ZGUg dGhlbSBmcm9tIA0KdGhlIHNjb3BlIG9mIHRoZWlyIG9wZXJhdGlvbnMuIA0KDQpUaGUgY29tYmlu YXRpb24gb2YgU0hPVUxEIGFuZCBNVVNUIGluIHRoZSBzcGVjaWFsIGhhbmRsaW5nIA0KaW5zdHJ1 Y3Rpb25zLCBhYm92ZSwgYXJlIG1lYW50IHRvIGNvbnZleSB0aGlzOiAgU2VydmVycyANClNIT1VM RCBzdXBwb3J0IHRoaXMgc3BlY2lhbCBoYW5kbGluZywgYW5kIGlmIHRoZXkgZG8gdGhleSANCk1V U1QgZG8gaXQgYXMgZGVzY3JpYmVkLCBhbmQgbm90IHNvbWUgb3RoZXIgd2F5LiANCg0KDQoNCjQu IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIA0KDQpMREFQIFN1YmVudHJpZXMgd2lsbCBmcmVxdWVu dGx5IGJlIHVzZWQgdG8gaG9sZCBkYXRhIHdoaWNoIA0KcmVmbGVjdHMgZWl0aGVyIHRoZSBhY3R1 YWwgb3IgaW50ZW5kZWQgYmVoYXZpb3Igb2YgdGhlIA0KZGlyZWN0b3J5IHNlcnZpY2UuICBBcyBz dWNoLCBwZXJtaXNzaW9uIHRvIHJlYWQgc3VjaCANCmVudHJpZXMgTUFZIG5lZWQgdG8gYmUgcmVz dHJpY3RlZCB0byBhdXRob3JpemVkIHVzZXJzLiAgDQpNb3JlIGltcG9ydGFudGx5LCBJRiBhIGRp cmVjdG9yeSBzZXJ2aWNlIHRyZWF0cyB0aGUgDQppbmZvcm1hdGlvbiBpbiBhbiBMREFQIFN1YmVu dHJ5IGFzIHRoZSBhdXRob3JpdGF0aXZlIHNvdXJjZSANCm9mIHBvbGljeSB0byBiZSB1c2VkIHRv IGNvbnRyb2wgdGhlIGJlaGF2aW9yIG9mIHRoZSANCmRpcmVjdG9yeSwgdGhlbiBwZXJtaXNzaW9u IHRvIGNyZWF0ZSwgbW9kaWZ5LCBvciBkZWxldGUgDQpzdWNoIGVudHJpZXMgTVVTVCBiZSBjYXJl ZnVsbHkgcmVzdHJpY3RlZCB0byBhdXRob3JpemVkIA0KYWRtaW5pc3RyYXRvcnMuIA0KDQoNCg0K NS4gUmVmZXJlbmNlcyANCg0KW0xEQVB2M10gUy4gS2lsbGUsIE0uIFdhaGwsIGFuZCBULiBIb3dl cywgIkxpZ2h0d2VpZ2h0IA0KRGlyZWN0b3J5IEFjY2VzcyBQcm90b2NvbCAodjMpIiwgUkZDIDIy NTEsIERlY2VtYmVyIDE5OTcgDQoNCltYLjUwMV0gSVRVLVQgUmVjLiBYLjUwMSwgIlRoZSBEaXJl Y3Rvcnk6IE1vZGVscyIsIDE5OTMgDQoNCg0KDQo2LiBDb3B5cmlnaHQgTm90aWNlIA0KDQpDb3B5 cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgxOTk5KS4gQWxsIFJpZ2h0cyANClJlc2Vy dmVkLiAgDQogDQpUaGlzIGRvY3VtZW50IGFuZCB0cmFuc2xhdGlvbnMgb2YgaXQgbWF5IGJlIGNv cGllZCBhbmQgDQpmdXJuaXNoZWQgdG8gb3RoZXJzLCBhbmQgZGVyaXZhdGl2ZSB3b3JrcyB0aGF0 IGNvbW1lbnQgb24gDQpvciBvdGhlcndpc2UgZXhwbGFpbiBpdCBvciBhc3Npc3QgaW4gaXRzIGlt cGxlbWVudGF0aW9uIG1heSANCmJlIHByZXBhcmVkLCBjb3BpZWQsIHB1Ymxpc2hlZCBhbmQgZGlz dHJpYnV0ZWQsIGluIHdob2xlIG9yIA0KDQpSZWVkICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgM10gDQogICAgICAgICAgICAgICAgICAg ICAgRXhwaXJlcyBTZXB0ZW1iZXIgOSwgMjAwMCANCiANDA0KDQoNCklOVEVSTkVULURSQUZUICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDkgTWFyY2ggMjAwMCANCiAg ICAgICAgICAgICAgICAgICBMREFQIFN1YmVudHJ5IFNjaGVtYSANCg0KaW4gcGFydCwgd2l0aG91 dCByZXN0cmljdGlvbiBvZiBhbnkga2luZCwgcHJvdmlkZWQgdGhhdCB0aGUgDQphYm92ZSBjb3B5 cmlnaHQgbm90aWNlIGFuZCB0aGlzIHBhcmFncmFwaCBhcmUgaW5jbHVkZWQgb24gDQphbGwgc3Vj aCBjb3BpZXMgYW5kIGRlcml2YXRpdmUgd29ya3MuIEhvd2V2ZXIsIHRoaXMgDQpkb2N1bWVudCBp dHNlbGYgbWF5IG5vdCBiZSBtb2RpZmllZCBpbiBhbnkgd2F5LCBzdWNoIGFzIGJ5IA0KcmVtb3Zp bmcgdGhlIGNvcHlyaWdodCBub3RpY2Ugb3IgcmVmZXJlbmNlcyB0byB0aGUgSW50ZXJuZXQgDQpT b2NpZXR5IG9yIG90aGVyIEludGVybmV0IG9yZ2FuaXphdGlvbnMsIGV4Y2VwdCBhcyBuZWVkZWQg DQpmb3IgdGhlIHB1cnBvc2Ugb2YgZGV2ZWxvcGluZyBJbnRlcm5ldCBzdGFuZGFyZHMgaW4gd2hp Y2ggDQpjYXNlIHRoZSBwcm9jZWR1cmVzIGZvciBjb3B5cmlnaHRzIGRlZmluZWQgaW4gdGhlIElu dGVybmV0IA0KU3RhbmRhcmRzIHByb2Nlc3MgbXVzdCBiZSBmb2xsb3dlZCwgb3IgYXMgcmVxdWly ZWQgdG8gDQp0cmFuc2xhdGUgaXQgaW50byBsYW5ndWFnZXMgb3RoZXIgdGhhbiBFbmdsaXNoLiAN CiANClRoZSBsaW1pdGVkIHBlcm1pc3Npb25zIGdyYW50ZWQgYWJvdmUgYXJlIHBlcnBldHVhbCBh bmQgDQp3aWxsIG5vdCBiZSByZXZva2VkIGJ5IHRoZSBJbnRlcm5ldCBTb2NpZXR5IG9yIGl0cyAN CnN1Y2Nlc3NvcnMgb3IgYXNzaWducy4gDQogDQpUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3Jt YXRpb24gY29udGFpbmVkIGhlcmVpbiBpcyANCnByb3ZpZGVkIG9uIGFuICJBUyBJUyIgYmFzaXMg YW5kIFRIRSBJTlRFUk5FVCBTT0NJRVRZIEFORCANClRIRSBJTlRFUk5FVCBFTkdJTkVFUklORyBU QVNLIEZPUkNFIERJU0NMQUlNUyBBTEwgDQpXQVJSQU5USUVTLCBFWFBSRVNTIE9SIElNUExJRUQs IElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgDQpUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNF IE9GIFRIRSBJTkZPUk1BVElPTiBIRVJFSU4gV0lMTCANCk5PVCBJTkZSSU5HRSBBTlkgUklHSFRT IE9SIEFOWSBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgDQpNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVT UyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuIiANCg0KDQo3LiBBY2tub3dsZWRnZW1lbnRzIA0K DQpUaGUgdXNlIG9mIHN1YkVudHJ5IG9iamVjdCBjbGFzcyB0byBzdG9yZSBSZXBsaWNhIGFuZCAN ClJlcGxpY2F0aW9uIEFncmVlbWVudCBpbmZvcm1hdGlvbiBpcyBkdWUgcHJpbWFyaWx5IHRvIHRo ZSANCmx1Y2lkIGV4cGxhbmF0aW9uIGJ5IE1hcmsgV2FobCwgSW5ub3NvZnQsIG9mIGhvdyB0aGV5 IGNvdWxkIA0KYmUgdXNlZCBhbmQgZXh0ZW5kZWQuIA0KIA0KVGhlIElFVEYgdGFrZXMgbm8gcG9z aXRpb24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSANCm9mIGFueSBpbnRlbGxlY3R1 YWwgcHJvcGVydHkgb3Igb3RoZXIgcmlnaHRzIHRoYXQgbWlnaHQgYmUgDQpjbGFpbWVkIHRvIHBl cnRhaW4gdG8gdGhlIGltcGxlbWVudGF0aW9uIG9yIHVzZSBvZiB0aGUgDQp0ZWNobm9sb2d5IGRl c2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8gDQp3aGljaCBhbnkgbGlj ZW5zZSB1bmRlciBzdWNoIHJpZ2h0cyBtaWdodCBvciBtaWdodCBub3QgYmUgDQphdmFpbGFibGU7 IG5laXRoZXIgZG9lcyBpdCByZXByZXNlbnQgdGhhdCBpdCBoYXMgbWFkZSBhbnkgDQplZmZvcnQg dG8gaWRlbnRpZnkgYW55IHN1Y2ggcmlnaHRzLiBJbmZvcm1hdGlvbiBvbiB0aGUgDQpJRVRGJ3Mg cHJvY2VkdXJlcyB3aXRoIHJlc3BlY3QgdG8gcmlnaHRzIGluIHN0YW5kYXJkcy10cmFjayANCmFu ZCBzdGFuZGFyZHMtcmVsYXRlZCBkb2N1bWVudGF0aW9uIGNhbiBiZSBmb3VuZCBpbiBCQ1AtMTEu IA0KQ29waWVzIG9mIGNsYWltcyBvZiByaWdodHMgbWFkZSBhdmFpbGFibGUgZm9yIHB1YmxpY2F0 aW9uIA0KYW5kIGFueSBhc3N1cmFuY2VzIG9mIGxpY2Vuc2VzIHRvIGJlIG1hZGUgYXZhaWxhYmxl LCBvciB0aGUgDQpyZXN1bHQgb2YgYW4gYXR0ZW1wdCBtYWRlIHRvIG9idGFpbiBhIGdlbmVyYWwg bGljZW5zZSBvciANCnBlcm1pc3Npb24gZm9yIHRoZSB1c2Ugb2Ygc3VjaCBwcm9wcmlldGFyeSBy aWdodHMgYnkgDQppbXBsZW1lbnRvcnMgb3IgdXNlcnMgb2YgdGhpcyBzcGVjaWZpY2F0aW9uIGNh biBiZSBvYnRhaW5lZCANCmZyb20gdGhlIElFVEYgU2VjcmV0YXJpYXQuIA0KIA0KDQoNClJlZWQg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFn ZSA0XSANCiAgICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciA5LCAyMDAwIA0K IA0MDQoNCg0KSU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgOSBNYXJjaCAyMDAwIA0KICAgICAgICAgICAgICAgICAgIExEQVAgU3ViZW50cnkg U2NoZW1hIA0KDQpUaGUgSUVURiBpbnZpdGVzIGFueSBpbnRlcmVzdGVkIHBhcnR5IHRvIGJyaW5n IHRvIGl0cyANCmF0dGVudGlvbiBhbnkgY29weXJpZ2h0cywgcGF0ZW50cyBvciBwYXRlbnQgYXBw bGljYXRpb25zLCANCm9yIG90aGVyIHByb3ByaWV0YXJ5IHJpZ2h0cyB3aGljaCBtYXkgY292ZXIg dGVjaG5vbG9neSB0aGF0IA0KbWF5IGJlIHJlcXVpcmVkIHRvIHByYWN0aWNlIHRoaXMgc3RhbmRh cmQuIFBsZWFzZSBhZGRyZXNzIA0KdGhlIGluZm9ybWF0aW9uIHRvIHRoZSBJRVRGIEV4ZWN1dGl2 ZSBEaXJlY3Rvci4gDQoNCg0KOC4gQXV0aG9yJ3MgQWRkcmVzcyANCg0KICAgICBFZHdhcmRzIEUu IFJlZWQgDQogICAgIFJlZWQtTWF0dGhld3MsIEluYy4gDQogICAgIDEwNjQgRSAxNDAgTm9ydGgg DQogICAgIExpbmRvbiwgVVQgIDg0MDQyIA0KICAgICBVU0EgDQogICAgIEUtbWFpbDogZWVyQG9u Y2FsbGRiYS5jb20gIA0KICAgICAgDQogICAgIExEVVAgTWFpbGluZyBMaXN0OiBpZXRmLWxkdXBA aW1jLm9yZyAgDQogICAgIExEQVBFWFQgTWFpbGluZyBMaXN0OiBpZXRmLWxkYXBleHRAbmV0c2Nh cGUuY29tIA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQpSZWVkICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgW1BhZ2UgNV0gDQogICAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBT ZXB0ZW1iZXIgOSwgMjAwMCANCiANDA0K --=_441C1E68.D1B0DCC3-- From owner-ietf-ldup@mail.imc.org Thu Jul 13 19:37: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 TAA20256 for ; Thu, 13 Jul 2000 19:37:05 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA10842 for ietf-ldup-bks; Thu, 13 Jul 2000 15:43:09 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA10838 for ; Thu, 13 Jul 2000 15:43:08 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e6DMdrU05705 for ; Thu, 13 Jul 2000 15:39:53 -0700 (PDT) Received: from netscape.com ([192.18.120.126]) by dredd.mcom.com (Netscape Messaging Server 4.15 dredd Jun 22 2000 16:29:39) with ESMTP id FXNR6G00.SE5; Thu, 13 Jul 2000 15:44:40 -0700 Message-ID: <396E4629.58855972@netscape.com> Date: Thu, 13 Jul 2000 15:43:53 -0700 From: olga@netscape.com (Olga Natkovich) X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-lcup@netscape.com CC: ietf-ldup@imc.org Subject: updated version of the LCUP draft Content-Type: multipart/mixed; boundary="------------68E01D812CBB134C6BE4CAA1" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------68E01D812CBB134C6BE4CAA1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Attached is the updated version if the LCUP draft. The draft was submitted to IESG today. Comments are welcome, Olga --------------68E01D812CBB134C6BE4CAA1 Content-Type: text/plain; charset=us-ascii; name="draft-natkovich-ldap-lcup-01.txt" Content-Disposition: inline; filename="draft-natkovich-ldap-lcup-01.txt" Content-Transfer-Encoding: 7bit Internet Draft O. Natkovich, Editor Document: M. Smith Category: Proposed Standard Netscape Communications Corp. M. Armijo Microsoft Corporation July 2000 LDAP Client Update Protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract This document defines the LDAP Client Update Protocol (LCUP). The protocol is intended to allow an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content. 2. Conventions used in this document In the protocol flow definition, the notation C->S and S->C specifies the direction of the data flow from the client to the server and from the server to the client respectively. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [KEYWORDS]. 3. Overview The LCUP protocol is intended to allow LDAP clients to synchronize with the content stored by LDAP servers. The problem areas addressed by the protocol include: - mobile clients that maintain a local read-only copy of the directory data. While off-line, the client uses the local copy of the data. When the client connects to the network, it synchronizes with the current directory content and can be optionally notified about the changes that occur while it is on- line. For example, a mail client can maintain a local copy of the corporate address book that it synchronizes with the master copy whenever the client gets connected to the corporate network. - applications intending to synchronize heterogeneous data stores. A meta directory application, for instance, would periodically retrieve a list of modified entries from the directory, construct the changes and apply them to a foreign data store. - clients that need to take certain actions when a directory entry is modified. For instance, an electronic mail repository may want to perform a "create mailbox" task when a new person entry is added to an LDAP directory and a "delete mailbox" task when a person entry is removed. The problem areas not being considered: - directory server to directory server synchronization. The LDUP replication protocol [LDUPPROT] should be used for this purpose. Several features of the protocol distinguish it from LDUP replication. First, the server does not maintain any state information on behalf of its clients. The clients are responsible for storing the information about how up to date they are with respect to the server's content. Second, no predefined agreements exist between the clients and the servers. The client decides when and from where to retrieve the changes. Finally, the server never pushes the data to the client; the client always initiates the update session during which it pulls the changes from the server. The set of clients that are allowed to synchronize with an LDAP server is determined by the server defined policy. There are, currently, several protocols available for LDAP client server synchronization. While each protocol addresses the needs of a particular group of clients (on-line clients in case of Persistent [PSEARCH] and Triggered [TSEARCH] Search, off-line clients in case of DirSync [DIRSYNC]), none satisfies the requirements of all clients in the target group. For instance, a mobile client that was off-line and wants to become up to date with the server and stay up to date while connected can't be easily supported by any of the above protocols. 4. Protocol Specification This section describes the protocol elements and the protocol flow. Natkovich Proposed Standard - Expires: January 2001 2 4.1 Protocol Elements A client initiates a synchronization session with a server by attaching a clientUpdate control to a search operation. The search specification determines the part of the directory information tree (DIT) the client wishes to synchronize with, the set of attributes it is interested in and the amount of data the client is willing to receive. The clientUpdate control contains the client's synchronization specification. The control has the following format: clientUpdateControlValue ::= SEQUENCE{ cookie OCTET STRING OPTIONAL, keepConnection BOOLEAN DEFAULT FALSE, changesOnly BOOLEAN DEFAULT FALSE } cookie - an opaque cookie that represents the current state of the client's data. keepConnection - if set to TRUE, indicates that the server should keep the connection open after the initial synchronization and should notify the client of modifications to the data. The connection should stay open until the client abandons the search operation, sends the stopClientUpdate extended operation, or closes the connection. The draft will refer to this type of operation as persistent. changesOnly - if set to TRUE, the keepConnection and cookie fields of the control are ignored by the server. In response, the server skips the initial synchronization and only notifies the client about the changes that occur to the data while the client is connected. This feature is useful if the client is not interested in data synchronization but needs to trigger events in response to data modifications. In response to the client's synchronization request, the server returns a set of SearchResultEntries that fits the client's specification. To represent a deleted entry, the server attaches an entryUpdate control to the corresponding SearchResultEntry. The SearchResultEntry corresponding to a deleted entry MUST contain a valid DN and a valid uniqueid but, to reduce the amount of data sent to the client, it SHOULD not contain any other attributes. Furthermore, the server may elect to periodically return to the client the cookie that represents the state of the client's data. This information is useful in case the client crashes or gets disconnected. The cookie is also provided in the entryUpdate control. The control has the following format: entryUpdateControlValue ::= SEQUENCE{ cookie OCTET STRING OPTIONAL, stateUpdate BOOLEAN DEFAULT FALSE, entryDeleted BOOLEAN DEFAULT FALSE Natkovich Proposed Standard - Expires: January 2001 3 } cookie - an opaque cookie that represents the current state of the client's data. stateUpdate - if set to TRUE, indicates that the entry to which the control is attached contains no changes and it is sent only to communicate to the client the new cookie. In this case, the entryDeleted field MUST be ignored and the cookie field WILL contain the updated cookie. This feature allows updating the client's cookie when there is no changes that effect the client's data store. Note that the control MUST be attached to a valid SearchResultEntry, i.e. the entry should contain a valid dn. The server MAY send the entry at the root of the client's tree. entryDeleted - if set to TRUE, indicates that the entry to which the control is attached was deleted. When the server has finished processing the client's request, it attaches a clientUpdateDone control to the SearchResultDone message and sends it to the client. The control has the following format: clientUpdateDoneControlValue ::= SEQUENCE{ reason INTEGER, reasonText LDAPString, cookie OCTET STRING OPTIONAL } reason - reason for terminating the operation. Currently supported values are lcupSuccess (0) the operation was successfully processed lcupResourcesExhausted (1) the server is running out of resource lcupSecurityViolation (2) the client is suspected of malicious actions lcupInvalidCookie (3) invalid cookie was supplied by the client lcupClientDisconnect (4) client requested search termination lcupReloadRequired (5) indicates that client data needs to be reinitialized. This reason is returned if the server does not contain sufficient information to synchronize the client or that the server's data was reloaded since the last synchronization session reasonText - may optionally contain a textual explanation of the error returned in the reason field of the control. cookie - an opaque cookie that represents the current state of the client's data. Natkovich Proposed Standard - Expires: January 2001 4 If the client needs to terminate the synchronization process and it wishes to obtain the cookie that represents the current state of its data, it issues a stopClientUpdateRequest extended operation. The operation carries no data. The server responds with a stopClientUpdateResponse extended operation that also carries no data followed by SearchResultDone with clientUpdateDone control attached. The stopClientUpdateResponse is sent only to satisfy LDAP requirement that every server must issue an extended response for each extended request it receives. If the client is not interested in the state information, it can simply abandon the search operation or disconnect from the server. If server resources become tight, the server can terminate one or more search operations by sending a SearchResultDone message to the client(s). Unless the client sets the changesOnly field to TRUE, the server attaches a clientUpdateDone control that contains the cookie that corresponds to the current state of the client's data and the reload flag set to FALSE. A server set policy is used to decide which searches to terminate. This can also be used as a security mechanism to disconnect clients that are suspected of malicious actions. 4.2 Protocol Flow The client server interaction can proceed in three different ways depending on the client's requirements. If the client's intent is not to synchronize data but to trigger actions in response to directory modifications, the protocol proceeds as follows: C->S Sends a search operation with a clientUpdate control attached. The search specification determines the part of the DIT the client wishes to synchronize with and the set of attributes it is interested in. The changesOnly field of the control should be set to TRUE; other fields are ignored. S->C Sends change notification to the client for each change to the data within the client's search specification. S->C If the server starts to run out of resources or the client is suspected of malicious actions, the server SHOULD terminate the search operation by sending to the client a SearchResultDone message with clientUpdateDone control attached. The control contains the reason field set to lcupResourcesExhausted or lcupSecurityViolation depending on the reason for termination. The server MAY provide more details to the client via the reasonText field of the control. C->S If the client receives lcupResourcesExhausted error from the server, it MUST wait for a while before attempting another synchronization session with the server. It is RECOMMENDED that clients use an exponential backoff strategy. C->S Abandons the search operation or disconnects from the server. S->C Stops sending changes to the client and closes the connection. Natkovich Proposed Standard - Expires: January 2001 5 If the client's intent is to synchronize with the server and then disconnect, the protocol proceeds as follows: C->S Sends a search operation with the clientUpdate control attached. The search specification determines the part of the DIT the client wishes to synchronize with, the set of attributes it is interested in and the amount of data the client is willing to receive. If this is the initial synchronization session, the client does not provide a cookie; otherwise, the cookie field of the control is set to the cookie received from the server at the end of the last synchronization session. (Note that the client can synchronize with different servers during different synchronization sessions.) The keepConnection and changesOnly fields are set to FALSE. S->C If no cookie is specified in the clientUpdate control, the server sends all data that matches the client's search specification followed by the SearchResultDone message with a clientUpdateDone control attached. The control contains the cookie that corresponds to the current state of the client's data and the reason flag set to lcupSuccess. If an invalid cookie is specified the server sends. SearchResultDone message with clientUpdateDone control attached. The reason field of the control is set to lcupInvalidCookie and the reasonText field MAY contain explanation of the error. If a valid cookie is specified and the data that matches the search specification has been reloaded or the server does not contain enough state information to synchronize the client, the server sends an SearchResultDone message with clientUpdateDone control attached. The reason field of the control is set to lcupReloadRequired and the reasonText field MAY contain explanation of the error. If the client is up to date, the server sends a success response to the client. If the cookie is valid and there is data to be sent, the server sends the modified entries to the client. Each SearchResultEntry contains the attributes requested by the client in the search specification regardless of whether they were modified. An entryUpdate control with the entryDeleted field set to TRUE is attached to every deleted entry. The server may also periodically attach an entryUpdate control to the entries sent to the client to indicate the current state of the client's data. In that case, the cookie field of the control represents the state of the client's data including the entry to which the control is attached. Once all the changes are sent, the server sends a SearchResultDone with the clientUpdateDone control attached. The control contains the cookie that represents the current state of the client's data. The reason field of the control is set to lcupSuccess. C->S If the reason field of the control is set lcupReloadRequired, the client clears its data store and repeats the synchronization process by sending the search operation with Natkovich Proposed Standard - Expires: January 2001 6 clientUpdate control that contains no cookie. Otherwise, the client stores the cookie received from the server until the next synchronization session. If the client's intent is to be synchronized with the server and stay notified about data modifications, the protocol proceeds as follows: C->S The client behaves exactly as in the previous case except it sets the keepConnection control field to TRUE. S->C The server behaves exactly as in the previous case except the connection is kept open after the initial set of changes is sent to the client. A SearchResultDone message is not sent to the client; instead, the server keeps sending changes to the client. S->C If the server starts to run out of resources or the client is suspected of malicious actions, the server SHOULD terminate the search operation by sending to the client a SearchResultDone message with clientUpdateDone control attached. The control contains the reason field set to lcupResourcesExhausted or lcupSecurityViolation depending on the reason for termination. The server MAY provide more details to the client via the reasonText field of the control. C->S If the client receives lcupResourcesExhausted error from the server, it MUST wait for a while before attempting another synchronization session with the server. We recommend exponential backoff strategy. C->S Sends a stopClientUpdateRequest extended operation to the server to terminate the synchronization session. S->C Responds with a stopClientUpdateResponse extended operation followed by a SearchResultDone with the clientUpdateDone control attached. The control contains the cookie that represents the current state of the client's data. The reason field of the control is set to lcupReloadRequired. 4.3 Size and Time Limits The search request size or the time limits can only be imposed for non-persistent operations, those that set keepConnection field of the clientUpdateControlValue to FALSE. All other operations MUST set both limits to 0. The server SHOULD ignore the limits set for persistent operations. 4.4 Changes vs. Operations Since the server sends to the client the modified entries rather than the operations, a MODDN operation performed on a subtree will be seen by the client as a sequence of added or modified entries depending on whether the operation moved the entries into the scope of the client's search specification. 4.5 Operations on the Same Connection Natkovich Proposed Standard - Expires: January 2001 7 It is permissible for the client to issue other LDAP operations on the connection used by the protocol. Since each LDAP request/response carries a message id there will be no ambiguity about which PDU belongs to which operation. By sharing the connection among multiple operations, the server will be able to conserve its resources. Clients MUST NOT issue multiple synchronization requests on the same connection. This is because the protocol includes an extended operation and it would be impossible to decide which synchronization session it belongs to. 5.0 Additional Features There are several features present in other protocols or considered useful by clients that are currently not included in the protocol primarily because they are difficult to implementing on the server. These features are briefly discussed in this section. This section is intended to open a discussion on the merits of including and approaches to implementing these features. 5.1. Change Type This feature is present in the Triggered Search [TSEARCH] specification. A flag is attached to each entry returned to the client indicating the reason why this entry is returned. The possible reasons from the draft are "- notChange: the entry existed in the directory and matched the search at the time the operation is being performed, - enteredSet: the entry entered the result set for one of the reasons defined in section 4 above, - leftSet: the entry left the result set for one of the reasons defined in section 4 above, - modified: the entry was part of the result set, was modified or renamed, and still is in the result set." The leftSet feature is particularly useful because it indicates to the client that an entry is no longer within the client's search specification and the client can remove the associated data from its data store. Ironically, this feature is the hardest to implement on the server because the server does not keep track of the client's state and has no easy way of telling which entries moved out of scope between synchronization sessions with the client. A compromise could be reached by only providing this feature for the operations that occur while the client is connected to the server. This is easier to accomplish because the decision about the change type can be made based only on the change without need for any historical information. This, however, would add complexity to the protocol. 5.2. Sending Changes Natkovich Proposed Standard - Expires: January 2001 8 The DirSync protocol [DIRSYNC] sends the client(s) only the modified attributes of the entry rather than the entire entry. While this approach can significantly reduce the amount of data returned to the client, it has several disadvantages. First, unless a separate mechanism (like the change type described above) is used to notify the client about entries moving into the search scope, sending only the changes can result in the client having an incomplete version of the data. Let's consider an example. An attribute of an entry is modified. As a result of the change, the entry enters the scope of the client's search. If only the changes are sent, the client would never see the initial data of the entry. Second, this feature is hard to implement since the server might not contain sufficient information to construct the changes based solely on the server's state and the client's cookie. On the other hand, this feature can be easily implemented by the client assuming that the client has the previous version of the data and can perform value by value comparisons. 5.3. Data Size Limits The DirSync protocol [DIRSYNC] allows clients to control the amount of data sent to them in the search response. The client can specify the number of bytes it is willing to receive by setting the maxReturnLength field of the DirSync control. This feature is intended to allow clients with limited resources to process synchronization data in batches. However, an LDAP search operation already provides the means for the client to specify the size limit by setting the sizeLimit field in the SearchRequest to the maximum number of entries the client is willing to receive. While the granularity is not the same, the assumption is that LCUP protocol will be implemented by regular LDAP clients that can deal with the limitations of the LDAP protocol. 5.4. Data Ordering The DirSync protocol [DIRSYNC] allows a client to specify that parent entries should be sent before the children for add operations and children entries sent before their parents during delete operations. This ordering helps clients to maintain a hierarchical view of the data in their data store. While possibly useful, this feature is relatively hard to implement and is expensive to perform. Comments from M. Armijo: " Although I appreciate the difficulty in implementing this, I believe we need to at least make it an option. If we do not, we will need to define how clients handle issues where changes are received out of order (stub entries, etc.) At the very least we should define that the server must not return a cookie until all parents involved in a series of operations have been returned (does that make sense or should I reword it?). I am concerned that a client can disconnect and be in what it considers to be a 'valid' state while it's own DIT is no longer valid." 6. The Protocol and the LDUP Architecture Natkovich Proposed Standard - Expires: January 2001 9 The LDAP Client Update Protocol is defined within the framework of the LDUP Architecture [LDUPARCH]. The following aspects of the protocol are drawn from the architecture: - The scope of each search operation is restricted to a single replica as defined in the LDUP architecture document [LDUPARCH]. - Each entry returned to the client contains a unique identifier as defined in the LDUP architecture document [LDUPARCH]. The client can use the identifier to unambiguously cross reference objects stored on the server with those in the client's store. - One of the main criteria for selecting the protocol features is that an LDUP compliant server can implement these features efficiently. 7. Client Side Considerations There are several issues that the implementors of a synchronization client need to consider: - The cookie received from the server after a synchronization session can only be used with the same or more restrictive search specification than the search that generated the cookie. The server will reject the search operation with a cookie that does not satisfy this condition. This is because the client can end up with an incomplete data store otherwise. A more restrictive search specification is the one that generates a subset of the data produced by the original search specification. - Because an LCUP client specifies the area of the tree with which it wishes to synchronize through the standard LDAP search specification, the client can be returned nsSuchObject error if the root of the synchronization area was renamed between the synchronization sessions. If this condition occurs, the client can attempt to locate the root by using the root's uniqueid saved in client's local data store. It then can repeat the synchronization request using the new search base. In general, a client can detect that an entry was renamed and apply the changes received to the right entry by using uniqueid rather then DN based addressing. - Each active persistent operation requires that an open TCP connection be maintained between an LDAP client and an LDAP server that might not otherwise be kept open. Therefore, client implementors are encouraged to avoid using persistent operations for non-essential tasks and to close idle LDAP connections as soon as practical. 8. Server Implementation Considerations By design, the protocol does not specify the format of the cookie. This is to allow different implementations the flexibility of storing any information applicable to their environment. A Natkovich Proposed Standard - Expires: January 2001 10 reasonable implementation for an LDUP compliant server would be to use the Replica Update Vector (RUV). For each master, RUV contains the largest CSN seen from this master. In addition, the RUV implemented by the iPlanet Directory Server (not yet in LDUP) contains replica generation - an opaque string that identifies the replica's data store. The replica generation value changes whenever the replica's data is reloaded. Replica generation is intended to signal the replication/synchronization peers that the replica's data was reloaded and that all other replicas need to be reinitialized. RUV satisfies the three most important properties of the cookie: (1) it uniquely identifies the state of client's data, (2) it can be used to synchronize with multiple servers, and (3) it can be used to detect that the server's data was reloaded. In addition, the cookie must contain enough information to allow the server to determine whether the cookie can be safely used with the search specification it is attached to. As discussed earlier in the document, the cookie can only be used with the search specification that is equally or more restrictive than the one for which the cookie was generated. An implementation must make sure that it can correctly update the client's cookie when there is a size limit imposed on the search results by either the client's request or by the server's configuration. If RUV is used as the cookie, entries last modified by a particular master must be sent to the client in the order of their last modified CSN. This ordering guarantees that the RUV can be updated after each entry is sent. An implementation must be able to notify the client about all entries deleted since the last implementation session. An LDUP compliant implementation can achieve this through the use of entry tombstones. The implementation should avoid aggressive tombstone purging since lack of tombstones would cause client's data to be reloaded. We suggest that only the tombstone content be removed during the regular trimming cycle while tombstones themselves are discarded much less frequently. The specification makes no guarantees about how soon a server should send notification of a changed entry to the client when the connection between the client and the server is kept open. This is intentional as any specific maximum delay would be impossible to meet in a distributed directory service implementation. Server implementors are encouraged to minimize the delay before sending notifications to ensure that clients' needs for timeliness of change notification are met. Implementors of servers that support the mechanism described in this document should ensure that their implementation scales well as the number of active persistent operations and the number of changes made in the directory increases. Server implementors are also encouraged to support a large number of client connections if they need to support large numbers of persistent operations. Natkovich Proposed Standard - Expires: January 2001 11 9. Synchronizing Heterogeneous Data Stores Clients synchronizing multiple writeable data stores, like iPlanet Meta Directory, will only work correctly if each piece of information is single mastered (for instance, only by an LDUP compliant directory or only by Oracle). This is because different systems have different notions of time and different update resolution procedures. As a result, a change applied on one system can be discarded by the other, thus preventing the data stores from converging. 10. Security Considerations In some situations, it may be important to prevent general exposure of information about changes that occur in an LDAP server. Therefore, servers that implement the mechanism described in this document SHOULD provide a means to enforce access control on the entries returned and MAY also provide specific access control mechanisms to control the use of the controls and extended operations defined in this document. As with normal LDAP search requests, a malicious client can initiate a large number of persistent search requests in an attempt to consume all available server resources and deny service to legitimate clients. The protocol provides the means to stop malicious clients by disconnecting them from the server. The servers that implement the mechanism SHOULD provide the means to detect the malicious clients. In addition, the servers SHOULD provide the means to limit the number of resources that can be consumed by a single client. Access control on the data can be modified in such a way that the data is no longer visible to the client. The specification does not specify how the server should handle this condition. Moreover, data consistency is not guaranteed if access control is changed from a more restrictive to a less restrictive one. This is because access control can be considered as an additional filter on the search specification and the protocol does not support going from a more to a less restrictive search specification. See Client Side Considerations Section for more detailed explanation of the problem. 11. References [KEYWORDS] S. Bradner, "Keywords for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [PSEARCH] M. Smith "A Simple LDAP Change Notification Mechanism", INTERNET-DRAFT , August 1998. [TSEARCH] M.Whal "LDAPv3 Triggered Search Control", INTERNET-DRAFT , August 1998. Natkovich Proposed Standard - Expires: January 2001 12 [DIRSYNC] M. Armijo "Microsoft LDAP Control for Directory Synchronization", INTERNET-DRAFT , August 1999. [LDUPARCH] J. Merrells, E. Reed, U. Srinivasan, "LDAP Replication Architecture", INTERNET-DRAFT , October 1999. [LDUPPROT] E. Stokes, G. Good "The LDUP Replication Update Protocol", INTERNET-DRAFT , October 1999. 12. Author's Addresses Olga Natkovich Netscape Communications Corp. 901 San Antonio Rd. Palo Alto, CA 94303-4900 Mail Stop SCA17 - 201 Phone: +1 408 276-4357 Email: olga@netscape.com Mark Smith Netscape Communications Corp. 901 San Antonio Rd. Palo Alto, CA 94303-4900 Mail Stop SCA17 - 201 Phone: +1 650 937-3477 Email: mcs@netscape.com Michael P. Armijo Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 Phone: +1 425 882-8080 Email: micharm@Exchange.Microsoft.com 13. Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than Natkovich Proposed Standard - Expires: January 2001 13 English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 14. Appendix A - Summary of Changes Since the last version of the draft, the following changes have been made: Replaced the reload flag in the clientUpdateDone control with a pair of reason and reasonText fields. The fields are used to communicate LCUP specific error conditions to the client. Several values for the reason field are defined in the draft. Added a scalability note to the Implementation Consideration section. Added a note that multiple synchronization requests are not allowed on the same connection. Added Michael Armijo, the author of the DirSync draft, as the co- author. Added a few clarifications and corrected a few typos. Natkovich Proposed Standard - Expires: January 2001 14 --------------68E01D812CBB134C6BE4CAA1-- From owner-ietf-ldup@mail.imc.org Fri Jul 14 02:53: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 CAA11759 for ; Fri, 14 Jul 2000 02:53:19 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA04681 for ietf-ldup-bks; Thu, 13 Jul 2000 23:22:53 -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 XAA04672 for ; Thu, 13 Jul 2000 23:22:50 -0700 (PDT) Received: (qmail 29521 invoked from network); 14 Jul 2000 06:24:52 -0000 Received: from softdnserror (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 14 Jul 2000 06:24:52 -0000 Reply-To: From: "Steven Legg" To: "'Haripriya S'" Cc: , Subject: RE: various comments (was Re: What's going on? - StatusofRequirements...) Date: Fri, 14 Jul 2000 16:27:35 +1000 Message-ID: <001501bfed5c$9a4fd300$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: 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 Hi, Comments in-line ... > -----Original Message----- > From: Haripriya S [mailto:SHARIPRIYA@novell.com] > Sent: Thursday, 13 July 2000 16:07 > To: steven.legg@adacel.com.au > Cc: ietf-ldup@imc.org; alison.payne@team.telstra.com > Subject: RE: various comments (was Re: What's going on? - > StatusofRequirements...) > > > Steven, > > The remaining (N - M) replicas would not be allowed > to perform any > strong consistency updates because they wouldn't be able to obtain > a quorum of M replicas: M > N/2 implies (N-M) < M . > However, loose consistency updates would be allowed at the > (N-M) replicas, > which might invalidate strong consistency updates performed by the M > replicas. I would regard this as a case of one application > stomping over > another application because it is unaware/uncaring of the second > application's semantics and constraints. This sort of thing > is a problem > even in the single master case, though admittedly the > multi-master case > raises some situations that wouldn't occur on a single master. > > - As transaction is an add-on for a directory, it should work > even in cases a client is not aware of strong or weak > consistency. One model that can be followed is: > > - reads are weakly consistent unless the client knows and > asks for strong consistency. We obviously have a choice for the default consistency behaviour. Since current applications operate in an environment without multiple operation transactions, i.e. weak consistency, it seems reasonable to assume weak consistency for reads. It would still be prudent for server implementations to provide a means for enforcing strong consistency on a per user, per attribute type, per application, per whatever basis, for the sake of broken applications that don't realize they are operating in a weak consistency environment. I'd be happy to leave the details up to vendors to decide for themselves. In X.500 terms, the dontUseCopy service control would also be a good indicator of whether strong consistency is required for a read. > - writes even if not specified by client should result in > strong consistency. Atomicity is expected for updates so defaulting to strong consistency for updates is reasonable. > > - One way in which this can be done is i. use a normal read > in case of no or weak consistency reads. ii. use the quorum > based aproach you mentioned if client requests strong > consistency read. iii. use a timestamps based approach for > atomicity of writes. > > - if a transaction makes n modifies to the directory (add, > modify or del) all these n modifies should have consecutive > or same CSNs. Agreed. > The CSNs will have the time at which the > transaction ended.Thus if server 1 makes changes to n items > in set N by a transaction beginning at time t1 and ending at > t2, and server 2 makes change to item n1 belonging to set N > at time t3, then if t2 > t3, then the effect of the change at > t2 will be overridden by the transaction at server 1. If t2 > is less that t3, then it is as if the lone change to n1 came > after the transaction completed, so the result is as > expected. Not really. The transaction at server 2 used the state of n1 as it was at time t1. If the transaction at server 2 is deemed to have occurred "after" the transaction at server 1 then it is only correct from a strong consistency point of view if it used the state of n1 as it was at time t2 on server 1. I'm assuming that the transactions are doing some reading. Purely write-only transactions are rare. > This approach could be used even if some of the > servers are down or inaccessible at the moment. > > My original thought was to allow applications to > request whether or not > their operations should be executed with strong consistency, > but I think > it would also be useful if applications and/or administrators > could register > what entries or attributes they want the server(s) to protect > by insisting > that ALL operations against those directory items, even those > explicitly > requesting loose consistency, are performed with strong consistency. > In this way an application could block loose consistency > updates in any > currently inaccessable (N-M) subset of the replicas. > > - Specifying a set of entries or attributes as forming a > transaction group may be difficult. Imagine the case where > the transaction's need is to preserve consistency between a > user and its group object at all times. if the user has a > groupmembership attribute, and the group has a member > attribute, these have to be changed together for the change > to be consistent. But it is difficult to specify this > relationship in terms of entry names because it has to be > said like "if entry e1 is the value of a member attribute of > a group g1, and e1 is a user, then the groupmembership > attribute of e1 should be updated along with the member > attribute of g1", which is difficult. I've been thinking along the lines of using a set of search operations to specify the directory data to protect. The basic idea being that the server blocks any update that would cause the result of those searches to change. How that gets implemented internally is a separate matter. If I was interested in protecting two particular entries e1 and g1 then I could use two search specifications. The first would have a base object of g1 and a filter of (member=e1). The second would have a base object of e1 and a filter of (groupmembership=g1). More likely you want to protect the relationship for all members of g1's group. Someone (Bruce maybe?) put together an ID on a matching rule that chased down DN links. I forget the details, but maybe that would enable a precise search specification of the relationship between g1's member list and the member's groupmembership attribute values. In any case, a more general search specification will do, at the cost of potentially lower update concurrency. A subtree search with filter on member present or groupmembership present and returning only member and groupmembership will do the trick. That effectively locks out any change to those two attribute types. Regards, Steven > > Regards, > Steven > > - Thanks and Regards, > - Haripriya > > From owner-ietf-ldup@mail.imc.org Fri Jul 14 04:52: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 EAA09076 for ; Fri, 14 Jul 2000 04:52:34 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id BAA09105 for ietf-ldup-bks; Fri, 14 Jul 2000 01:22:03 -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 BAA09101 for ; Fri, 14 Jul 2000 01:22:01 -0700 (PDT) Received: (qmail 23089 invoked from network); 14 Jul 2000 08:19:22 -0000 Received: from cpe-144-132-68-23.vic.bigpond.net.au (HELO w98sysrec) (144.132.68.23) by relay1.pair.com with SMTP; 14 Jul 2000 08:19:22 -0000 X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: , , , Cc: Subject: RE: LDAP subentry alignment with X.500 subentry Date: Fri, 14 Jul 2000 18:23:16 +1000 Message-ID: <001701bfed6c$c3a0a800$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: <396DE97A.CE8EA105@france.sun.com> 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 [Albert] LDAP standards must not unnecessarily limit implementation choices. Filter specifications on object classes work with either model, since every entry knows its object classes and can easily calculate an arbitrary filter on them quickly when determining visibility during searches. [Robert] Albert, doesn't an entry know the other attributes that it contains as well and so could evaluate an arbitrary filter ? [Albert] Sorry, I should have said "the (structural) object class of an entry is fixed and therefore the set of applicable subentries does not need to be recalculated on every search". With general filters such a calculation would be needed on every search, for every subentry that has a parent within the base of the search applied to every entry within the scope of the search. This is multiplying the cost of a search by the number of potentially applicable subentries (not just the number of actually applicable subentries). [Albert] General filters really only work with a traversal based implementation and are basically just an attempt to substitute regexp evaluation on path names familiar to centralized web administrators for a serious admin model that can actually be delegated. The apparant additional flexibility is illusory since it [Robert] Don't catch this--a general filter refers to values of attributes within the entry, not the dn of the entry. As I pointed out above, users of our directory make use of this "illusion" all the time. [Albert] Whoops, I was arguing against the use of regexp path based ACIs as used in UMich derived implementations. As you say, this is irrelevant to your suggestion for (entry) attribute based filters (assuming that a "generic" filter does not treat dn as an attribute). That's what comes from responding from "off the top of my head". My other argument above still stands. [Robert] For the second question, "what is so great about using subentries for acis?", I think Alan's response was clearest. For my own benefit I've tried to distill (quite a lot!) the main points to the points listed below. I don't dispute them, but I would say that the "aci attribute" approach also allows seperation (it's an operational attribute) and delegation (you've got rights to that attribute or not)...though not to the same extent as the subentry approach. [...] [Albert] I've just realised this topic is across ldap-ext as well as ldup. I'm not subscribed to ldap-ext and don't have time to be at the moment, so I'm not plannning to comment further. For the record though, I believe that: 1. The LDAP subentry proposal is adequate for current LDUP needs. It may be more than adequate because allowing nested families of subentries may not be strictly necessary since the replication agreements children of subentries contain the dn of the replica they apply to. It also appears to still rely on special case semantics for the meaning of a child subentry of replica entry. Changing the structure rules is not a minor variant and if done I would prefer to see it done more fully as in: Chadwick, D.W., "Compound (Families of) Entries", Internet-Draft, draft-chadwick-families-00.txt, (expired) 5 December 1999. Ed's argument for a subset of X.500 rather than a superset is convincing. Its application to a final call for endorsement of a superset by varying structure rules is not convincing. But somebody has to either object now or hold their peace. I'm sticking to my objection to the replication requirements but holding my peace on subentries. If you want a different superset you need to object now. 2. There will be future LDUP needs for subtree specifications related to management of the creation of new replication areas. However this is beyond the current scope. 3. LDAP-EXT ACI ought to have requirements for Directory Access Control Domains, which need subentry specifications with object class filters. Not having them severely complicates simple things like delegating management of printers to printer operators across organizational unit boundaries as well as across both distribution and replication boundaries. I pointed this out at the Melbourne IETF but I don't have time to pursue it. 4. Issues like LDAP subentries are quite naturally across both WGs. In my view there is a vital need for coordination of issues like transactions and ACI across both groups. The current replication proposals from LDUP will impede if not prevent any deployment of transactions. This however may not matter as they will also not meet any reasonable requirements for ACI and therefore are unworkable anyway. This is independent of whether ACI should include DACDs. Any workable ACI MUST be replicated atomically and the current LDUP proposals fail to achieve that, so discussion of attempts to standardize subentries for ACI as well as for replication within LDUP are rather pointless. 5. LDAP-EXT has, and should therefore state, a clear requirement for atomic replication of ACI attributes so that LDUP could stop trying to avoid the issue. Despite the overlap of authorship of the two requirements documents there is no indication of any understanding of the impact of non-atomicity on ACI. Anyone in LDAP-EXT interested in this should look at my objection and alternative to the current LDUP proposals: http://www.ietf.org/internet-drafts/draft-langer-ldup-mdcr-00.txt Please send or CC any comments to LDUP as I won't see them in LDAP-EXT. Seeya, Albert From owner-ietf-ldup@mail.imc.org Fri Jul 14 12:47: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 MAA27997 for ; Fri, 14 Jul 2000 12:47:40 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA27873 for ietf-ldup-bks; Fri, 14 Jul 2000 09:11:24 -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 JAA27868 for ; Fri, 14 Jul 2000 09:11:22 -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 QAA16468; Fri, 14 Jul 2000 16:12:43 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <4.3.2.7.0.20000714091014.00b4ad10@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 14 Jul 2000 09:12:39 -0700 To: "Ed Reed" From: "Kurt D. Zeilenga" Subject: Re: LDAP subentry schema request for last call Cc: , , , Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_221505327==_.ALT" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=====================_221505327==_.ALT Content-Type: text/plain; charset="us-ascii" Even if you dismiss my suggestion to align with X.500 subentry, the LDAPentry I-D still needs work and, IMO, not ready for last call. 1) Given that LDAPsubentry is NOT X.500 subentry, the I-D must explicit in defining it's semantics. As defined, it is not clear which X.500 subentry semantics apply or which ones don't. The reader cannot assume X.500 semantics apply unless the document explicitly states they do apply. It is not clear of how LDAPsubentries are scoped. It is not clear whether or not X.500 placement (at administrative points) restrictions apply to LDAPsubentries (the I-D uses a MAY). It is not clear what container restrictions, if any, are applicable. Can they be contained by the root DSE? other non-entry DSEs? Can a LDAPsubentry contain a non-LDAPsubentry? Are there restrictions upon sub-classing with other 'special' object classes (such as 'alias' and 'referral')? 2) I believe the specification of (objectclass=LDAPsubentry) filter component is inadequate and that a control should be used instead. If a filter component is used, the specification should state the semantics of filter component when it is part of an Undefined or FALSE filter component or not evaluated due to filter evaluation short circuiting. I think further overloading the search filter is a really bad idea. But beyond that, a search filter component is limited to only search operation operations and the visibility control may be needed with other operations (such as modify, see below). I proposed use of a control instead of a filter component. We have operational experience with similar controls (ManageDSAit) working well and experience with overloaded search filter components not working well (previous matched values I-D). I believe a control would facilitate implementation of LDAP-DAP gateways. But beyond this, a control is usable with any operation. I would suspect that visibility control would be needed with other operations such as modify and/or extended operations. In particular, note that in X.500 collective attributes (which an LDAP server may support) are not normally modifiable unless the subentries control is present. X.511, 11.3.2: The [modify] operation may be used to modify collective attributes only if the service control subentries is TRUE and if the object is the subentry actually holding the collective attribute(s) to be modified. (careful readers might note this sentence conflicts conflicts with 7.5(f), but that's another matter) At 09:55 AM 7/13/00 -0600, Ed Reed wrote: >With regard to making LDAPsubentry fully compatible with the X.500 subentry, it's been pointed out that people wanting to use the X.500 subentry should feel free to do so - it's incorporated by reference in the base LDAP definitions. Yes. So there must be an overwhelming reason why a replacement is needed. I don't think the complexity of the subtree specifier is an overwhelming reason. It would be similar just to grant vendors some freedom to implement portions of the specifier (as previously suggested by another member). >The purpose of this proposal is to define a subset of the X.500 functionality (and extend the structural rules by allowing nesting of LDAPsubentries) for use by certain LDAP applications which find the subset functionality a useful simplification. I believe the removal of the subtree specifier will require the introduction of replacement scoping mechanisms/placement restrictions with complexity similar to that of the subtree specifier. And if you allow LDAPsubentries to be placed anywhere in the directory, locating the applicable LDAPsubentry becomes quite complex (for both clients and servers). On an editorial note, Section 2: ... RFC 2119 [RFC2119]. The sections below reiterate these definitions and include some additional ones. The need for alternative and/or additional ones should be eliminated. This is an IESG nit: http://www.ietf.org/ID-nits.html --=====================_221505327==_.ALT Content-Type: text/html; charset="us-ascii" Even if you dismiss my suggestion to align with X.500 subentry,
the LDAPentry I-D still needs work and, IMO, not ready for last call.

1) Given that LDAPsubentry is NOT X.500 subentry, the I-D must
explicit in defining it's semantics.  As defined, it is not
clear which X.500 subentry semantics apply or which ones don't.
The reader cannot assume X.500 semantics apply unless the
document explicitly states they do apply.

It is not clear of how LDAPsubentries are scoped.  It is not
clear whether or not X.500 placement (at administrative points)
restrictions apply to LDAPsubentries (the I-D uses a MAY).

It is not clear what container restrictions, if any, are
applicable. Can they be contained by the root DSE?
other non-entry DSEs?  Can a LDAPsubentry contain a
non-LDAPsubentry?  Are there restrictions upon sub-classing
with other 'special' object classes (such as 'alias' and 'referral')?

2) I believe the specification of (objectclass=LDAPsubentry)
filter component is inadequate and that a control should be used
instead.  If a filter component is used, the specification
should state the semantics of filter component when it is
part of an Undefined or FALSE filter component or not
evaluated due to filter evaluation short circuiting.  I think
further overloading the search filter is a really bad idea.
But beyond that, a search filter component is limited to only
search operation operations and the visibility control may be
needed with other operations (such as modify, see below).

I proposed use of a control instead of a filter component.
We have operational experience with similar controls
(ManageDSAit) working well and experience with overloaded
search filter components not working well (previous matched
values I-D).  I believe a control would facilitate
implementation of LDAP-DAP gateways.

But beyond this, a control is usable with any operation.  I
would suspect that visibility control would be needed with
other operations such as modify and/or extended operations.
In particular, note that in X.500 collective attributes
(which an LDAP server may support) are not normally modifiable
unless the subentries control is present.  X.511, 11.3.2:

  The [modify] operation may be used to modify collective attributes only if the
 service control subentries is TRUE and if the object is the subentry actually
  holding the collective attribute(s) to be modified.

(careful readers might note this sentence conflicts conflicts
with 7.5(f), but that's another matter)

At 09:55 AM 7/13/00 -0600, Ed Reed wrote:
With regard to making LDAPsubentry fully compatible with the X.500 subentry, it's been pointed out that people wanting to use the X.500 subentry should feel free to do so - it's incorporated by reference in the base LDAP definitions.

Yes.  So there must be an overwhelming reason why a replacement is
needed.  I don't think the complexity of the subtree specifier is
an overwhelming reason.  It would be similar just to grant vendors
some freedom to implement portions of the specifier (as previously
suggested by another member).

The purpose of this proposal is to define a subset of the X.500 functionality (and extend the structural rules by allowing nesting of LDAPsubentries) for use by certain LDAP applications which find the subset functionality a useful simplification.

I believe the removal of the subtree specifier will require the
introduction of replacement scoping mechanisms/placement restrictions
with complexity similar to that of the subtree specifier.  And if
you allow LDAPsubentries to be placed anywhere in the directory,
locating the applicable LDAPsubentry becomes quite complex (for
both clients and servers).


On an editorial note, Section 2:
  ... RFC 2119 [RFC2119]. The sections below reiterate these definitions
  and include some additional ones.

The need for alternative and/or additional ones should be eliminated.
This is an IESG nit: http://www.ietf.org/ID-nits.html
--=====================_221505327==_.ALT-- From owner-ietf-ldup@mail.imc.org Fri Jul 14 15:33:59 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 PAA22948 for ; Fri, 14 Jul 2000 15:33:58 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA08157 for ietf-ldup-bks; Fri, 14 Jul 2000 11:59:55 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA08151 for ; Fri, 14 Jul 2000 11:59:53 -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 e6EIueU26920 for ; Fri, 14 Jul 2000 11:56:40 -0700 (PDT) Received: from netscape.com ([205.217.240.37]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FXPBI201.P7J; Fri, 14 Jul 2000 12:01:14 -0700 Message-ID: <396F6398.301932EB@netscape.com> Date: Fri, 14 Jul 2000 12:01:44 -0700 From: ggood@netscape.com (Gordon Good) X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: internet-drafts@ietf.org CC: ietf-ldup@imc.org Subject: Please publish draft-ietf-ldup-protocol-02.txt Content-Type: multipart/mixed; boundary="------------4A370400D52D7F80062B35F1" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------4A370400D52D7F80062B35F1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Please publish the attached draft. It is an update to draft-ietf-ldup-protocol-01.txt. --------------4A370400D52D7F80062B35F1 Content-Type: text/plain; charset=us-ascii; name="draft-ietf-ldup-protocol-02.txt" Content-Disposition: inline; filename="draft-ietf-ldup-protocol-02.txt" Content-Transfer-Encoding: 7bit LDUP Replication Update Protocol Internet-Draft Intended Category: Standards Track Expires: February 15, 2001 Ellen Stokes IBM Corporation Gordon Good America Online The LDUP Replication Update Protocol Filename: draft-ietf-ldup-protocol-02.txt Table of Contents 1. Status of this Memo.............................................2 2. Abstract........................................................2 3. Overview of Protocol............................................2 4. High-level Description of Protocol Flow.........................3 4.1 Supplier-initiated replication protocol.........................3 4.2. Consumer-initiated replication protocol......................4 5. Replication protocol element definitions........................5 5.1 StartReplicationRequest Extended Operation......................5 5.2 StartReplicationResponse Extended Operation.....................6 5.3 ReplicationUpdate Extended Operation............................7 5.3.1 UniqueIdentifier.............................................8 5.3.2 ReplicationPrimitive.........................................8 5.3.2.1 AddEntryPrimitive.........................................8 5.3.2.2 MoveEntryPrimitive........................................9 5.3.2.3 RenameEntryPrimitive......................................9 5.3.2.4 RemoveEntryPrimitive......................................9 5.3.2.5 AddAttributeValuePrimitive................................10 5.3.2.6 RemoveAttributeValuePrimitive.............................10 5.3.2.7 RemoveAttributePrimitive..................................10 5.4 EndReplicationRequest Extended Operation........................11 5.5 EndReplicationResponse Extended Operation.......................12 6. Semantics of Full and Incremental Update protocols..............13 7. Summary of response codes.......................................13 8. Implications for log-based and state-based servers..............14 9. Replication of access control and schema information............14 10. Security Considerations.........................................14 11. Glossary of Terms...............................................14 12. Acknowledgments.................................................14 13. References......................................................14 14. Author's Addresses..............................................15 Stokes and Good [Page 1] Internet-Draft LDUP Workgroup 15 July 2000 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. This Internet Draft expires February 15, 2001. 2. Abstract The protocol described in this document is designed to allow one LDAP server to replicate its directory content to another LDAP server. The protocol is designed to be used in a replication configuration where multiple updatable servers are present. Provisions are made in the protocol to carry information that allows the server receiving updates to apply a total ordering to all updates in the replicated system. This total ordering allows all replicas to correctly resolve conflicts that arise when LDAP clients submit changes to different servers that later replicate to one another. All protocol elements described here are LDAP Version 3 extended operations. LDAP Version 3 is described in RFC 2251 [LDAPv3]. Certain terms used in this document are defined in the document "LDAP Replication Architecture" [ARCHITECTURE]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC 2119 [KEYWORDS]. 3. Overview of Protocol The LDAP Replication Architecture [ARCHITECTURE] describes the overall approach used in ensuring consistency of multiple updatable replicas of directory content. The protocol described in this document implements the approach desribed in that document. Stokes and Good [Page 2] Internet-Draft LDUP Workgroup 15 July 2000 LDAP Version 3 extended operations are used to carry replicated content from one server to another. The extended operations defined in this document are used to initiate and end a replication session, and to exchange updates. These updates carry with them information that allows the receiving server to apply a total ordering to all of the updates in a replicated system. All servers that receive replication updates apply a consistent set of update resolution policies, described in [URP]. Consistent application of the update resolution policies ensures that all replicas eventually converge and contain the same directory data. The protocol is intended to meet the requirements set forth in [REQ]. 4. High-level Description of Protocol Flow The following section provides a high-level overview of the replication protocol. Throughout this section, the supplier server is indicated by the letter "S" and the consumer server by the letter "C". The construct "S -> C" indicates that the supplier is sending an LDAPv3 extended operation to the consumer, and "C -> S" indicates that the consumer is sending an LDAPv3 extended operation to the supplier. 4.1 Supplier-initiated replication protocol S -> C: LDAP bind operation (identity and credentials used are implementation-defined) C -> S: Bind response S -> C: StartReplicationRequest LDAPv3 extended operation. The parameters are: 1) Root of replicated area (unambiguously identifies the replicated area) 2) Supplier's replicaID 3) OID of replication protocol to be used (this document defines IETF-LDUP incremental and IETF-LDUP total update protocols) 4) The protocol initiation type - Supplier-Initiated in this case. C -> S: StartReplicationResponse LDAPv3 extended operation. The parameters are: 1) A response code (see section 7) 2) An optional update vector that is included if and only if the response code is REPL_SUCCESS. Stokes and Good [Page 3] Internet-Draft LDUP Workgroup 15 July 2000 S -> C: The supplier may send zero or more ReplicationUpdate LDAPv3 extended operations. The parameters are: 1) The UUID of the entry being updated 2) One or more Replication Primitives (The supplier may send as many of these as required to bring the consumer up to date) C -> S: At any time, the consumer may send an unsolicited ReplicationUpdateResponse LDAPv3 extended operation. The parameters are: 1) An optional update vector. If sent, this indicates that the consumer has committed all updates whose CSNs are covered by the transmitted update vector [see glossary for a definition of "covered by"]. 2) An optional AbortUpdate boolean flag. If a supplier receives a ReplicationUpdateResponse from a consumer with the AbortUpdate flag set to true, the supplier server MUST immediately cease sending updates and terminate its connection to the consumer. S -> C: After all required updates have been sent to the consumer, the supplier sends an EndReplicationRequest LDAPv3 extended operation C -> S: The consumer responds by sending an EndReplicationRequest LDAPv3 extended operation, and then closes the connection. 4.2. Consumer-initiated replication protocol C -> S: LDAP bind operation (identity and credentials used are implementation-defined) S -> C: Bind response C -> S: StartReplicationRequest LDAPv3 extended operation. The parameters are: 1) Root of replicated area (unambiguously identifies the replicated area) 2) Consumer's replicaID 3) OID of replication protocol to be used (this document defines IETF-LDUP incremental and IETF-LDUP total update protocols) 4) The protocol initiation type - Consumer-Initiated in this case S -> C: StartReplicationResponse LDAPv3 extended operation. The Stokes and Good [Page 4] Internet-Draft LDUP Workgroup 15 July 2000 parameters are: 1) A response code (see section 7) S -> C: The supplier server disconnects from the consumer server, and then connects to the consumer, beginning a Supplier- Initiated protocol session (see section 4.1). 5. Replication protocol element definitions 5.1 StartReplicationRequest Extended Operation The StartReplicationRequest extended operation is sent by a replication initiator to a server to indicate that a replication session should commence. For supplier-initiated replication, the supplier sends this extended operation to the replication consumer to indicate that a replication session should commence. For consumer-initiated replication, the consumer sends this extended operation to the replication supplier to indicate that the supplier should initiate a replication session to the consumer as soon as possible. The StartReplicationRequest extended operation is defined as follows: StartReplicationRequest ::= [APPLICATION 23] SEQUENCE { requestName [0] LDAPOID, requestValue [1] OCTET STRING } The requestName of the StartReplicationRequest must be [OID to be assigned]. The requestValue of the StartReplicationRequest must be set to the BER-encoding of the following: requestValue ::= SEQUENCE { replicaRoot LDAPDN, replicaID LDAPString, replicationProtocolOID LDAPOID, replicationInitiator ENUMERATED { supplier (0), consumer (1) } } The parameters in the requestValue of the StartReplicationRequest are: Stokes and Good [Page 5] Internet-Draft LDUP Workgroup 15 July 2000 - replicaRoot: the distinguished name of the entry at the top of the replicated area, and uniquely identifies the unit of replication. - replicaID: the replica identifier of the replication initiator. Each replica of a given replicated area is identified by a unique identifier, described in [ARCHITECTURE]. - replicationProtocolOID: the type of replication protocol that should be used to transfer the updates. This document describes two protocols; ietf-ldup-full-update and ietf-ldup-incremental-update. See section 7 for information on the semantic behavior of these update protocols. Implementations MUST support the two update protocols defined in this document. - replicationInitiator: used to differentiate between a supplier- initiated session and a consumer-initiated session. If the replicationInitiator contains the enumerated value , then the initiator is the supplier, and the receiver of this operation should prepare to receive a set of replication updates (or should reject the operation is replication updates are not permitted for some reasonm, perhaps due to access control restrictions). If the replicationInitiator contains the enumerated value , then the receiver should prepare to establish a supplier-initiated replication session with the consumer as soon as possible, updating the replicated are given by replicaRoot and using the update protocol given by replicationProtocolOID. 5.2 StartReplicationResponse Extended Operation The StartReplicationResponse extended operation is sent in response to a StartReplicationRequest extended operation. For a supplier-initiated session, the StartReplicationResponse extended operation indicates that the consumer is or is not prepared to accept a set of updates. If the consumer is prepared to accept updates, it sends a StartReplicationResponse extended operation containing a success code and the consumer's replica update vector. If the consumer is unwilling or unable to accept updates, it sends a StartReplicationResponse extended operation containing an error code. For a consumer-initiated session, the StartReplicationResponse extended operation indicates that the supplier is or is not prepared to send a set of updates to the consumer. If the supplier is prepared to send updates to the consumer, it sends a StartReplicationResponse extended operation with a success code. If the supplier is unwilling or unable to send updates to the consumer, it sends a StartReplicationResponse extended operation containing an error code. In both cases, the supplier Stokes and Good [Page 6] Internet-Draft LDUP Workgroup 15 July 2000 disconnects from the consumer. If the supplier sent a success code to the consumer, it opens a connection to the consumer as soon as possible and initiates a supplier-initiated replication session. The StartReplicationResponse extended operation is defined as follows: StartReplicationResponse ::= [APPLICATION 23] SEQUENCE { requestName [0] LDAPOID, requestValue [1] OCTET STRING } The requestName of the StartReplicationResponse must be [OID to be assigned]. The requestValue of the StartReplicationResponse must be set to the BER-encoding of the following: requestValue ::= SEQUENCE { responseCode LDUPResponseCode, replicaUpdateVector Attribute, } LDUPResponseCodes are defined in section 8. The replicaUpdateVector contains a replica update vector, as defined in [INFOMOD]. The update vector is encoded as a normal LDAP attribute, defined in [LDAPv3]. 5.3 ReplicationUpdate Extended Operation The ReplicationUpdate extended operation carries a set of replication primitives that represent the desired final state of a single entry. The ReplicationUpdate extended operation is defined as follows: An LDAPv3 Extended Request is defined in [LDAPv3] as follows: ReplicationUpdate ::= [APPLICATION 23] SEQUENCE { requestName [0] LDAPOID, requestValue [1] OCTET STRING } The requestName of the ReplicationUpdate must be [OID to be assigned]. The requestValue of the ReplicationUpdate must be set to the BER- encoding of the following: Stokes and Good [Page 7] Internet-Draft LDUP Workgroup 15 July 2000 requestValue ::= SEQUENCE { uniqueID UniqueIdentifier, updates SET OF ReplicationPrimitive } 5.3.1 UniqueIdentifier The Distinguished Name of an entry may be changed (by renaming the entry), or the entry may not have a distinguished name (if it was deleted). The Unique Identifier provides an immutable name, independent of the current name or deletion status, for an entry. All replicated operations address entries by their Unique Identifiers. UniqueIdentifier ::= LDAPString 5.3.2 ReplicationPrimitive A ReplicationPrimitive carries a single assertion about the the final state of an entry, attribute, or attribute value. There are seven types of primitives. ReplicationPrimitive ::= CHOICE { addEntryPrimitive AddEntryPrimitive, moveEntryPrimitive MoveEntryPrimitive, renameEntryPrimitive RenameEntryPrimitive, removeEntryPrimitive RemoveEntryPrimitive, addAttributeValuePrimitive AddAttributeValuePrimitive, removeAttributeValuePrimitive RemoveAttributeValuePrimitive, removeAttributePrimitive RemoveAttributePrimitive } Each primitive applies to the entry referred to by the uniqueIdentifier in the enclosing ReplicationUpdate extended operation. Each primitive carries an lLDAPChangeSequenceNumber that is used by the consumer server to correctly resolve update conflicts. [URP] describes the update reconciliation procedures. 5.3.2.1 AddEntryPrimitive The AddEntryPrimitive is used to add a new entry. AddEntryPrimitive ::= [APPLICATION 0] SEQUENCE { csn lDAPChangeSequenceNumber, superior UniqueIdentifier, rdn RelativeLDAPDN Stokes and Good [Page 8] Internet-Draft LDUP Workgroup 15 July 2000 } Parameters of the AddEntryPrimitive are: - csn: The change sequence number of the primitive. - superior: The unique identifier of the superior (parent) entry. - rdn: The relative distinguished name of the new entry. 5.3.2.2 MoveEntryPrimitive The MoveEntryPrimitive is used to move an entry to a new location in the DIT. MoveEntryPrimitive ::= [APPLICATION 1] SEQUENCE { csn lDAPChangeSequenceNumber, superior UniqueIdentifier } Parameters of the MoveEntryPrimitive are: - csn: The change sequence number of the primitive. - superior: The unique identifier of the new superior (parent) entry. 5.3.2.3 RenameEntryPrimitive The RenameEntryPrimitive is used to change the RDN of an entry. RenameEntryPrimitive ::= [APPLICATION 2] SEQUENCE { csn lDAPChangeSequenceNumber, rdn RelativeLDAPDN } Parameters of the RenameEntryPrimitive are: - csn: The change sequence number of the primitive. - rdn: The new relative distinguished name of the entry. 5.3.2.4 RemoveEntryPrimitive The RemoveEntryPrimitive is used to delete an entry from the DIT. RemoveEntryPrimitive ::= [APPLICATION 3] SEQUENCE { csn lDAPChangeSequenceNumber Stokes and Good [Page 9] Internet-Draft LDUP Workgroup 15 July 2000 } Parameters of the RemoveEntryPrimitive are: - csn: The change sequence number of the primitive. 5.3.2.5 AddAttributeValuePrimitive The AddAttributeValuePrimitive is use to add a new attribute value to an entry. AddAttributeValuePrimitive ::= [APPLICATION 4] SEQUENCE { csn lDAPChangeSequenceNumber, type AttributeDescription, value AttributeValue } Parameters of the AddAttributeValuePrimitive are: - csn: The change sequence number of the primitive. - type: The type of the attribute being added. - value: The value being added. Multiple values are not permitted. 5.3.2.6 RemoveAttributeValuePrimitive The RemoveAttributeValuePrimitive is used to remove a particular attribute value from an entry. RemoveAttributeValuePrimitive ::= [APPLICATION 5] SEQUENCE { csn lDAPChangeSequenceNumber, type AttributeDescription, value AttributeValue } Parameters of the RemoveAttributeValuePrimitive are: - csn: The change sequence number of the primitive. - type: The type of the attribute being removed. - value: The value being removed. Multiple values are not permitted. 5.3.2.7 RemoveAttributePrimitive The RemoveAttributePrimitive is used to remove an attribute and all Stokes and Good [Page 10] Internet-Draft LDUP Workgroup 15 July 2000 its values from an entry. RemoveAttributePrimitive ::= [APPLICATION 6] SEQUENCE { csn lDAPChangeSequenceNumber, type AttributeDescription } Parameters of the RemoveAttributePrimitive are: - csn: The change sequence number of the primitive. - type: The type of the attribute being removed. 5.4 EndReplicationRequest Extended Operation The EndReplicationRequest extended operation is sent from the replication supplier to the replication consumer to indicate the end of the sequence of replication updates. In the event that the supplier is sending a total update, the EndReplicationRequest extended operation contains a replica update vector. The consumer server must replace its replica update vector, if present, with the one provided by the suplier. In the event that the supplier is sending an incremental update, the replica update vector is absent. The EndReplicationRequest extended operation is defined as follows: EndReplicationRequest ::= [APPLICATION 23] SEQUENCE { requestName [0] LDAPOID, requestValue [1] OCTET STRING } The requestName of the EndReplicationRequest must be [OID to be assigned]. The requestValue of the EndReplicationRequest must be set to the BER-encoding of the following: requestValue ::= SEQUENCE { replicaUpdateVector Attribute OPTIONAL, returnConsumerUpdateVector BOOLEAN } If returnConsumerUpdateVector is TRUE, the consumer server must return its current update vector to the supplier in the EndReplicationResponse extended operation. Typically, the supplier will request the consumer's update vector for read-only replicas, since the read-only replica will never initiate a replication Stokes and Good [Page 11] Internet-Draft LDUP Workgroup 15 July 2000 session, and will therefore never have the opportunity to provide its update vector to other servers. 5.5 EndReplicationResponse Extended Operation The EndReplicationResponse extended operation is sent by a consumer to a supplier in response to an EndReplicationRequest extended operation. The EndReplicationResponse extended operation is defined as follows: EndReplicationResponse ::= [APPLICATION 23] SEQUENCE { requestName [0] LDAPOID, requestValue [1] OCTET STRING } The requestName of the EndReplicationResponse must be [OID to be assigned]. The requestValue of the EndReplicationResponse must be set to the BER-encoding of the following: requestValue ::= SEQUENCE { replicaUpdateVector Attribute OPTIONAL } The replicaUpdateVector contains the consumer's current replica update vector, and is optional. The consumer server should only send the replicaUpdateVector if requested by the supplier server in the EndReplicationRequest extended operation. 5.6 ReplicationUpdateResponse Extended Operation The ReplicationUpdateResponse extended operation is sent, unsolicited, by a consumer to a supplier when the consumer wishes the supplier to stop sending updates. An LDAPv3 extended response is defined in [LDAPv3] as follows: ExtendedResponse ::= [APPLICATION 24] SEQUENCE { COMPONENTS of LDAPResult, responseName [10] LDAPOID OPTIONAL, response [11] OCTET STRING OPTIONAL } The responseName of the ReplicationUpdateResponse must be the OID [OID to be assigned]. Stokes and Good [Page 12] Internet-Draft LDUP Workgroup 15 July 2000 The response field of the ReplicationUpdateResponse must be set to the BER-encoding of the following: response ::= SEQUENCE { replicaUpdateVector Attribute OPTIONAL abortUpdate BOOLEAN } The parameters of the ReplicationUpdateResponse are: - An optional update vector. If sent, this indicates that the consumer has committed all updates whose CSNs are covered by the transmitted update vector [see glossary for a definition of "covered by"]. - An optional AbortUpdate boolean flag. If a supplier receives a ReplicationUpdateResponse from a consumer with the AbortUpdate flag set to true, the supplier server MUST immediately cease sending updates and terminate its connection to the consumer. 6. Semantics of Full and Incremental Update protocols [To be written] 7. Summary of response codes The following list describes the response codes that may be included in the StartReplicationResponse, EndReplicationResponse, and ReplicationUpdateResponse extended operations. LDUPResponseCode ::= SEQUENCE { resultCode ENUMERATED { success (0), operationsError (1), protocolError (2), insufficientAccessRights (50), busy (51), excessiveCSNSkew (200), other (80) }, errorMessage LDAPString } The meanings of the response codes are as follows: success..................... As defined in [LDAPv3]. operationsError............. As defined in [LDAPv3]. protocolError............... As defined in [LDAPv3]. insufficientAccessRights.... Access denied. The identity that the Stokes and Good [Page 13] Internet-Draft LDUP Workgroup 15 July 2000 initiator provided in the bind request does not have sufficient privileges to perform the operation. busy........................ The replica is temporarily unable to accept updates. excessiveCSNSkew............ The consumer server has detected that the CSNs being generated by the supplier are too small (perhaps because the supplier's clock was set back). Updates from the supplier will not be applied. other....................... Some other error occurred. 8. Implications for log-based and state-based servers [To be written, or possibly incorporated into [ARCHITECTURE].] 9. Replication of access control and schema information [To be written, or possibly incorporated into [ARCHITECTURE]] 10. Security Considerations [To be written] 11. Glossary of Terms Covered by: We say that a CSN is "covered by" an update vector if and only if the CSN is less than or equal to the component of the update vector corresponding to the replica ID in the CSN. In other words, given a CSN with components and an update vector with CSNs ,..., then the CSN is covered by the RUV if and only if one of the following holds for some value i: a) r = ri and t < ti b) r = ri and t = ti and S < Si c) r = ri and t = ti and S = Si and s < si 12. Acknowledgments [To be written] 13. References [KEYWORDS] S. Bradner, "Key Words for use in RFCs to Indicate Requirement Lev- els", Harvard University, RFC 2119, March 1997. Stokes and Good [Page 14] Internet-Draft LDUP Workgroup 15 July 2000 [ARCHITECTURE] J. Merrells, E. Reed, U. Srinivasan, "LDAP Replication Architec- ture", Internet-Draft, draft-ietf-ldup-model-00.txt, April 1999. [LDAPv3] M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [URP]S. Legg, "LDUP Update Reconciliation Procedures", Internet-Draft, draft-legg-ldup-urp-00.txt, February 1999. [INFOMOD] E. Reed, "LDAP Replication Information Model", Internet-Draft, draft-reed-ldup-infomod-00.txt, November 1998. [REQ]R. Weiser, E. Stokes, "LDAP V3 Replication Requirements", Internet-Draft, draft-ietf-ldup-replica-req-00.txt, February 1999. 14. Author's Addresses Ellen Stokes Tivoli Systems 6300 Bridgepoint Parkway Austin, TX 78731 USA Email: estokes@tivoli.com phone: +1 512 436 9098 fax: +1 512 436 1199 Gordon Good America Online 150 Network Circle Mailstop USCA17-201 Santa Clara, CA 95054 USA EMail: ggood@netscape.com phone: +1 408 276 4351 This Internet Draft expires February 15, 2001. Appendix A - Complete ASN.1 Definition XXXggood - to be provided. Stokes and Good [Page 15] Internet-Draft LDUP Workgroup 15 July 2000 Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of develop- ing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Stokes and Good [Page 16] --------------4A370400D52D7F80062B35F1-- From owner-ietf-ldup@mail.imc.org Fri Jul 14 17:34:25 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 RAA28503 for ; Fri, 14 Jul 2000 17:34:24 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA14988 for ietf-ldup-bks; Fri, 14 Jul 2000 14:04:56 -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 OAA14981 for ; Fri, 14 Jul 2000 14:04:55 -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 VAA17371; Fri, 14 Jul 2000 21:07:00 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <4.3.2.7.0.20000714135237.00b8b1e0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 14 Jul 2000 14:06:58 -0700 To: ietf-ldapext@netscape.com, ietf-ldup@imc.org From: "Kurt D. Zeilenga" Subject: LDAPv3bis BOF at IETF#48 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: The following BOF has been approved and should be scheduled soon. Those interested are encouraged to participate. Please note that we are only collecting suggested changes. This will be used as an aid in identifying items needing to be worked and to develop more concrete proposals. Below is the draft agenda for this BOF. If you like to propose additional agenda items, please drop Bob and I a note. Regards, Kurt Name: LDAPv3bis Chairs: Kurt Zeilenga RL "Bob" Morgan Mailing list: ietf-ldapv3bis@OpenLDAP.org http://www.openldap.org/lists/ietf-ldapv3bis/ Introduction: LDAPv3 core specifications (RFC 2251-56) must be revised if they are to be progressed to Draft Standard per the IESG Notice contained within these documents. With the approval of RFC 2829 and 2830, the necessary secure authentication mechanisms to obtain Draft Standard status have now available. In addition, the community has obtain a wealth of operational experience using the current specifications. The community has identified a number of areas where the specifications need to amended. These amendments include a few significant substantive changes, a fair number of lessor substantive changes, and many clarifications. A forum for discussing and addressing these issues is needed. Purpose: The purpose of this BOF is to discuss proposed updates to the LDAPv3 core protocol specification (RFC 2251-56, 2829-30), to identify work items, and discuss formation of a working group specifically chartered to address identified work items. Extensions to LDAPv3 are not within the scope of this BOF as this is the realm of existing IETF working groups. Background: The LDAPv3 specifications were developed by the ASID and LDAPext working groups. The ASID working group is defunct. The LDAPext WG is focused on significant protocol extensions such as Access Control, APIs, Referrals, and CLDAP. A separate working group is currently proposed to focus energies to address LDAPv3 specification updates while not distracting LDAPext from their chartered work. However, at the discretion of the IESG, work items identified by this BOF may be assigned to LDAPext or other appropriate WG (after appropriate charter review). Agenda: Agenda Review Introduction Discuss IESG Note Discuss LDAPv3 Applicability Statement Discuss incorporation of rescodes I-D into 2251bis Discuss incorporation of partial responses I-D into 2251bis Discuss reorganization of specification Discuss Mark Wahl's 75+ odd changes Discuss Kurt Zeilenga's 75+ odd changes Discuss relationship to X.500 issues Discuss other issues Discuss working group formation issues RFC to be discussed: 2251-2256, 2829-2830 I-D to be discussed: draft-hodges-ldapv3-as-00.txt draft-just-ldapv3-rescodes-02.txt draft-rharrison-ldap-extpartresp-01.txt draft-wahl-ldapv3bis-*.txt (to be issued) draft-zeilenga-ldapv3bis-*.txt From owner-ietf-ldup@mail.imc.org Sun Jul 16 23:36: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 XAA25402 for ; Sun, 16 Jul 2000 23:36:55 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA29038 for ietf-ldup-bks; Sun, 16 Jul 2000 20:04:02 -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 UAA29033 for ; Sun, 16 Jul 2000 20:04:00 -0700 (PDT) Received: (qmail 26609 invoked from network); 17 Jul 2000 03:06:06 -0000 Received: from softdnserror (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 17 Jul 2000 03:06:06 -0000 Reply-To: From: "Steven Legg" To: Cc: , Subject: RE: LDAP subentry alignment with X.500 subentry Date: Mon, 17 Jul 2000 13:08:52 +1000 Message-ID: <001501bfef9c$56aa6f10$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: <001701bfed6c$c3a0a800$17448490@vic.bigpond.net.au> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal 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: Friday, 14 July 2000 18:23 > To: Robert.Byrne@France.Sun.COM; Alan.Lloyd@ca.com; Ron.Ramsay@ca.com; > ietf-ldapext@netscape.com > Cc: ietf-ldup@imc.org > Subject: RE: LDAP subentry alignment with X.500 subentry [snip] > [Robert] > Albert, doesn't an entry know the other attributes that it > contains as well > and so could evaluate an arbitrary filter ? > [Albert] > Sorry, I should have said "the (structural) object class of > an entry is > fixed and therefore the set of applicable subentries does not > need to be > recalculated on every search". With general filters such a > calculation would > be needed on every search, for every subentry that has a > parent within the > base of the search applied to every entry within the scope of > the search. > This is multiplying the cost of a search by the number of potentially > applicable subentries (not just the number of actually applicable > subentries). The specificationFilter of a SubtreeSpecification applies to the objectClass attribute rather than the structuralObjectClass. Since the objectClass can contain optional auxiliary object classes that come and go, a conformant X.500 implementation already has to deal with the situation where the set of applicable subentries changes. Some of our customers need to be able to set access controls based on the non-objectClass attributes of the entry. The way we have achieved this with X.500 basic access control is to define an auxiliary object class, with no mandatory or optional attributes, that we use to tag entries satisfying an implied filter on the entry contents. SubtreeSpecifications then reference the auxiliary class in their specificationFilters. The auxiliary class tagging has to be maintained manually. Being able to filter on arbitrary entry contents in the specificationFilter would be better. [snip] > > Please send or CC any comments to LDUP as I won't see them in LDAP-EXT. > > Seeya, Albert Regards, Steven From owner-ietf-ldup@mail.imc.org Mon Jul 17 07:12: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 HAA05130 for ; Mon, 17 Jul 2000 07:12:21 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA10831 for ietf-ldup-bks; Mon, 17 Jul 2000 03:39:33 -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 DAA10827 for ; Mon, 17 Jul 2000 03:39:32 -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 GAA25752; Mon, 17 Jul 2000 06:41:52 -0400 (EDT) Message-Id: <200007171041.GAA25752@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-subentry-03.txt Date: Mon, 17 Jul 2000 06:41:52 -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 Subentry Schema Author(s) : E. Reed Filename : draft-ietf-ldup-subentry-03.txt Pages : 5 Date : 14-Jul-00 This document describes an object class called ldapSubEntry which MAY be used to indicate operations and management related entries in the directory, called LDAP Subentries. This version of this document is updated with an assigned OID for the ldapSubEntry object class. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-subentry-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-subentry-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-subentry-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: <20000714143733.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-subentry-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-subentry-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000714143733.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Mon Jul 17 10:36: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 KAA05092 for ; Mon, 17 Jul 2000 10:36:29 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA14304 for ietf-ldup-bks; Mon, 17 Jul 2000 06:45:15 -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 GAA14300 for ; Mon, 17 Jul 2000 06:45:14 -0700 (PDT) Received: (qmail 29170 invoked from network); 17 Jul 2000 13:42:49 -0000 Received: from cpe-144-132-68-23.vic.bigpond.net.au (HELO w98sysrec) (144.132.68.23) by relay1.pair.com with SMTP; 17 Jul 2000 13:42:49 -0000 X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: Cc: , Subject: RE: LDAP subentry alignment with X.500 subentry Date: Mon, 17 Jul 2000 23:46:40 +1000 Message-ID: <000801bfeff5$702bae00$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: <001501bfef9c$56aa6f10$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 Steven, Thanks for: a) The correction below. b) The explanation of why the non-restriction to structural classes is useful. c) The explanation of why general filters would be more useful. Clearly I was wrong about the restriction to object class avoiding any need to dynamically track which DACDs an entry is in, though I still think it might be simpler and more efficient than for a general filter, eg some implementations only having to recalculate when an entry changes its object class attribute (rarely), rather than for any change. I'm still not convinced about the advantage of c) over b), although this certainly does at least diminish one argument against c). Other reasons are: 1. General principle that LDAP should remain "lighter" than X.500 and compatible with it. Therefore any superset variations should be demonstrably necessary, eg to simplify something else, not just desirable. Proper subentries are demonstrably necessary to simplify access control. As Kurt pointed out, not providing them will just result in more complex ways of doing the same thing being required anyway. But "enhanced" subentries are not demonstrably necessary. 2. What kinds of DACD can be specified should be a matter for schema administrators (ie "manually" in practice), not for access control administrators. It really is an issue of maintaining consistent schema (in this case for access control) so that there is a common understanding of what each type of DACD actually means. Maintaining that commonality of understanding of the schema is inevitably and intentionally less flexible than the changes that other kinds of administrators and end users should be allowed to make to the directory. The concept of a DACD is currently less familiar to LDAP administrators, who are often both schema and access control administrators (whether or not they understand much about either). The concept of a general filter is more familiar to them, but the relative rigidity of DACDs will actually make it easier for administrators and end users to understand in the long run, as the point of standardizing these things is to enable full interoperability over much larger areas than most LDAP administrators are currently administering, with delegation within those areas. eg "Allow printer administers to administer printers within this part of the tree" is easily understood. If it turns out that a different set of permissions should be granted with respect to color printers, then they are entries with a different type of behaviour from other printers and should have their own object class, even if they don't need extra attributes. If they do not need recognition in the common schema applicable organization wide as a distinct type of entry, then any variations in types of access control should be local to the particular part of the tree that perceives the need for this. Authority over types of access control should not be delegated unless one is also willing to delegate authority over schema. Delegation is rapidly moving down to end users and lower level administrators need a clear and stable conceptual framework. If its really inconvenient, lower level administrators can ask schema administrators to define a new object class. The standards do not prevent them tagging entries with auxiliary object classes once those classes have been defined, but only from introducing new ones without coordination. An implementation might make such tagging unnecessarily "manual", but that it is not a standards problem. The goal here is to reduce variation in conceptual framework, not facilitate it. General filters are intended to, and would succeed in, enabling easy ad hoc changes to the conceptual framework for administering access controls. If that was desirable, then general filters would be desirable. As it is undesirable, they are a bad idea. 3. I suspect that the interaction between general filters, permissions and priorities is likely to not be well understood, and result in errors when people are given permission to change an attribute value without understanding that this will have side effects on access controls. 4. Even with atomicity, I don't think its going to be at all easy to cope with the interactions between ACI and replication. My error regarding structural object classes may have resulted from wishful thinking, since it will be even harder to cope, given that an object can move in and out of a DACD as a result of a change in its auxiliary object classes. But at least that only adds one kind of replicated change to worry about, on top of changes to entry and prescriptive ACI themselves (not to mention group membership and changes in distinguished name prefixes that can also affect access controls). Adding potential surprises in permissions resulting from unsynchronized replication of other attribute values would not be helpful. In earlier discussions on the LDUP list it was recognized that this problem of entries moving in and out of the scope of a filter made it undesirable to allow general filters for specifying fractional replicated areas. 5. Its clear that there is a strong reluctance to introduce proper subentries at all, despite their obvious necessity for ACI, which goes far beyond what is immediately needed for LDUP. I would rather see a successful quick resolution by acceptance of existing standards for subentries, or a viable subset of them, than a protracted delay in achieving any reasonable support for ACI at all. (The arguments raised against the current draft by others already establish that at least some specification of the base and a filter on object class will be necessary before final call. Adding chop specifications does not really complicate implementation much, whereas general filters still does to at least some extent, and would therefore increase the resistance and consequently the delay for accepting the necessity for having proper subentries). BTW If the reference to manual maintenance of tagging below means that your customers *want* the DACD applicable to an entry to change dynamically with the ordinary contents of the entry, and you are having to change the object classes in synchronization with other changes to the entry, then I can only suggest seeking more sensible customers ;-) I have assumed above that you were only referring to the manual difficulties of tagging entries when the customer's conceptual framework changes, not when the entries change. Implementation tools should allow administrators to apply a general filter to re-tag entries, without a need for standardization. A standard DUA should be able to do that just by scripting to apply the change desired to each entry within the scope of the filter. If standards were required for directory operations that apply to more than entry, they would be be for more general changes, not just in relation to access controls. Seeya, Albert [original below] > [Robert] > Albert, doesn't an entry know the other attributes that it > contains as well > and so could evaluate an arbitrary filter ? > [Albert] > Sorry, I should have said "the (structural) object class of > an entry is > fixed and therefore the set of applicable subentries does not > need to be > recalculated on every search". With general filters such a > calculation would > be needed on every search, for every subentry that has a > parent within the > base of the search applied to every entry within the scope of > the search. > This is multiplying the cost of a search by the number of potentially > applicable subentries (not just the number of actually applicable > subentries). [Steven] The specificationFilter of a SubtreeSpecification applies to the objectClass attribute rather than the structuralObjectClass. Since the objectClass can contain optional auxiliary object classes that come and go, a conformant X.500 implementation already has to deal with the situation where the set of applicable subentries changes. Some of our customers need to be able to set access controls based on the non-objectClass attributes of the entry. The way we have achieved this with X.500 basic access control is to define an auxiliary object class, with no mandatory or optional attributes, that we use to tag entries satisfying an implied filter on the entry contents. SubtreeSpecifications then reference the auxiliary class in their specificationFilters. The auxiliary class tagging has to be maintained manually. Being able to filter on arbitrary entry contents in the specificationFilter would be better. [snip] > > Please send or CC any comments to LDUP as I won't see them in LDAP-EXT. > > Seeya, Albert Regards, Steven From owner-ietf-ldup@mail.imc.org Mon Jul 17 10:59:27 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 KAA15714 for ; Mon, 17 Jul 2000 10:59:26 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA15221 for ietf-ldup-bks; Mon, 17 Jul 2000 07:28:04 -0700 (PDT) Received: from mta03-svc.ntlworld.com (mta03-svc.ntlworld.com [62.253.162.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15217 for ; Mon, 17 Jul 2000 07:28:02 -0700 (PDT) Received: from dwc-acer ([62.252.104.10]) by mta03-svc.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with ESMTP id <20000717143022.MEWA16423.mta03-svc.ntlworld.com@dwc-acer>; Mon, 17 Jul 2000 15:30:22 +0100 From: "David Chadwick" Organization: University of Salford To: "Kurt D. Zeilenga" , ietf-ldapext@netscape.com, ietf-ldup@imc.org Date: Mon, 17 Jul 2000 15:29:37 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: LDAPv3bis BOF at IETF#48 Reply-to: d.w.chadwick@salford.ac.uk Message-ID: <39732661.15578.1784E6F@localhost> In-reply-to: <4.3.2.7.0.20000714135237.00b8b1e0@infidel.boolean.net> 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 forwarded: Fri, 14 Jul 2000 14:07:07 -0700 (PDT) Date sent: Fri, 14 Jul 2000 14:06:58 -0700 To: ietf-ldapext@netscape.com, ietf-ldup@imc.org From: "Kurt D. Zeilenga" Subject: LDAPv3bis BOF at IETF#48 Forwarded by: ietf-ldapext@netscape.com > The following BOF has been approved and should be scheduled > soon. Those interested are encouraged to participate. > > Please note that we are only collecting suggested changes. > This will be used as an aid in identifying items needing to > be worked and to develop more concrete proposals. > > Below is the draft agenda for this BOF. If you like to > propose additional agenda items, please drop Bob and I a > note. Kurt the following document may be in Mark's list of 75+ other changes. If not can you please include it in the agenda Ta David > > Regards, Kurt > > > > Name: LDAPv3bis > > Chairs: > Kurt Zeilenga > RL "Bob" Morgan > > Mailing list: > ietf-ldapv3bis@OpenLDAP.org > http://www.openldap.org/lists/ietf-ldapv3bis/ > > Introduction: > LDAPv3 core specifications (RFC 2251-56) must be revised if > they are to be progressed to Draft Standard per the IESG > Notice contained within these documents. With the approval > of RFC 2829 and 2830, the necessary secure authentication > mechanisms to obtain Draft Standard status have now available. > > In addition, the community has obtain a wealth of operational > experience using the current specifications. The community > has identified a number of areas where the specifications > need to amended. These amendments include a few significant > substantive changes, a fair number of lessor substantive changes, > and many clarifications. A forum for discussing and addressing > these issues is needed. > > Purpose: > The purpose of this BOF is to discuss proposed updates to the > LDAPv3 core protocol specification (RFC 2251-56, 2829-30), > to identify work items, and discuss formation of a working > group specifically chartered to address identified work items. > > Extensions to LDAPv3 are not within the scope of this BOF > as this is the realm of existing IETF working groups. > > Background: > The LDAPv3 specifications were developed by the ASID and > LDAPext working groups. The ASID working group is defunct. > The LDAPext WG is focused on significant protocol extensions > such as Access Control, APIs, Referrals, and CLDAP. A separate > working group is currently proposed to focus energies to address > LDAPv3 specification updates while not distracting LDAPext from > their chartered work. However, at the discretion of the IESG, work > items identified by this BOF may be assigned to LDAPext or other > appropriate WG (after appropriate charter review). > > Agenda: > Agenda Review > Introduction > Discuss IESG Note > Discuss LDAPv3 Applicability Statement > Discuss incorporation of rescodes I-D into 2251bis > Discuss incorporation of partial responses I-D into 2251bis > Discuss reorganization of specification > Discuss Mark Wahl's 75+ odd changes > Discuss Kurt Zeilenga's 75+ odd changes > Discuss relationship to X.500 issues > Discuss other issues > Discuss working group formation issues > > RFC to be discussed: > 2251-2256, 2829-2830 > > I-D to be discussed: > draft-hodges-ldapv3-as-00.txt > draft-just-ldapv3-rescodes-02.txt > draft-rharrison-ldap-extpartresp-01.txt > draft-wahl-ldapv3bis-*.txt (to be issued) > draft-zeilenga-ldapv3bis-*.txt > > *************************************************** 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 Mon Jul 17 17:22: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 RAA16144 for ; Mon, 17 Jul 2000 17:22:46 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA23423 for ietf-ldup-bks; Mon, 17 Jul 2000 13:44:08 -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 NAA23419 for ; Mon, 17 Jul 2000 13:44:06 -0700 (PDT) Received: (qmail 22841 invoked from network); 17 Jul 2000 20:41:41 -0000 Received: from cpe-144-132-68-23.vic.bigpond.net.au (HELO w98sysrec) (144.132.68.23) by relay1.pair.com with SMTP; 17 Jul 2000 20:41:41 -0000 X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: Cc: Subject: RE: various comments (was Re: What's going on? - Status of Requirements...) Date: Tue, 18 Jul 2000 06:45:38 +1000 Message-ID: <001701bff02f$f74e5ba0$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: <000b01bfdf30$9aad82f0$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, Thanks for the detailed and helpful response a while back. http://www.imc.org/ietf-ldup/mail-archive/msg00576.html Looks to me like we've moved into concrete discussion of various issues between URP and MDCR and their relation to requirements (thanks also to Ryan for getting this going). Sorry about the long delay responding. I propose we should discuss each of those issues under separate headings rather than continuing within a thread that started from a request for status reports. I'm planning to chop up your message, re-arranging it within the categories I perceive and want to respond to, each with a link here from which people can get the original context. I'm starting now to ensure anyone interested has time to think about the issues before the Pittsburgh meeting, which I will be unable to attend. Finishing may still be delayed for a week or so due to other commitments. Meanwhile, here's a summary of the issues as I see them, and their relation to the original request for status reports. 1. "Atomicity and related concepts". Disagreement about definition, importance and relation to other concepts and requirements. Should be clarified and resolved by definitions, explanations and requirements in requirements document before final call. 2. "ModifiersName and other Operational Attributes". Disagreement about definition, semantics, and implications of URP and MDCR proposals for handling them. Definition and semantics should be clarified in requirements document before final call. URP and MDCR handling should be clarified in further discussion of URP and MDCR. Unclear whether there is a disagreement about a requirement to handle ModifiersName "correctly", because of lack of agreed definition of what would be "correct". 3. "Change Reports - ProtocolOps or Primitives". Reference by Steve to non-LDAP and non-X500 replicating servers may involve clarification of requirements. Other issues can be clarified in discussion of URP and MDCR approaches. 4. "Eventual Convergence - Version numbers or timestamps". Agreement that URP could operate with priority for either version numbers or timestamps. I maintain that version numbers should have priority, for reasons fully explained in the Coda file system research. If URP remains the only protocol under consideration by the WG it can and should be changed to do so. Design issue, not requirements (though relevant to any requirement for eventual convergence - see below). Implicit agreement that in the absence of further changes, all replicas should converge to the same state and any protocol that does not guarantee this is unacceptable. Disagreement as to whether each of MDCR and URP meet that requirement. Steve maintains that MDCR cannot meet that requirement. I maintain that MDCR can and that URP as currently drafted does not, but that URP is capable of doing so, provided that version numbers have priority over timestamps. Although there seems to be no disagreement about requirements on this between Steve and myself, I cannot resist pointing out that the current requirements draft actually "requires" a "flexible" ability to accommodate both models that guarantee convergence and models that will diverge. 5. "Oscillation". Implicit agreement that no protocol should oscillate. No need to state in requirements as both obvious and covered by 4 above. Steve says he has an example showing that MDCR oscillates. I say that neither MDCR nor URP oscillates. Unfortunately the margin of this email is too small for the proof ;-) Fortunately it is short enough to present in another email rather than leaving the world waiting breathlessly for hundreds of years... or subjecting it to eyeglazing discussion of examples. 6. "Implementation and Performance Issues". Disagreement as to whether there is any significant difference in implementation difficulty or performance. 7. "Revocation notices". Implicit agreement that MDCR could add them and that URP makes no provision for them because it does not revoke anything. Disagreement as to whether they are useful. 8. "Strong consistency and transactions". Steve has sketched an idea that Alison and Steve have for adding these to URP. While relevant to the WG, I don't think they are intended to meet any objections to adoption of URP for multi-master replication as they do not satisfy the definition of, nor the requirements for, multi-master replication. I believe this does shed further light on the requirements draft problem, as by failing to give any explanation whatever of user needs for multi-master replication, that draft invites confusion. Original message below. I am adding comments re item 8 at the end as further discussion of it has already occurred in this thread. Comments on other 7 will follow under the 7 headings listed. ******************************* [snip] > [RM] > On the subject of the requirements / URP draft: > > 1. I still believe the requirements draft should be more > explicit about atomicity of operations being maintained > across replication. In my various re-readings of this > draft, I have at times found justification for both > sides (maintain and do not maintain) and I still think > that maintaining atomicity is necessary. > > 2. The URP draft should be explicit in how it maintains > atomicity of operations across replication. I'm pretty > sure from my last perusal it doesn't now. > > [AL] > Understood. > URP certainly does not maintain atomicity and is explicit > about that. This > problem is not in the URP draft, but in the requirements > draft. If there was > a requirement to maintain atomicity there would be a > completely different > URP (not necessarily MDCR). Atomicity is not the right concept to be arguing about in a multimaster replication environment. Consider this example. At server S1 at time t1 a user modify request on an entry adds attribute A1 and replaces the existing values of attribute A2. At server S2 at time t2 (t2 > t1) a user modify request replaces attribute A2. Some time later the modify from server S1 arrives at S2. If S2 performs this operation atomically it will replace the newer (time t2) value(s) of attribute A2 with the older values (time t1). This is clearly the wrong thing to do. If S2 adds the new attribute A1 but ignores the replacement of A2 (as URP would do) then it produces the same outcome as the serial execution of the two modify requests, though the action doesn't fit the usual definition of "atomic". If we are going to discuss atomicity in replication then we need a more meaningful definition. URP makes all the replicas produce an outcome that is equivalent to the serial atomic execution of all the updates. That is as atomic as it needs to be. The real question revolves around the preconditions of a user update request. If we look at the equivalent serial processing of a collection of updates performed at two or more multimaster replicas then some of those updates will be "executed" against a different database state than actually existed at the time they were really performed by one of the replicas. The URP philosophy is that most of the time for most applications it doesn't really matter. The MDCR philosophy is that it is better to completely disregard the user's update, after the fact, just in case the state of the entry did matter. [snip] > [RM] > 3. Once URP maintains change atomicity, the "modifiersName" > issue in my mind goes away. There may be others that > still remain... > > [AL] > Agreed. "modifiersName" is impossible without atomicity, and > easily achieved > with it (as are many other things). You seem to be assuming that the DSA maintained operational attributes are being independently maintained by each replica. The intent in URP is that the replica executing the user update request will modify the operational attributes, like modifiersName and modifyTimestamp, as required, and that these changes will also be reflected in the primitives sent to the other replicas. Those other replicas will keep the values of these operational attributes with the highest CSNs, which will correspond to the latest change to the user attributes. Exactly the same outcome as a serial execution of the updates in CSN order. [snip] > As regards efficient propagation of the tree via the report > propagation > protocol I believe the encoding on the wire is as efficient > and as simple as > possible by just conveying the actual LDAP protocolOps for > the changes. The > only redundancy is for the relatively small proportion of changes that > affect the Directory Information Tree (DIT), ie add, del and modifyDN, > rather than just the Directory Information Base (DIT), ie modify (for > changes to non-distinguished attributes and values). The replicating servers aren't necessarily LDAP or X.500 DSAs, so the update protocol operations aren't necessarily just LDAP, DAP or DSP operations. Also, these protocols are still subject to change so additional operations may be defined in the future, or existing ones extended. LDAP also has a means for vendors to define proprietary operations. We can't expect LDUP implementors to cover all the possibilities. The original request also doesn't carry the changes to operational attributes or other vendor specific DSA invoked changes such as might occur to maintain referential integrity of DNs. Breaking all update requests into replication primitives gets around these problems. [snip] > Incidentally the MDCR draft also proposes adoption of the Coda report > propagation protocols adopted by AD. I believe that would be > a considerable > improvement without requiring any substantial change to either the > requirements or architecture and especially beneficial to the > existing URP > design as there is a lot of avoidable complication there > simply because > reports are propagated out of sequence by each replica. Propagating the changes strictly in CSN order wouldn't make much difference. The "complexity" arises from the requirement to process local changes out of order with updates reported by other replicas. Whether those remote changes are reported in order becomes irrelevant. > > That is completely independent of the issue of atomicity. > > [RM] > 2. The whole "weeding and summarizing" discussion left me > confused and therefore worried. There seems to be an > unstated assumption that all replicas are "well-connected". > My concern is that if one or more replicas are > "sporadically-connected" then the size of the trees could > become an issue. Again, I may be missing something in the > draft, but if so, I'd claim it is buried. Because the > whole discussion left me confused, I think some clarification > in the form of an example would help. > > Ryan > > [AL] If the WG accepts the draft as being on its agenda for > discussion I > think a lot more work will be needed on it, including > detailed examples (and > diagrams) for the weeding and summarizing process as you suggest. I too have some concerns about the "weeding and summarizing" stuff. In particular it is not possible to guarantee that all replicas will converge toward the same state. A version of an entry cannot be made "Durable" until after some unspecified delay to see if any higher version shows up. For an entry version to become the definitive (durable) version depends not only on earlier events but also on events that are yet to occur! If the waiting time is chosen badly the replicas will quickly diverge. No matter what delay is chosen there is always a chance that a higher version will pop up immediately afterward. Also, I can also construct examples where two replicas endlessly flip back and forth between two competing strands with no entry versions ever becoming durable. > A simpler approach to conflict resolution would just resolve > each conflict > immediately, at each DUA that encounters a conflicting change, by > suppressing the change with the lower version number etc and > propagating > only 1 survivor (which may itself be suppressed at another > DUA with the > survivor propagated from that conflict in turn reaching the > previous DUA and > suppressing the previous survivor there). I don't think this is enough to solve the problems mentioned above. > This is more or > less what AD does > (for attributes). > URP makes the fatal mistake of splitting > the operations > into primitives so as to effectively merge conflicts instead > of resolve > them, and adds the serious mistake of giving higher priority > to timestamps > than to version numbers. The LDUP CSNs can be used either way. URP doesn't care, it just sees a monotonically increasing value. > This means the "survivor" at each > DUA separately is > just the latest, with no actual conflict resolution at all. > > The tree is especially important for "sporadically-connected" > replicas since > they are the most likely to generate conflicts. In most cases > the tree would > be trivial or very small, but if it is not recognized as a tree, that > "simplification" makes everything else become incredibly complicated. > > I don't see a large tree as an implementation problem in itself - the > overhead is only about 12 bytes of RAM per conflicting change. You would also need to store enough information to reconstruct the previous versions of an entry on each strand. To change the current entry version from one strand to another requires unwinding index changes, etc, back to the common branching point and then applying the saved change requests on the new strand. URP never has to go backwards. [snip] > The conflicts form a tree in reality, whether it is > recognized or not. If > that tree becomes large then URP would produce a high rate of > "Extraordinary > States" and "Transient Extraordinary States" while MDCR would > produce a high > rate of revocation notices because it has at least recognized > the reality. > Neither is appropriate for directory applications. (In my view even an > extremely low rate of "Extraordinary States" without any > means except manual > administration to recover from them is completely unacceptable). I don't expect many LDAP client application developers will want to deal with the complexities of out-of-band revocation notices, or deal with restoring the application context of the original change so it can be repeated. The enterprising ones will probably just send a series of spurious changes to an entry after each real change just to "up" the version number and so increase the chance of the real change sticking. In effect, what we have done with URP is hardwire a reasonable conflict resolution mechanism (best effort merge) that is (we think) good enough for most uses of the directory. But that doesn't leave the remaining uses out in the cold. Alison and I have previously mentioned in passing that we have an idea for providing strong consistency and transactions with URP. This is a good time to sketch out what we mean. This is the sequence of events for a user update request requiring or requesting strong consistency: The receiving replica (let's call it the primary) opens a session with each of the other replicas and sends a request for all update primitives up to and including the latest change to the target entry. This is just a variation on a regular LDUP session. However the other replicas will also lock the target entry to prevent any local changes to it. Some sort of deadlock detection will be necessary. The primary replica applies all the primitives it has received and then attempts the user request. If it fails with an error the sessions with the other replicas are closed and they drop the locks on the target entry. If the request succeeds the primary server sends the primitives up to and including the ones generated from the current user request, then closes the sessions causing the locks to be released. If the primary doesn't send the latest primitives the other replicas will just import them the next time they action a strong consistency update on the same entry. Two-phase commit isn't required. Handling transactions is straightforward. The initial request from the primary replica specifies a range of affected entries (maybe with something like a search filter) instead of just the one target entry. The primary is also allowed to send multiple requests within the same session since it won't generally know all the entries affected by a transaction at the beginning. The above scheme requires all updatable replicas to be available to perform a strong consistency update but there is a more general scheme that allows some of the replicas to be unavailable. If there are N replicas then it is only necessary to contact M (M > N/2) of them to make an update provided N-M+1 of them are contacted before evaluating any strong consistency query. The original description was the special case of M = N. Regards, Steven ******************************** [AL] (Commenting only on the last item). If DSAs have to contact any other replica, whether all, a majority or just a few, before applying a change, they are not providing the benefits of multi-master replication. This is clearly excluded by the accurate definition of multi-master replication in the WG charter. The requirements draft should clearly explain that the reasons for needing multi-master replication standards is to meet user needs for changes to be available locally to other users of a local DSA, whether or not that DSA is able to contact other DSAs, and without suffering the performance and scalability problems of attempting to contact any of them before applying the change and making it locally available. Instead, the only scenario in the requirements draft which does involve that user need, is not identified as being relevant to multi-master replication, while every single scenario identified as explaining the need for multi-master replication actually involves no need for multi-master replication at all - either because it is to do with meta directories rather than replication, or because it could be achieved just as well by single master replication. Once you give up the scalability and performance of local availability of changes made possible by multi-master replication, I see no advantage in this proposal over the use of failover single master replication as proposed earlier by Alan Lloyd. The latter is already covered by standards for single master replication and by the fact that a DSA need not hold any naming context or shadow any naming context, but can just be equivalent to a DUA that speaks DAP. Both ideas are simply irrelevant to the requirements we ought to be trying to meet. This would be obvious if we actually had a requirements draft that actually talked about those needs. Incidentally Coda does provide very closely related ideas for cacheing file server clients to contact a subset of multi-master replicating file servers in an enhancement of the Andrew File System for "sometimes disconnected" use. As mentioned in MDCR, it is worth studying thoroughly for ideas relevant to LDAP replication and I have attempted to adapt some ideas from it in the MDCR report propagation protocol, also used by Active Directory. Needless to say, Coda does not attempt to merge changes made to different aspects of a file by different clients eg by applying a name change made at one client to a contents change made concurrently at another. Unfortunately when the servers are partitioned, Coda has no alternative but to resort to manual fixups for conflicts, in much the same way that any LDUP protocol will have to for conflicting create, modifyDN and delete operations. Nevertheless there is really extensive research there on precisely HOW to deal with contacting less than all the servers at once. It does center around revocation notices and priority for version numbers rather than timestamps. From owner-ietf-ldup@mail.imc.org Mon Jul 17 20:47: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 UAA17193 for ; Mon, 17 Jul 2000 20:47:35 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA27664 for ietf-ldup-bks; Mon, 17 Jul 2000 17:18:52 -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 RAA27660 for ; Mon, 17 Jul 2000 17:18:51 -0700 (PDT) Received: (qmail 2703 invoked from network); 18 Jul 2000 00:16:29 -0000 Received: from cpe-144-132-68-23.vic.bigpond.net.au (HELO w98sysrec) (144.132.68.23) by relay1.pair.com with SMTP; 18 Jul 2000 00:16:29 -0000 X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: Cc: Subject: 5. "Oscillation" Date: Tue, 18 Jul 2000 10:20:28 +1000 Message-ID: <001b01bff04d$fc9f2760$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 Steve, Here's the response to item 5, which I summarized as: *** 5. "Oscillation". Implicit agreement that no protocol should oscillate. No need to state in requirements as both obvious and covered by 4 above. Steve says he has an example showing that MDCR oscillates. I say that neither MDCR nor URP oscillates. Unfortunately the margin of this email is too small for the proof ;-) Fortunately it is short enough to present in another email rather than leaving the world waiting breathlessly for hundreds of years... or subjecting it to eyeglazing discussion of examples. http://www.imc.org/ietf-ldup/mail-archive/msg00614.html *** Comments follow original below. *** [Steven] Also, I can also construct examples where two replicas endlessly flip back and forth between two competing strands with no entry versions ever becoming durable. > A simpler approach to conflict resolution would just resolve > each conflict > immediately, at each DUA that encounters a conflicting change, by > suppressing the change with the lower version number etc and > propagating > only 1 survivor (which may itself be suppressed at another > DUA with the > survivor propagated from that conflict in turn reaching the > previous DUA and > suppressing the previous survivor there). I don't think this is enough to solve the problems mentioned above. [Albert] Well, all you need to do is exhibit just one of those examples and I am sure everyone, including me, will agree that MDCR is unacceptable. I found the discussions of various examples of URP failures when wading through the archives quite eyeglazing, so I can sympathize with your reluctance to spark another such discussion. 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. Consider a finite set of N replicas and a finite set of changes applied to a single entry at some or all of those replicas within a finite time interval. 1. There is a finite set of CSNs resulting from the original entries and the changed entries that result, and a one to one association between the CSN of an entry at a replica and the state of that entry at that replica. 2. This finite set of CSNs is strictly ordered and imposes a corresponding strict ordering on entry states. Exactly one entry state corresponds to the highest CSN in that strict ordering. 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). 4. Therefore all entries will converge to the same state. There may be a combinatorial explosion of transient states and some of them may be "Transient Extraordinary States", but URP *will* converge to some common state, which may be regular or "Extraordinary" depending on factors beyond the scope of this analysis (and possibly any other). If you accept that proof as showing URP converges you should accept that the same proof shows MDCR converges, as you have agreed that CSNs and USNs are similar strict (lexical) orderings. The only differences are: a) In para 3, MDCR propagates all changes to all replicas whether they immediately replace the current entry there or not. It is slightly more obvious, though no more true, that the change with the highest USN will be propagated to all replicas, and therefore will become the convergent entry at all replicas. b) The number of visible entry states (and of tree history states) at different replicas is never greater than the number of actual changes that were made concurrently at different replicas. With MDCR there are no new "transient" states and no combinatorial explosion. c) The final result is completely predictable and never "Extraordinary". From owner-ietf-ldup@mail.imc.org Mon Jul 17 20:48: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 UAA17558 for ; Mon, 17 Jul 2000 20:48:20 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA27654 for ietf-ldup-bks; Mon, 17 Jul 2000 17:18:45 -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 RAA27650 for ; Mon, 17 Jul 2000 17:18:43 -0700 (PDT) Received: (qmail 2577 invoked from network); 18 Jul 2000 00:16:20 -0000 Received: from cpe-144-132-68-23.vic.bigpond.net.au (HELO w98sysrec) (144.132.68.23) by relay1.pair.com with SMTP; 18 Jul 2000 00:16:20 -0000 X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: Cc: Subject: 4. "Eventual Convergence - Version numbers or timestamps". Date: Tue, 18 Jul 2000 10:20:20 +1000 Message-ID: <001a01bff04d$f5f0a4c0$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 Steve, Here's the response to item 4, which I summarized as: 4. "Eventual Convergence - Version numbers or timestamps". Agreement that URP could operate with priority for either version numbers or timestamps. I maintain that version numbers should have priority, for reasons fully explained in the Coda file system research. If URP remains the only protocol under consideration by the WG it can and should be changed to do so. Design issue, not requirements (though relevant to any requirement for eventual convergence - see below). Implicit agreement that in the absence of further changes, all replicas should converge to the same state and any protocol that does not guarantee this is unacceptable. Disagreement as to whether each of MDCR and URP meet that requirement. Steve maintains that MDCR cannot meet that requirement. I maintain that MDCR can and that URP as currently drafted does not, but that URP is capable of doing so, provided that version numbers have priority over timestamps. Although there seems to be no disagreement about requirements on this between Steve and myself, I cannot resist pointing out that the current requirements draft actually "requires" a "flexible" ability to accommodate both models that guarantee convergence and models that will diverge. http://www.imc.org/ietf-ldup/mail-archive/msg00614.html *** Comments are interspersed with original below. *** [snip] [Albert] > Incidentally the MDCR draft also proposes adoption of the Coda report > propagation protocols adopted by AD. I believe that would be > a considerable > improvement without requiring any substantial change to either the > requirements or architecture and especially beneficial to the > existing URP > design as there is a lot of avoidable complication there > simply because > reports are propagated out of sequence by each replica. [Steve] Propagating the changes strictly in CSN order wouldn't make much difference. The "complexity" arises from the requirement to process local changes out of order with updates reported by other replicas. Whether those remote changes are reported in order becomes irrelevant. > > That is completely independent of the issue of atomicity. > [Albert] Well, if you believe that all the complex "Extraordinary States" and "Transient Extraordinary States" are inherent in URP and cannot be removed, I'm not going to argue. I certainly agree that the central problem for any replication protocol arises from changes arriving out of order from different replicas rather than from reports being re-ordered when propagated. But that is simply because the former is unavoidable, while the latter can be easily avoided by simply forwarding them in the same order that they are received - as specified in MDCR, based on the work done for Coda and implemented in Active Directory. Propagation in order of receipt ensures that the MDCR "seenMarks" corresponding to the URP "purge vectors" can accurately reflect the fact that *all* prior change reports to those listed have been propagated. Purging cannot occur until *after* that has occurred. This guarantees that when DSAs crash and get restored from backups etc only the delay for "durability" of changes at other replicas, and not the integrity of the replication itself is affected. 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. What 4.5.3 of the architecture draft *should* have added is "Consequently we are not relying on timestamps but giving priority to version numbers". > [RM] > 2. The whole "weeding and summarizing" discussion left me > confused and therefore worried. There seems to be an > unstated assumption that all replicas are "well-connected". > My concern is that if one or more replicas are > "sporadically-connected" then the size of the trees could > become an issue. Again, I may be missing something in the > draft, but if so, I'd claim it is buried. Because the > whole discussion left me confused, I think some clarification > in the form of an example would help. > > Ryan > > [AL] If the WG accepts the draft as being on its agenda for > discussion I > think a lot more work will be needed on it, including > detailed examples (and > diagrams) for the weeding and summarizing process as you suggest. [Steven] I too have some concerns about the "weeding and summarizing" stuff. In particular it is not possible to guarantee that all replicas will converge toward the same state. A version of an entry cannot be made "Durable" until after some unspecified delay to see if any higher version shows up. For an entry version to become the definitive (durable) version depends not only on earlier events but also on events that are yet to occur! If the waiting time is chosen badly the replicas will quickly diverge. No matter what delay is chosen there is always a chance that a higher version will pop up immediately afterward. [Albert] Partly true, except that the replicas will not diverge because all reports are still propagated to all replicas and will be treated identically at all of them. MDCR makes use of the "seenMarks" to determine the propagation time to all other replicas. As I mentioned in the draft, a formula does need to be specified as to how to calculate what additional time should be allowed, and that formula needs to leave a generous margin. But all that is necessary is to specify, for all replicas in a replication area, a sufficiently generous margin. Any stragglers that do arrive would still have higher version numbers and could just be applied to ensure eventual convergence while not maintaining the guarantee of conflict detection and resolution, ie it would behave as badly as URP but only for stragglers instead of always. Alternatively, more complex provisions could be added. Details should be left until MDCR is actually on the agenda, but I would prefer to simply mark stragglers for manual fixup, like modifyDN, create and add conflicts, as the numbers should be negligible. This is VERY different from requiring manual fixups whenever clocks go out of sync, or DSAs crash and get restored from backups, which they do all the time. [...] > URP makes the fatal mistake of splitting > the operations > into primitives so as to effectively merge conflicts instead > of resolve > them, and adds the serious mistake of giving higher priority > to timestamps > than to version numbers. [Steven] The LDUP CSNs can be used either way. URP doesn't care, it just sees a monotonically increasing value. [Albert] Agreed. That is why I distinguished it from what I regard as the fatal mistake re atomicity. It is not in any way essential to the design of URP that it rely on timestamps instead of giving priority to version numbers, or that replicas be allowed to propagate reports out of order. This defect that would otherwise result in eventual divergence can easily be fixed by simply adopting the Coda based report propagation protocols suggested in MDCR while retaining the essence of the URP design. So why not just fix it? From owner-ietf-ldup@mail.imc.org Mon Jul 17 22:40:50 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 WAA29210 for ; Mon, 17 Jul 2000 22:40:49 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id TAA06510 for ietf-ldup-bks; Mon, 17 Jul 2000 19:11:03 -0700 (PDT) Received: from aspams52.cai.com (aspams52.cai.com [155.35.248.76]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA06502 for ; Mon, 17 Jul 2000 19:11:01 -0700 (PDT) Received: by aspams52.cai.com with Internet Mail Service (5.5.2650.21) id <3X7A0W6J>; Tue, 18 Jul 2000 12:13:02 +1000 Message-ID: <11981F9F5649D411BC92009027D0D18C657668@aspams01.cai.com> From: "Ramsay, Ron" To: Albert.Langer@directory-designs.org, steven.legg@adacel.com.au Cc: ietf-ldup@imc.org Subject: RE: 5. "Oscillation" Date: Tue, 18 Jul 2000 12:13:03 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Albert, I don't accept your proof. My eyes are URP-glazed but I think you proof fails from common sense alone. Your proof depends on ordering of CSNs, as if they can be ordered. Yet, presumably, the CSNs are originated by the source. They will, therefore, be capable of ordering in general, but clashes may occur. To construct a counter-example, you will probably set the CSNs to all the changes to be the same, say 7. Of course, mostly the CSNs will be different and this will produce a deterministic result. Semantically, it feels odd as the server with the highest CSNs will, in effect, arbitrate the result. Ron. -----Original Message----- From: Albert Langer [mailto:Albert.Langer@directory-designs.org] Sent: Tuesday, 18 July 2000 10:20 To: steven.legg@adacel.com.au Cc: ietf-ldup@imc.org Subject: 5. "Oscillation" Steve, Here's the response to item 5, which I summarized as: *** 5. "Oscillation". Implicit agreement that no protocol should oscillate. No need to state in requirements as both obvious and covered by 4 above. Steve says he has an example showing that MDCR oscillates. I say that neither MDCR nor URP oscillates. Unfortunately the margin of this email is too small for the proof ;-) Fortunately it is short enough to present in another email rather than leaving the world waiting breathlessly for hundreds of years... or subjecting it to eyeglazing discussion of examples. http://www.imc.org/ietf-ldup/mail-archive/msg00614.html *** Comments follow original below. *** [Steven] Also, I can also construct examples where two replicas endlessly flip back and forth between two competing strands with no entry versions ever becoming durable. > A simpler approach to conflict resolution would just resolve > each conflict > immediately, at each DUA that encounters a conflicting change, by > suppressing the change with the lower version number etc and > propagating > only 1 survivor (which may itself be suppressed at another > DUA with the > survivor propagated from that conflict in turn reaching the > previous DUA and > suppressing the previous survivor there). I don't think this is enough to solve the problems mentioned above. [Albert] Well, all you need to do is exhibit just one of those examples and I am sure everyone, including me, will agree that MDCR is unacceptable. I found the discussions of various examples of URP failures when wading through the archives quite eyeglazing, so I can sympathize with your reluctance to spark another such discussion. 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. Consider a finite set of N replicas and a finite set of changes applied to a single entry at some or all of those replicas within a finite time interval. 1. There is a finite set of CSNs resulting from the original entries and the changed entries that result, and a one to one association between the CSN of an entry at a replica and the state of that entry at that replica. 2. This finite set of CSNs is strictly ordered and imposes a corresponding strict ordering on entry states. Exactly one entry state corresponds to the highest CSN in that strict ordering. 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). 4. Therefore all entries will converge to the same state. There may be a combinatorial explosion of transient states and some of them may be "Transient Extraordinary States", but URP *will* converge to some common state, which may be regular or "Extraordinary" depending on factors beyond the scope of this analysis (and possibly any other). If you accept that proof as showing URP converges you should accept that the same proof shows MDCR converges, as you have agreed that CSNs and USNs are similar strict (lexical) orderings. The only differences are: a) In para 3, MDCR propagates all changes to all replicas whether they immediately replace the current entry there or not. It is slightly more obvious, though no more true, that the change with the highest USN will be propagated to all replicas, and therefore will become the convergent entry at all replicas. b) The number of visible entry states (and of tree history states) at different replicas is never greater than the number of actual changes that were made concurrently at different replicas. With MDCR there are no new "transient" states and no combinatorial explosion. c) The final result is completely predictable and never "Extraordinary". From owner-ietf-ldup@mail.imc.org Tue Jul 18 04:56:14 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 EAA10856 for ; Tue, 18 Jul 2000 04:56:13 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id BAA00718 for ietf-ldup-bks; Tue, 18 Jul 2000 01:20:51 -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 BAA00714 for ; Tue, 18 Jul 2000 01:20:49 -0700 (PDT) Received: (qmail 19506 invoked from network); 18 Jul 2000 08:18:28 -0000 Received: from cpe-144-132-68-23.vic.bigpond.net.au (HELO w98sysrec) (144.132.68.23) by relay1.pair.com with SMTP; 18 Jul 2000 08:18:28 -0000 X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: "'Ramsay, Ron'" , Cc: Subject: RE: 5. "Oscillation" Date: Tue, 18 Jul 2000 18:20:18 +1000 Message-ID: <000401bff091$4f07d220$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: <11981F9F5649D411BC92009027D0D18C657668@aspams01.cai.com> Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [Ron] I don't accept your proof. My eyes are URP-glazed but I think you proof fails from common sense alone. Your proof depends on ordering of CSNs, as if they can be ordered. Yet, presumably, the CSNs are originated by the source. They will, therefore, be capable of ordering in general, but clashes may occur. To construct a counter-example, you will probably set the CSNs to all the changes to be the same, say 7. Of course, mostly the CSNs will be different and this will produce a deterministic result. Semantically, it feels odd as the server with the highest CSNs will, in effect, arbitrate the result. [Albert] The URP CSN is defined with four components as specified in the architecture draft, 4.5.1: "In order of significance they are; the time, a change count, a Replica Identifier, and a modification number. The CSN is composed thus to ensure the uniqueness of every generated CSN." I believe that clearly does ensure the uniqueness of every generated CSN as intended. The three components time, change count and modification number ensure uniqueness within a replica, and the remaining component, replica identifuer, ensures global uniqueness within the replication set. Therefore no counter-example could be based on CSNs for different changes having the same value. 4.5.1 continues: "When CSNs are compared to determine their ordering, they are compared component by component. First the time, then the change count, then the replica identifier, and finally the modification number." This does establish a strict ordering of CSNs. Whenever the other 3 components of two CSNs generated at different replicas happen to have the same time, change count and modification number, the result is arbitrarily determined by the replica with the highest replica identifier. I agree that "feels odd", but it does guarantee convergence. In my view it is a clumsy and confusing way to do it, but that isn't worth arguing about at this late stage, as long as it does do it. The "change count" is really an internal implementation detail for coordinating multiple threads within a DSA, and need not be carried by protocol at all. MDCR just uses the timestamp plus version number to guarantee uniqueness of USNs generated by a DSA (for a single entryID). The difference is simply that URP gives priority in the lexical ordering to the combined timestamp represented by the time and change count, while MDCR gives priority to the version number. Both apply the last component, replica identifier in the same way to guarantee uniqueness among all DSAs and arbitrarily impose a strict ordering. However MDCR applies this only as a last resort and treats the version number as the principal determinant of priority among concurrent changes. In practice the fact that URP applies that arbitrary last resort slightly earlier does not really matter as the whole ordering is arbitrary anyway and the remaining three components will almost always be unique. The precise ordering of timestamps generated for concurrent changes at different replicas is inherently arbitrary as clocks are not synchronized. All it creates is the *illusion* of time ordering. The reality is that changes are concurrent, not serialized, when made at different replicas to the same entry state. It doesn't really matter which change succeeds as long as no more than one of them does. This seems a good point to mention a significant advantage of the Coda/Active Directory method of using version numbers as the primary determinant of priority for resolving conflicts among concurrent changes. Typically, concurrent changes will have different timestamps. The fact that occasionally they will have identical timestamps is focussed on by URP, thus distracting attention from the fact that they are still concurrent, not serialized, whether they have the same timestamp or not. The simple fact is that each concurrent change was made without knowledge of the state resulting from the other(s). MDCR makes this explicit by recognizing concurrency whenever the version numbers are different (or are the same but generated at different replicas, hence the need for a tree). A consequence is that regardless of timestamps, the final state of an entry that is changed more frequently at a particular replica during a conflict will ultimately prevail over conflicting changes made at other replicas. Typically a conflict will simply occur between just two changes made at two different replicas and MDCR will arbitrarily converge to the change made by the replica with the highest replica number, regardless of timestamps. But on the rare occasions when there is a non-trivial tree of conflicts, because additional changes have been applied to the visible changed entries at a replica before they become "durable", MDCR will recognize this and give priority to the longest possible sequence of changes that could have been serialized. For example if two successive changes are made to a single replica at A, while a concurrent single change is made at B, the result will converge to the final state represented by the second change at A. This is more significant than it seems. The entries that are being changed most often are those being actively worked on. If an application is trying to coordinate a transaction by first setting some sort of transaction identifier on all the related entries, then changing them and all and coming back to finalize the transaction, it is more likely to ultimately succeed and become durable, than a conflicting single change made by another DUA that is not part of a transaction. Although the main point is to ensure that conflicts are actually resolved, not merged. This is a significant optimization of the resolution. The Coda research has full details. From owner-ietf-ldup@mail.imc.org Tue Jul 18 07:54:51 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 HAA13281 for ; Tue, 18 Jul 2000 07:54:51 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id EAA11296 for ietf-ldup-bks; Tue, 18 Jul 2000 04:16: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 EAA11291 for ; Tue, 18 Jul 2000 04:16:02 -0700 (PDT) Received: (qmail 18265 invoked from network); 18 Jul 2000 11:13:41 -0000 Received: from cpe-144-132-68-23.vic.bigpond.net.au (HELO w98sysrec) (144.132.68.23) by relay1.pair.com with SMTP; 18 Jul 2000 11:13:41 -0000 X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: Cc: Subject: 3. "Change Reports - ProtocolOps or Primitives" Date: Tue, 18 Jul 2000 21:17:42 +1000 Message-ID: <000501bff0a9$cabebba0$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: <001701bff02f$f74e5ba0$17448490@vic.bigpond.net.au> Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Steve, I didn't really understand what you are getting at on this, so it might be best to restate what point you were actually making afresh. Nevertheless, here's my response to item 4, which I summarized as: 3. "Change Reports - ProtocolOps or Primitives". Reference by Steve to non-LDAP and non-X500 replicating servers may involve clarification of requirements. Other issues can be clarified in discussion of URP and MDCR approaches. http://www.imc.org/ietf-ldup/mail-archive/msg00614.html *** Comments follow the original below. *** [AL responding to Ryan] > As regards efficient propagation of the tree via the report > propagation > protocol I believe the encoding on the wire is as efficient > and as simple as > possible by just conveying the actual LDAP protocolOps for > the changes. The > only redundancy is for the relatively small proportion of changes that > affect the Directory Information Tree (DIT), ie add, del and modifyDN, > rather than just the Directory Information Base (DIT), ie modify (for > changes to non-distinguished attributes and values). [Steven] The replicating servers aren't necessarily LDAP or X.500 DSAs, so the update protocol operations aren't necessarily just LDAP, DAP or DSP operations. Also, these protocols are still subject to change so additional operations may be defined in the future, or existing ones extended. LDAP also has a means for vendors to define proprietary operations. We can't expect LDUP implementors to cover all the possibilities. The original request also doesn't carry the changes to operational attributes or other vendor specific DSA invoked changes such as might occur to maintain referential integrity of DNs. Breaking all update requests into replication primitives gets around these problems. [snip] [Albert] I do not understand what problems you are referring to or how breaking all update requests into primitives gets around them. My understanding was and is that URP breaking all update requests into primitives is intended to get around the problem that modify operations to the same entry made concurrently at different replicas cannot all succeed as a whole (ie "atomically"). URP breaks up the whole operation into its constituent primitive elements so that they can be merged or "reconciled" independently regardless of any conflict between them. When more than one operation includes a primitive element that changes the same single valued attribute, only the primitive element that happens to have the highest timestamp will succeed. But if they change different attributes, or add or delete different values to the same attribute, they can all succeed. Please confirm whether that understanding is correct, or explain why it is not. Conversely, MDCR aims to ensure that each operation can only succeed or fail as a whole, so it has no need to break it up into "primitives". I was replying to Ryan raising an issue which I took to be about the efficiency of protocol encoding on the wire, but may not have been. My point was that both MDCR and URP carry essentially the same information, although they treat that information differently ("atomically" vs splitting the atom). Now you *seem* to be saying that the use of primitives enables URP to convey additional protocol information for proprietary non-LDAP and non-X500 directories, which could not be conveyed by MDCR. I do not see any provision for this in URP and I do not think any such provision is desirable. It could easily be added to both if it was desirable. If there is any thought of doing so, I think a clear statement should be added to the requirements document explicitly ruling this out, as such additions would guarantee incompatability between different implementations. 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. If so, I agree. My intention in the MDCR draft was that the encoding should correspond to a canonicalized "protocolOp" that could have been received from an LDAP DUA as specified in the LDAP RFCs - explicitly excluding any "controls". I did not mean to imply that it would always be a verbatim copy of such a protocolOp (although many implementations will be simplified by being able to do that). The "protocolOp" ASN specified in the RFCs includes all the information required by URP except the entryID, which MDCR also carries separately. Thus MDCR does not omit any information used by URP. The (marginally) greater efficiency of MDCR "on the wire" results simply from not repeating the entryID etc for every attribute value that is changed by a single modify operation. MDCR just transmits this once for each modify operation and also saves other overhead from multiple protocol elements for a single operation (both "on the wire" and when processing the protocol). 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. Finally, in relation to the original point re efficiency on the wire, I should mention that I said MDCR is only "marginally" more efficient than URP because the really significant overhead is per replication session, (for authentication, synchronization etc) not per item within a replication session. MDCR also carries the full DN of each modify operation within the protocolOp, which is not strictly necessary for the current draft (00), and could be omitted as URP does, if the number of bytes was a dominant concern. However I believe it will be necessary for dealing with potential conflicts between replication of prescriptive ACI information applying to an entry and changes to the entry. I do not believe URP is capable of addressing that at all. Also, MDCR always propagates every change report to every replica, whether or not it results in a visible change, whereas URP does not propagate a primitive further, once it has encountered another for the same attribute value with a higher CSN. This is important for explaining the difference in predicability etc of the two alternatives, but not a significant difference in efficiency "on the wire". In practice most changes are not made concurrently to the same entry, and for the small proportion that are, those with earlier CSNs will usually have propagated further than those with later CSNs, which will therefore be catching up with them rather than preventing their further propagation. From owner-ietf-ldup@mail.imc.org Tue Jul 18 19:17:33 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 TAA11309 for ; Tue, 18 Jul 2000 19:17:32 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA10153 for ietf-ldup-bks; Tue, 18 Jul 2000 15:42:55 -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 PAA10147 for ; Tue, 18 Jul 2000 15:42:53 -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 WAA32692; Tue, 18 Jul 2000 22:44:57 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <4.3.2.7.0.20000718143734.00b164a0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 18 Jul 2000 15:44:56 -0700 To: IETF-LDAPbis@OpenLDAP.org, agenda@ietf.org From: "Kurt D. Zeilenga" Subject: LDAP (v3) Revision BOF (LDAPbis) Cc: IETF-LDAPext@netscape.com, IETF-LDUP@imc.org, IETF@ietf.org 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: This is the final IETF#48 LDAPbis BOF agenda. Those interested are encouraged to attend. Regards, Kurt --- cut here --- NAME: LDAP (v3) Revision BOF ACRONYM: LDAPbis CHAIRS: Kurt Zeilenga RL "Bob" Morgan MAILING LIST: Archives: http://www.openldap.org/lists/ietf-ldapbis/ Subscribe: mailto:ietf-ldapbis-request@OpenLDAP.org?body=subscribe Post: mailto:ietf-ldapbis@OpenLDAP.org Policy: You must be subscribed to post. INTRODUCTION: LDAPv3 core specifications (RFC 2251-56) must be revised if they are to be progressed to Draft Standard per the IESG Note contained within these documents. With the approval of RFC 2829 and 2830, the necessary secure authentication mechanisms to obtain Draft Standard status are now available. In addition, the community has obtain a wealth of operational experience using the current specifications. The community has identified a number of areas where the specifications need to amended. These amendments include a few significant substantive changes, a fair number of lessor substantive changes, and many clarifications. A forum for discussing and addressing these issues is needed. PURPOSE: The purpose of this BOF is to discuss proposed updates to the LDAPv3 core protocol specification (RFC 2251-56, 2829-30), to identify work items, and discuss formation of a working group specifically chartered to address identified work items. Extensions to LDAPv3 are not within the scope of this BOF as this is the realm of existing IETF working groups. BACKGROUND: The LDAPv3 specifications were developed by the ASID and LDAPext working groups. The ASID working group is defunct. The LDAPext WG is focused on significant protocol extensions such as Access Control, APIs, Referrals, and CLDAP. A separate working group is currently proposed to focus energies to address LDAPv3 specification updates while not distracting LDAPext from their chartered work. However, at the discretion of the IESG, work items identified by this BOF may be assigned to LDAPext or other appropriate WG (after appropriate charter review). TIME/PLACE: WEDNESDAY, August 2, 2000, 1530-1730 AGENDA: Agenda Bashing Introduction, Chair(s), 10m Extent of suggested changes LDAPv3 vs LDAPv4 IESG Note, AD, 5m LDAPv3 Applicability Statement, JeffH, 10m Relationship to X.500, MarkW, 10m Reorganisation of the Specification, MarkW, 5m Other Issues, TBD, 10m Next Steps, Chair(s), 10m I-D Review (as time permits), Author(s), 1hr (5m/I-D) Order to be determined by chair(s) READING MATERIALS: RFC 2251-2256,2829,2830 draft-armijo-ldap-control-error-00.txt draft-hodges-ldapv3-as-00.txt draft-just-ldapv3-rescodes-02.txt draft-rharrison-ldap-extpartresp-01.txt draft-smith-ldapv3-dn-update-00.txt draft-smith-ldapv3-url-update-00.txt draft-zeilenga-ldapv3bis-opattrs.txt draft-zeilenga-ldapv3bis-rfc2251.txt draft-zeilenga-ldapv3bis-rfc2252.txt draft-zeilenga-ldapv3bis-rfc2253.txt draft-zeilenga-ldapv3bis-rfc2254.txt draft-zeilenga-ldapv3bis-rfc2255.txt draft-zeilenga-ldapv3bis-rfc2256.txt draft-zeilenga-ldapv3bis-rfc2829.txt draft-zeilenga-ldapv3bis-rfc2830.txt From owner-ietf-ldup@mail.imc.org Wed Jul 19 01:07: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 BAA29044 for ; Wed, 19 Jul 2000 01:07:55 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id VAA00385 for ietf-ldup-bks; Tue, 18 Jul 2000 21:29:25 -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 VAA00371 for ; Tue, 18 Jul 2000 21:29:17 -0700 (PDT) Received: (qmail 13883 invoked from network); 19 Jul 2000 04:31:42 -0000 Received: from softdnserror (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 19 Jul 2000 04:31:42 -0000 Reply-To: From: "Steven Legg" To: Cc: Subject: RE: 5. "Oscillation" Date: Wed, 19 Jul 2000 14:34:28 +1000 Message-ID: <001001bff13a$a1012ff0$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 Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V4.72.2120.0 In-Reply-To: <001b01bff04d$fc9f2760$17448490@vic.bigpond.net.au> 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: Tuesday, 18 July 2000 10:20 > To: steven.legg@adacel.com.au > Cc: ietf-ldup@imc.org > Subject: 5. "Oscillation" > > > Steve, > > Here's the response to item 5, which I summarized as: > > *** > 5. "Oscillation". Implicit agreement that no protocol should > oscillate. No > need to state in requirements as both obvious and covered by > 4 above. Steve > says he has an example showing that MDCR oscillates. I say > that neither MDCR > nor URP oscillates. Unfortunately the margin of this email is > too small for > the proof ;-) Fortunately it is short enough to present in > another email > rather than leaving the world waiting breathlessly for > hundreds of years... > or subjecting it to eyeglazing discussion of examples. > > http://www.imc.org/ietf-ldup/mail-archive/msg00614.html > > *** > Comments follow original below. > *** > > [Steven] > Also, I can also construct examples where two replicas endlessly flip > back and forth between two competing strands with no entry > versions ever > becoming durable. > > > A simpler approach to conflict resolution would just resolve > > each conflict > > immediately, at each DUA that encounters a conflicting change, by > > suppressing the change with the lower version number etc and > > propagating > > only 1 survivor (which may itself be suppressed at another > > DUA with the > > survivor propagated from that conflict in turn reaching the > > previous DUA and > > suppressing the previous survivor there). > > I don't think this is enough to solve the problems mentioned above. > > [Albert] > Well, all you need to do is exhibit just one of those > examples and I am sure > everyone, including me, will agree that MDCR is unacceptable. Okay. 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. I'm using the tuple (version, originator, previous) to identify a record in the tree of changes to an entry. Let's assume that E already exists and that the root of the changes tree is identified as (1, R1, -) for both replicas. At time 0:15, E is changed at R1. This creates a new change record (2, R1, R1). At time 0:30, R2 sends unreported changes to R1. At this time it is an empty set so nothing interesting happens. At time 0:45, E is changed at R2. This creates a new record (2, R2, R1). At time 1:00, R1 sends changes to R2, i.e. (2, R1, R1). Since (2, R2, R1) has a higher modify timestamp and R2 > R1, R2 doesn't alter its current version of E. At time 1:15, E is changed at R1. This creates a new record (3, R1, R1). At time 1:30, R2 sends changes to R1, i.e. (2, R2, R1). Since (3, R1, R1) has the highest version number, R1 doesn't alter its current version of E. At time 1:45, E is changed at R2. This creates a new record (3, R2, R2). At time 2:00, R1 sends changes to R2, i.e. (3, R1, R1). Since (3, R2, R2) has a higher modify timestamp and R2 > R1, R2 doesn't alter its current version of E. ... 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. > > I found the discussions of various examples of URP failures > when wading > through the archives quite eyeglazing, so I can sympathize with your > reluctance to spark another such discussion. > > 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. > > Consider a finite set of N replicas and a finite set of > changes applied to a > single entry at some or all of those replicas within a finite > time interval. > > 1. There is a finite set of CSNs resulting from the original > entries and the > changed entries that result, and a one to one association > between the CSN of > an entry at a replica and the state of that entry at that replica. > > 2. This finite set of CSNs is strictly ordered and imposes a > corresponding > strict ordering on entry states. Exactly one entry state > corresponds to the > highest CSN in that strict ordering. > > 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). > > 4. Therefore all entries will converge to the same state. > > There may be a combinatorial explosion of transient states > and some of them > may be "Transient Extraordinary States", but URP *will* > converge to some > common state, which may be regular or "Extraordinary" > depending on factors > beyond the scope of this analysis (and possibly any other). > > If you accept that proof as showing URP converges you should > accept that the > same proof shows MDCR converges, as you have agreed that > CSNs and USNs are > similar strict (lexical) orderings. 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. Regards, Steven > > The only differences are: > > a) In para 3, MDCR propagates all changes to all replicas whether they > immediately replace the current entry there or not. It is > slightly more > obvious, though no more true, that the change with the > highest USN will be > propagated to all replicas, and therefore will become the > convergent entry > at all replicas. > > b) The number of visible entry states (and of tree history states) at > different replicas is never greater than the number of actual > changes that > were made concurrently at different replicas. With MDCR there > are no new > "transient" states and no combinatorial explosion. > > c) The final result is completely predictable and never > "Extraordinary". > > From owner-ietf-ldup@mail.imc.org Wed Jul 19 04:19: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 EAA04711 for ; Wed, 19 Jul 2000 04:19:01 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id AAA10038 for ietf-ldup-bks; Wed, 19 Jul 2000 00:42:34 -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 AAA10026 for ; Wed, 19 Jul 2000 00:42:26 -0700 (PDT) Received: (qmail 23075 invoked from network); 19 Jul 2000 07:44:55 -0000 Received: from softdnserror (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 19 Jul 2000 07:44:55 -0000 Reply-To: From: "Steven Legg" To: Cc: Subject: RE: 3. "Change Reports - ProtocolOps or Primitives" Date: Wed, 19 Jul 2000 17:47:41 +1000 Message-ID: <001701bff155$9f3a5e60$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 Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V4.72.2120.0 In-Reply-To: <000501bff0a9$cabebba0$17448490@vic.bigpond.net.au> 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: Tuesday, 18 July 2000 21:18 > To: steven.legg@adacel.com.au > Cc: ietf-ldup@imc.org > Subject: 3. "Change Reports - ProtocolOps or Primitives" > > > Steve, > > I didn't really understand what you are getting at on this, > so it might be > best to restate what point you were actually making afresh. > > Nevertheless, here's my response to item 4, which I summarized as: > > 3. "Change Reports - ProtocolOps or Primitives". Reference by Steve to > non-LDAP and non-X500 replicating servers may involve clarification of > requirements. Other issues can be clarified in discussion of > URP and MDCR > approaches. > > > http://www.imc.org/ietf-ldup/mail-archive/msg00614.html > > *** > Comments follow the original below. > *** > > [AL responding to Ryan] > > As regards efficient propagation of the tree via the report > > propagation > > protocol I believe the encoding on the wire is as efficient > > and as simple as > > possible by just conveying the actual LDAP protocolOps for > > the changes. The > > only redundancy is for the relatively small proportion of > changes that > > affect the Directory Information Tree (DIT), ie add, del > and modifyDN, > > rather than just the Directory Information Base (DIT), ie > modify (for > > changes to non-distinguished attributes and values). > > [Steven] > The replicating servers aren't necessarily LDAP or X.500 > DSAs, so the update > protocol operations aren't necessarily just LDAP, DAP or DSP > operations. > Also, these protocols are still subject to change so > additional operations > may be defined in the future, or existing ones extended. LDAP also has > a means for vendors to define proprietary operations. We > can't expect LDUP > implementors to cover all the possibilities. > > The original request also doesn't carry the changes to operational > attributes or other vendor specific DSA invoked changes such as might > occur to maintain referential integrity of DNs. > > Breaking all update requests into replication primitives gets > around these > problems. Perhaps I should have said: Breaking all update requests into replication primitives for conveying changes in the LDUP protocol (instead of using the original protocolOp) gets around these problems. > [snip] > > [Albert] > I do not understand what problems you are referring to or how > breaking all > update requests into primitives gets around them. 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. > My understanding was and is that URP breaking all update requests into > primitives is intended to get around the problem that modify > operations to > the same entry made concurrently at different replicas cannot > all succeed as > a whole (ie "atomically"). URP breaks up the whole operation into its > constituent primitive elements so that they can be merged or > "reconciled" > independently regardless of any conflict between them. When > more than one > operation includes a primitive element that changes the same > single valued > attribute, only the primitive element that happens to have the highest > timestamp will succeed. But if they change different > attributes, or add or > delete different values to the same attribute, they can all succeed. > > Please confirm whether that understanding is correct, or > explain why it is > not. 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. > > Conversely, MDCR aims to ensure that each operation can only > succeed or fail > as a whole, so it has no need to break it up into "primitives". > > I was replying to Ryan raising an issue which I took to be about the > efficiency of protocol encoding on the wire, but may not have > been. My point > was that both MDCR and URP carry essentially the same > information, although > they treat that information differently ("atomically" vs splitting the > atom). > > Now you *seem* to be saying that the use of primitives > enables URP to convey > additional protocol information for proprietary non-LDAP and non-X500 > directories, which could not be conveyed by MDCR. The use of primitives allows the *LDUP protocol* to convey the additional information. > I do not > see any provision > for this in URP and I do not think any such provision is > desirable. The latest version of the URP document explicitly talks about what to do with non-LDAP/X.500 update operations. > It could > easily be added to both if it was desirable. The LDUP protocol and URP don't need to change to accommodate other types of update operations. > > If there is any thought of doing so, I think a clear > statement should be > added to the requirements document explicitly ruling this out, as such > additions would guarantee incompatability between different > implementations. It's the reality now, there's no chance of it being ruled out, and it's not a problem for the current LDUP design. > > 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. That's what I was saying. > > If so, I agree. My intention in the MDCR draft was that the > encoding should > correspond to a canonicalized "protocolOp" that could have > been received > from an LDAP DUA as specified in the LDAP RFCs - explicitly > excluding any > "controls". I did not mean to imply that it would always be a > verbatim copy > of such a protocolOp (although many implementations will be > simplified by > being able to do that). The "protocolOp" ASN specified in the > RFCs includes > all the information required by URP except the entryID, which > MDCR also > carries separately. Thus MDCR does not omit any information > used by URP. 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. > > The (marginally) greater efficiency of MDCR "on the wire" > results simply > from not repeating the entryID etc for every attribute value > that is changed > by a single modify operation. MDCR just transmits this once > for each modify > operation and also saves other overhead from multiple > protocol elements for > a single operation (both "on the wire" and when processing > the protocol). 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. > > 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 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. > > Finally, in relation to the original point re efficiency on > the wire, I > should mention that I said MDCR is only "marginally" more > efficient than URP > because the really significant overhead is per replication > session, (for > authentication, synchronization etc) not per item within a replication > session. MDCR also carries the full DN of each modify > operation within the > protocolOp, which is not strictly necessary for the current > draft (00), and > could be omitted as URP does, if the number of bytes was a > dominant concern. > However I believe it will be necessary for dealing with > potential conflicts > between replication of prescriptive ACI information applying > to an entry and > changes to the entry. I do not believe URP is capable of > addressing that at > all. It's not obvious to me what sort of conflicts you are talking about. Changes to prescriptive ACIs are much rarer than changes to entries and unlikely to be directly linked. If there is a concern then wouldn't MDCR be in bigger trouble because it is liable to completely discard one of the linked changes ? Merging has fewer failure modes. Regards, Steven > > Also, MDCR always propagates every change report to every > replica, whether > or not it results in a visible change, whereas URP does not > propagate a > primitive further, once it has encountered another for the > same attribute > value with a higher CSN. This is important for explaining the > difference in > predicability etc of the two alternatives, but not a > significant difference > in efficiency "on the wire". In practice most changes are not made > concurrently to the same entry, and for the small proportion > that are, those > with earlier CSNs will usually have propagated further than > those with later > CSNs, which will therefore be catching up with them rather > than preventing > their further propagation. > > From owner-ietf-ldup@mail.imc.org Thu Jul 20 09:24: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 JAA03153 for ; Thu, 20 Jul 2000 09:24:10 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id FAA19317 for ietf-ldup-bks; Thu, 20 Jul 2000 05:51:57 -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 FAA19312 for ; Thu, 20 Jul 2000 05:51:56 -0700 (PDT) Received: (qmail 12570 invoked from network); 20 Jul 2000 12:49:38 -0000 Received: from cpe-144-132-68-23.vic.bigpond.net.au (HELO w98sysrec) (144.132.68.23) by relay1.pair.com with SMTP; 20 Jul 2000 12:49:38 -0000 X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: Cc: Subject: 9. "Replication of ACI changes" Date: Thu, 20 Jul 2000 22:53:46 +1000 Message-ID: <000901bff249$8b799a40$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: <001701bff155$9f3a5e60$b05508cb@osmium.adacel.com.au> 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 Steve, I am deferring responses to your replies on items 3 and 5 for now, while catching up with the rest of my original list: Done 3,4,5 and 8 so 1,2,6 and 7 still to go. However I am also starting a separate thread 9 on this issue as it doesn't really belong with item 3 and should be dealt with fully. Hoping you can kick off the discussion. At the end of my item 3 I mentioned in passing that: > MDCR also carries the full DN of each modify > operation within the > protocolOp, which is not strictly necessary for the current > draft (00), and > could be omitted as URP does, if the number of bytes was a > dominant concern. > However I believe it will be necessary for dealing with > potential conflicts > between replication of prescriptive ACI information applying > to an entry and > changes to the entry. I do not believe URP is capable of > addressing that at > all. You responded briefly: [Steve] It's not obvious to me what sort of conflicts you are talking about. Changes to prescriptive ACIs are much rarer than changes to entries and unlikely to be directly linked. If there is a concern then wouldn't MDCR be in bigger trouble because it is liable to completely discard one of the linked changes ? Merging has fewer failure modes. [Albert] The sort of conflicts I was thinking about and preparing for, but did not attempt to explain, and have not dealt with in my draft, (nor you in yours), relate to the interaction between concurrent changes to any entry affected by changes to prescriptive ACI applicable to entries depending on what the entry's DN actually is (ie whether or not it is actually in a particular subtree or subtree refinement regardless of its UUID). I do not think any solution should attempt to directly link the changes. It is not obvious to me either, as to exactly what problems there might be - but those are the sort of problems I worry about most, as potential problems that are clear are easily dealt with ;-0 Anyway, it is even less obvious what the solutions to unobvious problems might require, so I didn't want to throw DN away and propagate only entryID. As you know I have not proposed an alternative to URP's basic approach for dealing with modifyDN, create and delete operations, but only for modify operations, since your approach to the former does maintain atomicity. I have suggested to both of you (via email twice to Alison with no reply) that we get together again face to face over at least ACI issues, as we are all in Melbourne. I'd still welcome that if you are interested. Meanwhile, on the simpler issue of just replicating ACI *at all*, I believe that MDCR behaves correctly by accepting only one change at a time, and that the consequences of non-atomicity in URP are vividly illustrated by considering its impact on simple ACI replication. Could you please elaborate on your remark that "merging has fewer failure modes", in this simpler context, with particular reference to the scenarios that could result from merging concurrent changes to different ACI attributes and attribute values as currently proposed in: http://search.ietf.org/internet-drafts/draft-ietf-ldapext-acl-model-06.txt (BTW as already mentioned I agree with your remark that the number of bytes is really a "non-issue"). From owner-ietf-ldup@mail.imc.org Thu Jul 20 10:04:12 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 KAA26369 for ; Thu, 20 Jul 2000 10:04:11 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA20939 for ietf-ldup-bks; Thu, 20 Jul 2000 06:33:00 -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 GAA20935 for ; Thu, 20 Jul 2000 06:32:58 -0700 (PDT) Received: (qmail 19120 invoked from network); 20 Jul 2000 13:30:45 -0000 Received: from cpe-144-132-68-23.vic.bigpond.net.au (HELO w98sysrec) (144.132.68.23) by relay1.pair.com with SMTP; 20 Jul 2000 13:30:45 -0000 X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: Cc: Subject: 6. "Implementation and Performance Issues" Date: Thu, 20 Jul 2000 23:34:54 +1000 Message-ID: <000a01bff24f$4a76c8a0$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: <001701bff02f$f74e5ba0$17448490@vic.bigpond.net.au> 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 Steve, Here's the response to item 6, which I summarized as: 6. "Implementation and Performance Issues". Disagreement as to whether there is any significant difference in implementation difficulty or performance. http://www.imc.org/ietf-ldup/mail-archive/msg00614.html *** Comments follow original below. *** > The tree is especially important for "sporadically-connected" > replicas since > they are the most likely to generate conflicts. In most cases > the tree would > be trivial or very small, but if it is not recognized as a tree, that > "simplification" makes everything else become incredibly complicated. > > I don't see a large tree as an implementation problem in itself - the > overhead is only about 12 bytes of RAM per conflicting change. [Steve] You would also need to store enough information to reconstruct the previous versions of an entry on each strand. To change the current entry version from one strand to another requires unwinding index changes, etc, back to the common branching point and then applying the saved change requests on the new strand. URP never has to go backwards. [Albert] Performance is dominated by the normal case of no concurrent changes. If concurrent changes are more than a small proportion of updates, the application is just not suitable for the Directory as configured. Concurrent changes are just an "unavoidable evil". Even if the mechanism for dealing with that "unavoidable evil" was highly inefficient, it would not have much effect on overall performance because it is rarely used - it is just there to avoid the far more inefficient alternative of manual intervention by system administrators. For that reason there is no significant difference in performance between MDCR and URP. When there is no conflict, the tree would be trivial and there would be no "going backwards". When there is conflict, for the same reasons, performance is dominated by the case of just 1 conflict. In that case "unwinding ... and then applying..." is exactly equivalent to replacing the original entry with the replacement, which happens to be precisely what URP does. The difference being that MDCR does it based on the actual conflict tree whereas URP uses roughly equivalent components of the lexical ordering to pretend that changes occurred on a linear time scale even though they did not. There is no difference in the complexity of actually implementing either ordering, just a greater level of abstraction required in visualizing the tree rather than succumbing to the illusion of sequential changes. In the very rare cases when there is more than one conflict with a longer single strand or a branching tree, MDCR actually has to do less work than URP because URP makes each change visible as it arrives and therefore has to update indexes (including "unwinding" indexes), whereas MDCR leaves some arriving changes invisible and stores them only in case they are needed later, so it does not have to update those indexes. MDCR does have to store every arriving change report, but this can simply be appending them to a log file, which can be very efficient for sequential seeks on a separate log disk spindle since not even random seeks for primary key indexing is required. Actual details are of course up to the implementation. Usually the log records would still be in RAM buffers if they need to be read back within a reasonably short replication latency, but would normally have to be written to disk for safety. The guesstimate of 12 bytes of RAM overhead per tree entry was based on a 32 bit (4 byte) version number, 2 x 16 bit replica number for up to 16K replicas per replicated area, and a 32 bit pointer into a log file up to 4GB long. Note that only these pointers are needed to maintain the shape of the tree in RAM, the actual contents of the changes required to unwind and wind forwards can be read back from the pointer into the log file. An implementation might choose to break down a switch from one part of the tree to another into "primitives" as you suggest, unwinding the index entries a step at a time and then rewinding them a step at a time. In this case that choice would not really matter as the frequency is negligible anyway. I would of course be more inclined to do it "atomically" ;-) as a single deletion of the currently visible entry and replacement by the new visible entry. In general I think implementing trees etc is not a big issue for software development. Unfortunately they are harder to describe in standards, which looks like a bigger problem at the moment. PS I will deal with your example of a long strand when returning to item 5. From owner-ietf-ldup@mail.imc.org Fri Jul 21 10:10: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 KAA14433 for ; Fri, 21 Jul 2000 10:10:06 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA28195 for ietf-ldup-bks; Fri, 21 Jul 2000 06:37:52 -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 GAA28191 for ; Fri, 21 Jul 2000 06:37:50 -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 JAA12848; Fri, 21 Jul 2000 09:40:29 -0400 (EDT) Message-Id: <200007211340.JAA12848@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-protocol-02.txt Date: Fri, 21 Jul 2000 09:40:29 -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 : The LDUP Replication Update Protocol Author(s) : E. Stokes, G. Good Filename : draft-ietf-ldup-protocol-02.txt Pages : 16 Date : 20-Jul-00 The protocol described in this document is designed to allow one LDAP server to replicate its directory content to another LDAP server. The protocol is designed to be used in a replication configuration where multiple updatable servers are present. Provisions are made in the protocol to carry information that allows the server receiving updates to apply a total ordering to all updates in the replicated system. This total ordering allows all replicas to correctly resolve conflicts that arise when LDAP clients submit changes to different servers that later replicate to one another. All protocol elements described here are LDAP Version 3 extended operations. LDAP Version 3 is described in RFC 2251 [LDAPv3]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-protocol-02.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-protocol-02.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-protocol-02.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: <20000720141907.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-protocol-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-protocol-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000720141907.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Fri Jul 21 13:15:54 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 NAA14584 for ; Fri, 21 Jul 2000 13:15:53 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA11751 for ietf-ldup-bks; Fri, 21 Jul 2000 09:45:31 -0700 (PDT) Received: from mta01-svc.ntlworld.com (mta01-svc.ntlworld.com [62.253.162.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11745 for ; Fri, 21 Jul 2000 09:45:23 -0700 (PDT) Received: from dwc-acer ([62.252.108.72]) by mta01-svc.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with ESMTP id <20000721164803.KOPQ26680.mta01-svc.ntlworld.com@dwc-acer> for ; Fri, 21 Jul 2000 17:48:03 +0100 From: "David Chadwick" Organization: University of Salford To: Date: Fri, 21 Jul 2000 17:46:09 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Some comments on model-04 Reply-to: d.w.chadwick@salford.ac.uk Message-ID: <39788C61.7721.9EEAC63@localhost> In-reply-to: <007c01bfa2cc$a671d7d0$97b544ab@cisco.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 John & Co I have a few comments to make on the Model doc, most of them minor i) you mention the term context prefix to refer to the root of a naming context, but mostly use the term root. I would prefer that you use context prefix consistently since a) this accords with X.518 and b) it can keep the term root reserved for the root of the DIT ii) last sentence of 4.6.1. I would like some clarification of what this actually means (A CSN is recorded.......). iii) I believe there is a conflict between 8.2 and 10.3 concerning fractional replication. Either the fraction is sent only the attributes it contains (8.2) or the whole modification operation is sent (10.3) but not both. iv) section 12, steps 5 and 6 for DSA2. I believe there is a bug here. In step 5 please state explicitly what the parent entry of the rep agreement NC1R1-R2 is. I believe it should be NC1R1. In step 6 state explicitly what the parent of rep agreement NC1R2-R1. I believe it should be NC1R2. Hence the rep agreements are not siblings, as they dont have the same parent. (otherwise I have misunderstood the model and perhaps some more text somewhere to clarify this) v) It is interesting that step 5 above said take a copy of the rep agreement, whereas in section 14 it states that autentication information should never be replicated between replicas. Perhaps this statements are slightly at odds with each other. Also , if password authentication is being employed, then the password will need to be replicated between the DSAs, thus section 14 is wrong. 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 Fri Jul 21 16:38:11 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 QAA12843 for ; Fri, 21 Jul 2000 16:38:10 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA17983 for ietf-ldup-bks; Fri, 21 Jul 2000 13:04:16 -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 NAA17979 for ; Fri, 21 Jul 2000 13:04:10 -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 UAA07156; Fri, 21 Jul 2000 20:06:41 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <4.3.2.7.0.20000721130516.00b1ed90@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Jul 2000 13:06:40 -0700 To: From: "Kurt D. Zeilenga" Subject: Re: 9. "Replication of ACI changes" Cc: , In-Reply-To: <000901bff249$8b799a40$17448490@vic.bigpond.net.au> References: <001701bff155$9f3a5e60$b05508cb@osmium.adacel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:53 PM 7/20/00 +1000, Albert Langer wrote: >As you know I have not proposed an alternative to URP's basic approach for >dealing with modifyDN, create and delete operations, but only for modify >operations, since your approach to the former does maintain atomicity. Does the fact that a modifyDN may change the entry's contents have any impact upon this discussion? From owner-ietf-ldup@mail.imc.org Fri Jul 21 18:39: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 SAA04496 for ; Fri, 21 Jul 2000 18:39:03 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA20953 for ietf-ldup-bks; Fri, 21 Jul 2000 15:07:44 -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 PAA20949 for ; Fri, 21 Jul 2000 15:07:37 -0700 (PDT) Received: (qmail 18897 invoked from network); 21 Jul 2000 22:05:29 -0000 Received: from cpe-144-132-68-23.vic.bigpond.net.au (HELO w98sysrec) (144.132.68.23) by relay1.pair.com with SMTP; 21 Jul 2000 22:05:29 -0000 X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: "'Kurt D. Zeilenga'" Cc: , Subject: RE: 9. "Replication of ACI changes" Date: Sat, 22 Jul 2000 08:09:30 +1000 Message-ID: <000101bff360$58e3d740$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: <4.3.2.7.0.20000721130516.00b1ed90@infidel.boolean.net> 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 [Kurt] At 10:53 PM 7/20/00 +1000, Albert Langer wrote: >As you know I have not proposed an alternative to URP's basic approach for >dealing with modifyDN, create and delete operations, but only for modify >operations, since your approach to the former does maintain atomicity. Does the fact that a modifyDN may change the entry's contents have any impact upon this discussion? [Albert] Yes, thanks for mentioning that. Whenever modifyDN is not just a move to a different superior with no change in the RDN, then it changes the contents as well as the DN (unless it happens to just swap some distinguished and non-distinguished attribute values and not add or remove any). Thus there isn't a complete separation between the Directory Information Base (DIB) aspects that MDCR deals with and the Directory Information Tree (DIT) aspects that I have just assumed will be handled along the same lines that URP proposes. My assumption has really been that URP does handle the DIT aspects atomically, imprecisely described by me above as also handling modifyDN atomically, although as you point out, only create and delete are actually always handled atomically. It is the URP's "basic approach" to DIT issues that I agree with - eg renaming by adding the entryID as a distinguished value when there are clashes. I've just assumed that given both DIT and DIB aspects would be handled atomically, there wouldn't be any major problem combining them into a single atomic operation in which they either both eventually succeed or both eventually fail (whether due to DIT integrity constraints, structure rules, name forms, object class schema or any kind of access controls). This may in fact require some of the "distinguished-not-present" complications in URP, hopefully only when the operation has eventually failed by resulting in a renaming anyway. But I haven't attempted to think any of that through at all - just proposing a method of dealing with DIB changes atomically and leaving DIT issues to be worked out in detail later, hopefully together with the authors of URP, and only when and if the WG decides to consider MDCR by adding it to its agenda as a possible alternative. (I'd certainly rather leave thinking through that stuff to people who have already thought a lot about it - ie Steve and Alison). That overlap may well further complicate handling ACI issues, but I simply haven't thought about it yet. Do you have any specific thoughts on it? For now, I think the simplest possible example of what happens when URP merges independent changes to different attributes or attribute values will do, without complicating the examples by considering modifyDN. Just changes to (non-distinguished) ACI attributes for a single entry made at different replicas will suffice to show this just HAS to be done atomically. From owner-ietf-ldup@mail.imc.org Sat Jul 22 13:51: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 NAA07293 for ; Sat, 22 Jul 2000 13:51:45 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA12147 for ietf-ldup-bks; Sat, 22 Jul 2000 10:17: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 KAA12141 for ; Sat, 22 Jul 2000 10:17:12 -0700 (PDT) Received: (qmail 27547 invoked from network); 22 Jul 2000 17:15:07 -0000 Received: from cpe-144-132-68-23.vic.bigpond.net.au (HELO w98sysrec) (144.132.68.23) by relay1.pair.com with SMTP; 22 Jul 2000 17:15:07 -0000 X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: , Cc: Subject: RE: Some comments on model-04 Date: Sun, 23 Jul 2000 03:19:14 +1000 Message-ID: <000001bff400$f5df6960$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: <39788C61.7721.9EEAC63@localhost> Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Re point i), there may perhaps also be an unintentional limitation in the possibilities for replication agreements by defining a "Replica" as "an instance of a replicated Naming Context" (3.5, p9). Although "sparse" replicas are currently out of scope by 3.3g this refers to the complexity of implementing entry selection filters. It may not have been intended to rule out vertically adjacent replicated areas held by the same DSA in connection with different replication agreements that are themselves contiguous or convex subtrees and not "sparse". The term "Naming Context" does exclude that, as explained in 4.4 of David's book "Understanding X.500", at the URL below. I believe this point may have been raised earlier (by Dieter?), with some mention of the architecture authors following up to correct it in the archives. But it doesn't seem to have been corrected. The only benefit of this limitation that I can see is to ensure that modifyDN operations within an NC can always be performed at any updateable replica. That strikes me as unnecessary since a referral could just be given to a "full" replica that holds replication agreements for the entire NC when a modifyDN is outside the replication areas held by a DSA. A category of "full" replicas, each of which is updatable for every replicated area within the NC could be defined. The "primary" for any replicated area within an NC would then also be the primary for all other replicated areas within the NC and would be one of the "full" replicas. Alternatively it would not be all that difficult to add a slightly more complex calculation of who to send a referral to, when not all updateable replicas that can process modifyDN are "full". Even if this restriction was intentional, I can see no justification for applying it to Read-Only replicas. Why shouldn't they hold vertically adjacent replicated areas as well as disjoint ones? eg Why shouldn't a branch office DSA serving a particular OU for an organization hold read only copies of the top of an organization's tree as well as read only copies for some, but not all, of the other OUs at the same level, any of which might be vertically adjacent to the top area? Why shouldn't another DSA at a different office interested in read only copies of a different set of OUs also be able to do that? The present definition requires that either the top be excluded so that disjoint NCs can be defined, or that a single NC cover them all and every read only replica hold the entire set. I suspect it may have been unintentional, as there is clearly some confusion around about the concept of an NC. The definition on p9 refers to X.501 but does not make it clear that any other NCs encountered down the tree from the context prefix held by a DSA must be context prefixes held in a different DSA. In draft-ietf-ldapext-acl-model-06.txt, there is even a reference to "adjacent naming contexts supported by that directory server" at 3.3, p6 despite the definition that NCs are disjoint, never adjacent within a DSA. I am CCing this to ldapext for that last point, despite still not being subscribed. It isn't just a matter of terminology, but may relate to confusion about the role of subschema and access control administration points and their relations to distribution and replication. In general, attempting to define replication and access controls without having first clarified distribution models and administrative models doesn't seem to have been a good idea. Seeya, Albert -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of David Chadwick Sent: Saturday, July 22, 2000 2:46 AM To: ietf-ldup@imc.org Subject: Some comments on model-04 John & Co I have a few comments to make on the Model doc, most of them minor i) you mention the term context prefix to refer to the root of a naming context, but mostly use the term root. I would prefer that you use context prefix consistently since a) this accords with X.518 and b) it can keep the term root reserved for the root of the DIT ii) last sentence of 4.6.1. I would like some clarification of what this actually means (A CSN is recorded.......). iii) I believe there is a conflict between 8.2 and 10.3 concerning fractional replication. Either the fraction is sent only the attributes it contains (8.2) or the whole modification operation is sent (10.3) but not both. iv) section 12, steps 5 and 6 for DSA2. I believe there is a bug here. In step 5 please state explicitly what the parent entry of the rep agreement NC1R1-R2 is. I believe it should be NC1R1. In step 6 state explicitly what the parent of rep agreement NC1R2-R1. I believe it should be NC1R2. Hence the rep agreements are not siblings, as they dont have the same parent. (otherwise I have misunderstood the model and perhaps some more text somewhere to clarify this) v) It is interesting that step 5 above said take a copy of the rep agreement, whereas in section 14 it states that autentication information should never be replicated between replicas. Perhaps this statements are slightly at odds with each other. Also , if password authentication is being employed, then the password will need to be replicated between the DSAs, thus section 14 is wrong. 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 Sun Jul 23 18:26: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 SAA01599 for ; Sun, 23 Jul 2000 18:26:45 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA03426 for ietf-ldup-bks; Sun, 23 Jul 2000 14:47:29 -0700 (PDT) Received: from inet-smtp3.oracle.com (inet-smtp3.oracle.com [205.227.43.23]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA03422 for ; Sun, 23 Jul 2000 14:47:24 -0700 (PDT) Received: from gmgw01.us.oracle.com (gmgw01.us.oracle.com [130.35.61.190]) by inet-smtp3.oracle.com (8.9.3/8.9.3) with ESMTP id OAA14265; Sun, 23 Jul 2000 14:50:11 -0700 (PDT) Received: from oracle.com (whq4op3x38-rtr-opw0-37.us.oracle.com [130.35.32.77]) by gmgw01.us.oracle.com (8.8.8+Sun/8.8.8) with ESMTP id OAA02180; Sun, 23 Jul 2000 14:50:01 -0700 (PDT) Message-ID: <397B6AA7.820D1C7C@oracle.com> Date: Sun, 23 Jul 2000 14:59:03 -0700 From: Uppili Srinivasan X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Albert.Langer@directory-designs.org CC: d.w.chadwick@salford.ac.uk, ietf-ldup@imc.org, ietf-ldapext@netscape.com Subject: Re: Some comments on model-04 References: <000001bff400$f5df6960$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 Albert: The "Naming context" definition in the context of replication was meant to avoid two replicas in the same DSA with over lapping or contiguous areas. It does allow multiple agreements associated with the same replica. You are right about some changes that were discussed around the definition of NC. The idea was to alter it as necessary so that the definition is consistent across replication, the ACL model (Ellen) and also for any future sub schema work (Mark Wahl). Let me try to make the necessary modification after some discussion at Pittsburgh with these authors. I would like to re-examine the ambiguities you have highlighted (regarding what is intentionally or unintentionally implied as requirements for read-only replicas) with a modified definition of NC. Thanks, Uppili. Albert Langer wrote: > Re point i), there may perhaps also be an unintentional limitation in the > possibilities for replication agreements by defining a "Replica" as "an > instance of a replicated Naming Context" (3.5, p9). Although "sparse" > replicas are currently out of scope by 3.3g this refers to the complexity of > implementing entry selection filters. It may not have been intended to rule > out vertically adjacent replicated areas held by the same DSA in connection > with different replication agreements that are themselves contiguous or > convex subtrees and not "sparse". The term "Naming Context" does exclude > that, as explained in 4.4 of David's book "Understanding X.500", at the URL > below. > > > I believe this point may have been raised earlier (by Dieter?), with some > mention of the architecture authors following up to correct it in the > archives. But it doesn't seem to have been corrected. > The only benefit of this limitation that I can see is to ensure that > modifyDN operations within an NC can always be performed at any updateable > replica. That strikes me as unnecessary since a referral could just be given > to a "full" replica that holds replication agreements for the entire NC when > a modifyDN is outside the replication areas held by a DSA. A category of > "full" replicas, each of which is updatable for every replicated area within > the NC could be defined. The "primary" for any replicated area within an NC > would then also be the primary for all other replicated areas within the NC > and would be one of the "full" replicas. Alternatively it would not be all > that difficult to add a slightly more complex calculation of who to send a > referral to, when not all updateable replicas that can process modifyDN are > "full". > > Even if this restriction was intentional, I can see no justification for > applying it to Read-Only replicas. Why shouldn't they hold vertically > adjacent replicated areas as well as disjoint ones? > eg Why shouldn't a branch office DSA serving a particular OU for an > organization hold read only copies of the top of an organization's tree as > well as read only copies for some, but not all, of the other OUs at the same > level, any of which might be vertically adjacent to the top area? Why > shouldn't another DSA at a different office interested in read only copies > of a different set of OUs also be able to do that? The present definition > requires that either the top be excluded so that disjoint NCs can be > defined, or that a single NC cover them all and every read only replica hold > the entire set. > > I suspect it may have been unintentional, as there is clearly some confusion > around about the concept of an NC. The definition on p9 refers to X.501 but > does not make it clear that any other NCs encountered down the tree from the > context prefix held by a DSA must be context prefixes held in a different > DSA. In draft-ietf-ldapext-acl-model-06.txt, there is even a reference to > "adjacent naming contexts supported by that directory server" at 3.3, p6 > despite the definition that NCs are disjoint, never adjacent within a DSA. > > I am CCing this to ldapext for that last point, despite still not being > subscribed. > > It isn't just a matter of terminology, but may relate to confusion about the > role of subschema and access control administration points and their > relations to distribution and replication. > > In general, attempting to define replication and access controls without > having first clarified distribution models and administrative models doesn't > seem to have been a good idea. > > Seeya, Albert > > -----Original Message----- > From: owner-ietf-ldup@mail.imc.org > [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of David Chadwick > Sent: Saturday, July 22, 2000 2:46 AM > To: ietf-ldup@imc.org > Subject: Some comments on model-04 > > John & Co > > I have a few comments to make on the Model doc, most of them > minor > > i) you mention the term context prefix to refer to the root of a > naming context, but mostly use the term root. I would prefer that > you use context prefix consistently since a) this accords with X.518 > and b) it can keep the term root reserved for the root of the DIT > > ii) last sentence of 4.6.1. I would like some clarification of what this > actually means (A CSN is recorded.......). > > iii) I believe there is a conflict between 8.2 and 10.3 concerning > fractional replication. Either the fraction is sent only the attributes it > contains (8.2) or the whole modification operation is sent (10.3) but > not both. > > iv) section 12, steps 5 and 6 for DSA2. I believe there is a bug > here. In step 5 please state explicitly what the parent entry of the > rep agreement NC1R1-R2 is. I believe it should be NC1R1. In step > 6 state explicitly what the parent of rep agreement NC1R2-R1. I > believe it should be NC1R2. Hence the rep agreements are not > siblings, as they dont have the same parent. (otherwise I have > misunderstood the model and perhaps some more text somewhere > to clarify this) > > v) It is interesting that step 5 above said take a copy of the rep > agreement, whereas in section 14 it states that autentication > information should never be replicated between replicas. Perhaps > this statements are slightly at odds with each other. Also , if > password authentication is being employed, then the password will > need to be replicated between the DSAs, thus section 14 is wrong. > > 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 Mon Jul 24 17:47: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 RAA17122 for ; Mon, 24 Jul 2000 17:47:34 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA22542 for ietf-ldup-bks; Mon, 24 Jul 2000 13:55:44 -0700 (PDT) Received: from mail1.ecal.com ([216.150.139.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA22538 for ; Mon, 24 Jul 2000 13:55:43 -0700 (PDT) Received: from pacapple ([216.52.68.3]) by mail1.ecal.com (Post.Office MTA v3.5.2 release 221 ID# 30-55765U3000L300S0V35) with SMTP id com; Mon, 24 Jul 2000 16:58:23 -0400 From: capple@ecal.com (Christopher Apple) To: Cc: , , "Chris Apple" Subject: LDUP Working Group Agenda Date: Mon, 24 Jul 2000 16:58:01 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0002_01BFF590.53BB41E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 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_0002_01BFF590.53BB41E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit LDUP WG Agenda - Pittsburgh IETF I. WG Deliverables Review "LDAP Replication Requirements" http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica-req-03.txt Editor(s): Russ Weiser, Ellen Stokes "LDUP Update Reconciliation Procedures" http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-03.txt Editor(s): Steven Legg, A Payne "LDAP Replication Architecture" http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-04.txt Editor(s): Ed Reed, U. Srinivasan, John Merrells "LDUP Replication Information Model" http://www.ietf.org/internet-drafts/draft-ietf-ldup-infomod-01.txt Editor(s): Ed Reed "LDAP Subentry Schema" http://www.ietf.org/internet-drafts/draft-ietf-ldup-subentry-03.txt Editor(s): Ed Reed "The LDUP Replication Update Protocol" http://www.ietf.org/internet-drafts/draft-ietf-ldup-protocol-01.txt Editor(s): G. Good, E. Stokes "Extended Operations for Framing LDAP Operations" http://www.ietf.org/internet-drafts/draft-ietf-ldup-framing-00.txt Editor(s): G. Good, E. Stokes, Rod Harrison II. Some deliverables still missing in action... III. Discussion of LDUP Requirements Document IV. Charter Addition for LCUP? "LDAP Client Update Protocol" http://www.ietf.org/internet-drafts/draft-natkovich-ldap-lcup-01.txt Editor(s): O. Natkovich, M. Smith, M. Armijo V. Other Business? Chris Apple capple@ecal.com ------=_NextPart_000_0002_01BFF590.53BB41E0 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 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:20000724T183753Z END:VCARD ------=_NextPart_000_0002_01BFF590.53BB41E0-- From owner-ietf-ldup@mail.imc.org Wed Jul 26 12:06: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 MAA12638 for ; Wed, 26 Jul 2000 12:06:22 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA08359 for ietf-ldup-bks; Wed, 26 Jul 2000 08:19:52 -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 IAA08352 for ; Wed, 26 Jul 2000 08:19:37 -0700 (PDT) Received: (qmail 7558 invoked from network); 26 Jul 2000 15:17: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; 26 Jul 2000 15:17:31 -0000 X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: "'Uppili Srinivasan'" Cc: , , Subject: RE: Some comments on model-04 Date: Thu, 27 Jul 2000 01:22:15 +1000 Message-ID: <000601bff715$48b41ac0$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: <397B6AA7.820D1C7C@oracle.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Uppili, Fine. When you do review it, if you decide to permit (vertically) adjacent non-overlapping areas, please use a different term than "Naming Context" as this has a precisely standardized meaning defined in X.500. I would suggest "replication area" as already used in the protocol draft. Also, I suggest using the word "adjacent" (or non-adjacent), as in the ACL draft, and giving a precise definition of that word. "Contiguous" is commonly used, but I find it slightly confusing (eg see my even more confusing use of "convex" below ;-) PS I should now be able to complete the responses to Steve in the next couple of days, as I've just managed to not let a daughter depart for Japan with a non-functional laptop, thus avoiding the classic "cobbler's family with no shoes" syndrome, and can therefore do some LDUP work :-) Hope it's not too late for people already on their way to IETF meeting. -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Uppili Srinivasan Sent: Monday, July 24, 2000 7:59 AM To: Albert.Langer@directory-designs.org Cc: d.w.chadwick@salford.ac.uk; ietf-ldup@imc.org; ietf-ldapext@netscape.com Subject: Re: Some comments on model-04 Albert: The "Naming context" definition in the context of replication was meant to avoid two replicas in the same DSA with over lapping or contiguous areas. It does allow multiple agreements associated with the same replica. You are right about some changes that were discussed around the definition of NC. The idea was to alter it as necessary so that the definition is consistent across replication, the ACL model (Ellen) and also for any future sub schema work (Mark Wahl). Let me try to make the necessary modification after some discussion at Pittsburgh with these authors. I would like to re-examine the ambiguities you have highlighted (regarding what is intentionally or unintentionally implied as requirements for read-only replicas) with a modified definition of NC. Thanks, Uppili. Albert Langer wrote: > Re point i), there may perhaps also be an unintentional limitation in the > possibilities for replication agreements by defining a "Replica" as "an > instance of a replicated Naming Context" (3.5, p9). Although "sparse" > replicas are currently out of scope by 3.3g this refers to the complexity of > implementing entry selection filters. It may not have been intended to rule > out vertically adjacent replicated areas held by the same DSA in connection > with different replication agreements that are themselves contiguous or > convex subtrees and not "sparse". The term "Naming Context" does exclude > that, as explained in 4.4 of David's book "Understanding X.500", at the URL > below. > > > I believe this point may have been raised earlier (by Dieter?), with some > mention of the architecture authors following up to correct it in the > archives. But it doesn't seem to have been corrected. > The only benefit of this limitation that I can see is to ensure that > modifyDN operations within an NC can always be performed at any updateable > replica. That strikes me as unnecessary since a referral could just be given > to a "full" replica that holds replication agreements for the entire NC when > a modifyDN is outside the replication areas held by a DSA. A category of > "full" replicas, each of which is updatable for every replicated area within > the NC could be defined. The "primary" for any replicated area within an NC > would then also be the primary for all other replicated areas within the NC > and would be one of the "full" replicas. Alternatively it would not be all > that difficult to add a slightly more complex calculation of who to send a > referral to, when not all updateable replicas that can process modifyDN are > "full". > > Even if this restriction was intentional, I can see no justification for > applying it to Read-Only replicas. Why shouldn't they hold vertically > adjacent replicated areas as well as disjoint ones? > eg Why shouldn't a branch office DSA serving a particular OU for an > organization hold read only copies of the top of an organization's tree as > well as read only copies for some, but not all, of the other OUs at the same > level, any of which might be vertically adjacent to the top area? Why > shouldn't another DSA at a different office interested in read only copies > of a different set of OUs also be able to do that? The present definition > requires that either the top be excluded so that disjoint NCs can be > defined, or that a single NC cover them all and every read only replica hold > the entire set. > > I suspect it may have been unintentional, as there is clearly some confusion > around about the concept of an NC. The definition on p9 refers to X.501 but > does not make it clear that any other NCs encountered down the tree from the > context prefix held by a DSA must be context prefixes held in a different > DSA. In draft-ietf-ldapext-acl-model-06.txt, there is even a reference to > "adjacent naming contexts supported by that directory server" at 3.3, p6 > despite the definition that NCs are disjoint, never adjacent within a DSA. > > I am CCing this to ldapext for that last point, despite still not being > subscribed. > > It isn't just a matter of terminology, but may relate to confusion about the > role of subschema and access control administration points and their > relations to distribution and replication. > > In general, attempting to define replication and access controls without > having first clarified distribution models and administrative models doesn't > seem to have been a good idea. > > Seeya, Albert > > -----Original Message----- > From: owner-ietf-ldup@mail.imc.org > [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of David Chadwick > Sent: Saturday, July 22, 2000 2:46 AM > To: ietf-ldup@imc.org > Subject: Some comments on model-04 > > John & Co > > I have a few comments to make on the Model doc, most of them > minor > > i) you mention the term context prefix to refer to the root of a > naming context, but mostly use the term root. I would prefer that > you use context prefix consistently since a) this accords with X.518 > and b) it can keep the term root reserved for the root of the DIT > > ii) last sentence of 4.6.1. I would like some clarification of what this > actually means (A CSN is recorded.......). > > iii) I believe there is a conflict between 8.2 and 10.3 concerning > fractional replication. Either the fraction is sent only the attributes it > contains (8.2) or the whole modification operation is sent (10.3) but > not both. > > iv) section 12, steps 5 and 6 for DSA2. I believe there is a bug > here. In step 5 please state explicitly what the parent entry of the > rep agreement NC1R1-R2 is. I believe it should be NC1R1. In step > 6 state explicitly what the parent of rep agreement NC1R2-R1. I > believe it should be NC1R2. Hence the rep agreements are not > siblings, as they dont have the same parent. (otherwise I have > misunderstood the model and perhaps some more text somewhere > to clarify this) > > v) It is interesting that step 5 above said take a copy of the rep > agreement, whereas in section 14 it states that autentication > information should never be replicated between replicas. Perhaps > this statements are slightly at odds with each other. Also , if > password authentication is being employed, then the password will > need to be replicated between the DSAs, thus section 14 is wrong. > > 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 Wed Jul 26 21:48: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 VAA16905 for ; Wed, 26 Jul 2000 21:48:02 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA08797 for ietf-ldup-bks; Wed, 26 Jul 2000 18:13:35 -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 SAA08791 for ; Wed, 26 Jul 2000 18:13:34 -0700 (PDT) Received: from mail.mirapoint.com (mail.mirapoint.com [192.168.0.18]) by mail.mirapoint.com (Mirapoint) with SMTP id AAH33548; Wed, 26 Jul 2000 18:16:30 -0700 (PDT) Message-Id: <200007270116.AAH33548@mail.mirapoint.com> Date: Wed, 26 Jul 2000 18:18:25 -0700 From: Zachary Amsden Subject: Comments on protocol-02 To: 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 In sections 5.2 and 5.5, StartReplicationResponse and End ReplicationResponse are defined as extended requests ::= [APPLICATION 23] Why are they not categorized as extended responses? This is rather counterintuitive. The framing draft as proposed had requests and responses defined correctly, but gave request/response pairs different OIDs. This is also counter-intuitive, as other extended operations use the same OID on the request and response. Thanks, Zach Amsden zach@mirapoint.com From owner-ietf-ldup@mail.imc.org Wed Jul 26 22:54:33 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 WAA27935 for ; Wed, 26 Jul 2000 22:54:32 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA14840 for ietf-ldup-bks; Wed, 26 Jul 2000 19:20:48 -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 TAA14834 for ; Wed, 26 Jul 2000 19:20:47 -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 CAA06665; Thu, 27 Jul 2000 02:23:55 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <4.3.2.7.0.20000726191650.00b264f0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 26 Jul 2000 19:23:53 -0700 To: Zachary Amsden From: "Kurt D. Zeilenga" Subject: Re: Comments on protocol-02 Cc: ietf-ldup@imc.org In-Reply-To: <200007270116.AAH33548@mail.mirapoint.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 06:18 PM 7/26/00 -0700, Zachary Amsden wrote: >In sections 5.2 and 5.5, StartReplicationResponse and End >ReplicationResponse are defined as extended requests > ::= [APPLICATION 23] > >Why are they not categorized as extended responses? This is >rather counterintuitive. The framing draft as proposed had >requests and responses defined correctly, but gave >request/response pairs different OIDs. This is also >counter-intuitive, as other extended operations use the same >OID on the request and response. I suggest the no OID be specified with the response as it clear by the semantics of the protocol that it is paired with the request (this is, after all, why it is OPTIONAL). Or follow the StartTLS example and use the same OID for paired request and responses (the OID identifies the "operation" instead of the PDU). Kurt From owner-ietf-ldup@mail.imc.org Thu Jul 27 02:50:42 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 CAA14313 for ; Thu, 27 Jul 2000 02:50:41 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA28967 for ietf-ldup-bks; Wed, 26 Jul 2000 23:13:57 -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 XAA28960 for ; Wed, 26 Jul 2000 23:13:55 -0700 (PDT) Received: (qmail 14437 invoked from network); 27 Jul 2000 06:12:07 -0000 Received: from cpe-144-132-68-23.vic.bigpond.net.au (HELO w98sysrec) (144.132.68.23) by relay1.pair.com with SMTP; 27 Jul 2000 06:12:07 -0000 X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: "'Christopher Apple'" , , Cc: , Subject: RE: LDUP Working Group Agenda - Summary of objections to requirements draft Date: Thu, 27 Jul 2000 16:16:21 +1000 Message-ID: <000201bff792$2f8e3d00$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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [Chris] I. WG Deliverables Review "LDAP Replication Requirements" http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica-req-03.txt Editor(s): Russ Weiser, Ellen Stokes [...] III. Discussion of LDUP Requirements Document [Albert] I am also sending this to LDAPEXT as the direction taken by LDUP could have major consequences for LDAPEXT (eg the current proposals for ACL simply will not replicate correctly and future support for transactions will be difficult if not impossible). Above link shows: *** This Internet-Draft has expired and is no longer available. Unrevised documents placed in the Internet-Drafts directories have a maximum life of six months. After that time, they must be updated, or they will be deleted. This document was deleted on July 17, 2000. *** A copy of the "final" version, which expired on 21 April 2000, is in the LDUP email archive at: http://www.imc.org/ietf-ldup/mail-archive/msg00471.html Despite assurances from at least one person who should know, I remain quite convinced that members of the LDUP WG have NOT read it carefully. It is especially unlikely that anybody else has read it recently, since it expired two months ago and has now been deleted. In view of agenda item III, I strongly urge that you do read it again, carefully. As I cannot attend the discussion, I have included a summary of my formal objection to it below. 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 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. That fix is also consistent with the rest of the current architecture and URP and would not require major re-work of existing drafts. 2) There is no requirement for atomic operations. Again this is obscured by poor expression and nonsensical definitions, but in fact the architecture and URP drafts merge changes to individual attribute values made concurrently at different replicas. The fact that this obviously breaks the ACL standards being developed in LDUP, despite an overlap in authorship between the two documents, strongly confirms that the consequences for existing applications are simply not understand and should be studied through a requirements analysis by actively explaining the implications and soliciting input from other areas (operations etc) that may be affected. Fixing this would require substantial changes to the current architecture and URP. I have sketched one possible way to do so in the draft below. 3) There is no requirement to support mandatory operational attributes of LDAP. The operational attribute "modifiersName" cannot be supported meaningfully as nobody in particular can be said to be responsible for a change that has in fact been merged from two or more concurrent changes made independently and without knowledge of each other. This severely complicates system administration as the first thing anybody would want to know after receiving a problem report is "who changed what". I believe that point 1) would be taken for granted by anybody thinking about LDUP requirements. Until somebody presents an argument against convergence or "eventual consistency" I see no point in even trying to present an argument for it. The current approach is simply absurd. Point 3) is also pretty obvious and is just one of many consequences of point 2. On point 2, there are plausible arguments (which I disagree with) for breaking the current LDAP/X.500 data model. If the WG does intend to do that, it has an obligation to clearly explain its intentions in a requirements draft and actively solicit input. I cannot express the argument against doing so more clearly than has already been done, long ago, without adequate response, in the following comments "Re: LDUP warmup exercise: atomicity in LDAPv3", from Tim Howes (16 December 1998): *** "Each LDAP operation (add, modify, delete, moddn) as a whole is atomic. The whole operation either happens or it doesn't. Changes cannot be half-applied to any single LDAP server. The replication consistency model must assume and build on this basic fact to define how multiple LDAP replicas converge to the same state over time, in the absence of additional changes. This kind of loose consistency model is pretty fundamental to the notion of a directory. My two cents on what's important in a replication consistency model are that it must be 1) predictable, and that it should 2) make some kind of sense to people using the system. All this talk of consistency at different levels (e.g., between applications using the directory at the same time) is a red herring. Our job is to define a consistency model for the directory itself. Some applications may find this model sufficient for their needs. Others may have to build more elaborate models on top. But let's start with the basics. -- Tim" http://www.imc.org/ietf-ldup/mail-archive/msg00214.html *** In my view, both an explicit requirement for atomic operations and a requirement that the results be 1) predictable and 2) make some kind of sense to users, should be in the final requirements draft. The consistency model of URP, was summarized in Alison's "Contribution to Profiles Document (Consistency Discussion)": http://www.imc.org/ietf-ldup/mail-archive/msg00548.html The attached Word version, with more easily read tables, is: http://www.imc.org/ietf-ldup/mail-archive/doc00000.doc In my view it is: 1) Unpredictable. See the explanation of "Extraordinary States" and "Transient Extraordinary States" above. 2) Preposterously complex. See the extensive use of procedural pseudo code for a protocol that simply defies plain description, in the URP draft: http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-03.txt In reviewing the LDUP archives I noted that a number of people had expressed various reservations, especially concerning the consistency model for replication, but subsequently ceased active participation. Hopefully some of them may still be involved in LDAP-EXT and could therefore see this and decide to take part in the discussion. See also my individual submission to LDUP: http://www.ietf.org/internet-drafts/draft-langer-ldup-mdcr-00.txt and my response to the WG chair's request for status reports, which contains links to all relevant discussion of that objection prior to the document expiring: http://www.imc.org/ietf-ldup/mail-archive/msg00561.html Subsequent discussion can be seen by following from the thread of that message in the archive. From owner-ietf-ldup@mail.imc.org Thu Jul 27 20:00: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 UAA05788 for ; Thu, 27 Jul 2000 20:00:03 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA20663 for ietf-ldup-bks; Thu, 27 Jul 2000 16:15:57 -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 QAA20659 for ; Thu, 27 Jul 2000 16:15:56 -0700 (PDT) Received: from mail.mirapoint.com (mail.mirapoint.com [192.168.0.18]) by mail.mirapoint.com (Mirapoint) with SMTP id AAH37574; Thu, 27 Jul 2000 16:19:01 -0700 (PDT) Message-Id: <200007272319.AAH37574@mail.mirapoint.com> Date: Thu, 27 Jul 2000 16:21:08 -0700 From: Zachary Amsden Subject: LDUPResponseCode To: ietf-ldup@imc.org 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 Why is an LDUP response code necessary? First, the LDUP response codes listed don't cover all possible responses. noSuchObject or invalidDNSyntax are just a few. Second, it is completely redundant, since the extended response already includes a response code. This is confusing - how is an invalid DN in a startReplication reported back? I would propose eliminating it entirely, and allocating one of the available codes for any additional codes LDUP needs. From owner-ietf-ldup@mail.imc.org Thu Jul 27 23:27: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 XAA06916 for ; Thu, 27 Jul 2000 23:27:54 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA03513 for ietf-ldup-bks; Thu, 27 Jul 2000 19:54: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 TAA03509 for ; Thu, 27 Jul 2000 19:54:06 -0700 (PDT) Received: from mail.mirapoint.com (mail.mirapoint.com [192.168.0.18]) by mail.mirapoint.com (Mirapoint) with SMTP id AAH38251; Thu, 27 Jul 2000 19:57:14 -0700 (PDT) Message-Id: <200007280257.AAH38251@mail.mirapoint.com> Date: Thu, 27 Jul 2000 19:59:22 -0700 From: Zachary Amsden Subject: Anonymous read only replicas To: 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 Any plans to implement anonymous read-only replicas? These would most likely be replicas that can't communicate frequently, or have other real world constraints. Proposed method of doing this would be: assign reserved replica ID (-1?) for anonymous servers keep no update vectors for anonymous replicas connections are consumer initiated only host security/anonymous replication allowed is server configurable An example (albeit poor) of this would be, say there is some IETF host that stores RFC pages and drafts as LDAP records. Every interested party would need a replication agreement with IETF to sync their private LDAP servers with this, which is clearly unacceptable. Partial update could be allowed if the update vector given by the initiating party was recent enough that all changes were known -- otherwise a total update would be required. Total updates could be subject to administrative policy (i.e only X sync/(month-host) could be allowed to prevent possible DOS attacks. Comments welcome... Zach Amsden zach@mirapoint.com From owner-ietf-ldup@mail.imc.org Fri Jul 28 03:49: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 DAA12259 for ; Fri, 28 Jul 2000 03:49:12 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id AAA20270 for ietf-ldup-bks; Fri, 28 Jul 2000 00:13:27 -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 AAA20266 for ; Fri, 28 Jul 2000 00:13:23 -0700 (PDT) Received: (qmail 25137 invoked from network); 28 Jul 2000 07:16:35 -0000 Received: from softdnserror (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 28 Jul 2000 07:16:35 -0000 Reply-To: From: "Steven Legg" To: Cc: , Subject: RE: LDUP Working Group Agenda - Summary of objections to requirements draft Date: Fri, 28 Jul 2000 17:15:56 +1000 Message-ID: <000101bff864$28c7e430$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: <000201bff792$2f8e3d00$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: Albert Langer [mailto:Albert.Langer@Directory-Designs.org] > Sent: Thursday, 27 July 2000 16:16 > To: 'Christopher Apple'; ietf-ldup@imc.org; ietf-ldapext@netscape.com > Cc: agenda@ietf.org; johns@cisco.com > Subject: RE: LDUP Working Group Agenda - Summary of objections to > requirements draft [snip] > III. Discussion of LDUP Requirements Document > > [Albert] > I am also sending this to LDAPEXT as the direction taken by > LDUP could have > major consequences for LDAPEXT (eg the current proposals for > ACL simply will > not replicate correctly Servers that don't store access controls as values of the ldapACI attribute will have to give the appearance that they do for the purposes of LDUP. Having done that, the access controls will replicate as any other attribute values would. > and future support for transactions will be > difficult if not impossible). I've outlined an extension to LDUP for providing strong transactional consistency with a configurable degree of availability. Though you might not agree with the philosophy, no one has yet pointed out any fatal flaw in the procedure. [snip] > 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 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] > 2) There is no requirement for atomic operations. > > Again this is obscured by poor expression and nonsensical > definitions, but > in fact the architecture and URP drafts merge changes to individual > attribute values made concurrently at different replicas. The > fact that this > obviously breaks the ACL standards being developed in LDUP, URP doesn't merge changes to individual values. The current ldapACI attribute type definition equates two values if they are semantically the same, so URP will only have the effect of changing the meaning of a collection of ACIs because of an explicit user change request to remove ACIs. On the other hand, MDCR will arbitrarily throw away previously accepted ACIs because of a potential, but probably non-existent, semantic conflict between the original change requests. MDCR assumes that changes to the same entry at different replicas are automatically in conflict and one of them has to lose. I contend that URP does less damage and therefore has a better chance of achieving a favourable final AC state than MDCR. > despite an > overlap in authorship between the two documents, strongly > confirms that the > consequences for existing applications are simply not > understand and should > be studied through a requirements analysis by actively explaining the > implications and soliciting input from other areas > (operations etc) that may > be affected. > > Fixing this would require substantial changes to the current > architecture > and URP. I have sketched one possible way to do so in the draft below. > > 3) There is no requirement to support mandatory operational > attributes of > LDAP. > > The operational attribute "modifiersName" cannot be supported > meaningfully > as nobody in particular can be said to be responsible for a > change that has > in fact been merged from two or more concurrent changes made > independently > and without knowledge of each other. Even though we talk about changes being "merged" the reality is that one of them will take precedence over the others. The operational attribute updates from that one change also take precedence, so the value of modifiersName corresponds to the latest apparent change to the entry, which is exactly what you'd expect from the single master case. > This severely complicates system > administration as the first thing anybody would want to know > after receiving > a problem report is "who changed what". You've over estimated the utility of the modifiersName attribute. It only tells you who last changed something, not what they changed. [snip] > In my view, both an explicit requirement for atomic operations and a > requirement that the results be 1) predictable and 2) make some kind of > sense to users, should be in the final requirements draft. I don't think obliterating all trace of a user's previously accepted change to an entry because someone else changed some unrelated information in the same entry qualifies as either predictable or sensible to users. [snip] Regards, Steven From owner-ietf-ldup@mail.imc.org Fri Jul 28 04:12:16 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 EAA21047 for ; Fri, 28 Jul 2000 04:12:16 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA21915 for ietf-ldup-bks; Fri, 28 Jul 2000 00:35:31 -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 AAA21906 for ; Fri, 28 Jul 2000 00:35:22 -0700 (PDT) Received: (qmail 6904 invoked from network); 28 Jul 2000 07:33:33 -0000 Received: from cpe-144-132-68-23.vic.bigpond.net.au (HELO w98sysrec) (144.132.68.23) by relay1.pair.com with SMTP; 28 Jul 2000 07:33:33 -0000 X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: "'Zachary Amsden'" , Subject: RE: Anonymous read only replicas Date: Fri, 28 Jul 2000 17:38:12 +1000 Message-ID: <000e01bff866$c99374e0$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: <200007280257.AAH38251@mail.mirapoint.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Isn't this fully covered by LCUP? IV. Charter Addition for LCUP? "LDAP Client Update Protocol" http://www.ietf.org/internet-drafts/draft-natkovich-ldap-lcup-01.txt Editor(s): O. Natkovich, M. Smith, M. Armijo -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Zachary Amsden Sent: Friday, July 28, 2000 12:59 PM To: ietf-ldup@imc.org Subject: Anonymous read only replicas Any plans to implement anonymous read-only replicas? These would most likely be replicas that can't communicate frequently, or have other real world constraints. Proposed method of doing this would be: assign reserved replica ID (-1?) for anonymous servers keep no update vectors for anonymous replicas connections are consumer initiated only host security/anonymous replication allowed is server configurable An example (albeit poor) of this would be, say there is some IETF host that stores RFC pages and drafts as LDAP records. Every interested party would need a replication agreement with IETF to sync their private LDAP servers with this, which is clearly unacceptable. Partial update could be allowed if the update vector given by the initiating party was recent enough that all changes were known -- otherwise a total update would be required. Total updates could be subject to administrative policy (i.e only X sync/(month-host) could be allowed to prevent possible DOS attacks. Comments welcome... Zach Amsden zach@mirapoint.com From owner-ietf-ldup@mail.imc.org Fri Jul 28 14:52:43 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 OAA11035 for ; Fri, 28 Jul 2000 14:52:42 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA13984 for ietf-ldup-bks; Fri, 28 Jul 2000 11:14:33 -0700 (PDT) Received: from rhea.salford.ac.uk (rhea.salford.ac.uk [146.87.255.99]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA13980 for ; Fri, 28 Jul 2000 11:14:27 -0700 (PDT) Received: (qmail 10130 invoked by alias); 28 Jul 2000 18:17:44 -0000 Received: (qmail 10096 invoked from network); 28 Jul 2000 18:17:44 -0000 Received: from unknown (HELO dwc-acer) (146.87.80.54) by rhea.salford.ac.uk with SMTP; 28 Jul 2000 18:17:44 -0000 From: "David Chadwick" Organization: University of Salford To: , , "'Christopher Apple'" , , Date: Fri, 28 Jul 2000 19:17:22 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: clash of times Reply-to: d.w.chadwick@salford.ac.uk CC: Stephen Kent Message-ID: <3981DC42.28284.BAF7AD1@localhost> In-reply-to: <000201bff792$2f8e3d00$17448490@vic.bigpond.net.au> References: 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 Folks The PKIX session on Tuesday am clashes with LDAP LDUP replication. Is there any chance we can move either session 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 Fri Jul 28 18:07: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 SAA02620 for ; Fri, 28 Jul 2000 18:07:06 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA19193 for ietf-ldup-bks; Fri, 28 Jul 2000 14:20:52 -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 OAA19189 for ; Fri, 28 Jul 2000 14:20:50 -0700 (PDT) Received: (qmail 18401 invoked from network); 28 Jul 2000 21:19:06 -0000 Received: from cpe-144-132-68-23.vic.bigpond.net.au (HELO w98sysrec) (144.132.68.23) by relay1.pair.com with SMTP; 28 Jul 2000 21:19:06 -0000 X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: Cc: , Subject: RE: LDUP Working Group Agenda - Summary of objections to requirements draft Date: Sat, 29 Jul 2000 07:23:47 +1000 Message-ID: <001701bff8da$1e6110e0$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: <000101bff864$28c7e430$b05508cb@osmium.adacel.com.au> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [Issue A - ACI Replication] > [Albert] > I am also sending this to LDAPEXT as the direction taken by > LDUP could have > major consequences for LDAPEXT (eg the current proposals for > ACL simply will > not replicate correctly [Steve] Servers that don't store access controls as values of the ldapACI attribute will have to give the appearance that they do for the purposes of LDUP. Having done that, the access controls will replicate as any other attribute values would. [Albert] Understood. Naturally LDUP can only replicate access controls that are stored as LDAP attributes. RFC 2820 already requires that ACL standards MUST satisfy that necessity (3.1 G3). Since LDUP will replicate access controls the same way that it will replicate other attributes, they will encounter the same problems that other applications will encounter. The problem is that URP merges conflicting concurrent changes to attributes and attribute values made at different replicas, whereas currently proposed LDAPEXT ACI related attributes (like many other applications), rely on an application semantics that assumes they can only be updated atomically. [Issue B - Transactions] > and future support for transactions will be > difficult if not impossible). [Steve] I've outlined an extension to LDUP for providing strong transactional consistency with a configurable degree of availability. Though you might not agree with the philosophy, no one has yet pointed out any fatal flaw in the procedure. [snip] [Albert] When an actual draft has been published, feedback can be expected. Meanwhile, the outline you gave clearly indicates that the proposal relates to DSAs contacting other DSAs before performing an update. This does not satisfy the definition of multi-master replication in the LDUP charter: "A replication model where entries can be written and updated on any of several replica copies, without requiring communication with other masters before the write or update is performed." http://www.ietf.org/html.charters/ldup-charter.html It therefore cannot meet the real performance and availability requirements that motivate work on this (although those real requirements for multi-master mentioned in the introduction are completely obscured, buried or forgotten, in the actual text of the "final" requirements doc). There are many well known ways to support full transactions semantics in a non-multimaster environment and yours may or may not do well in comparison with others. Personally I cannot see what advantage it has over Alan Lloyd's advocacy of failover single master, but no doubt you will explain the advantages in a draft. However, like Alan's proposal, it cannot resolve any problems concerning future standardization of transactions that may result from deployment of multi-master LDUP standards, because it is not multi-master. Both the advantage and irrelevance of Alan's proposal is that it does not need any new standards, as it is just an implementation of existing single master standards. I see no reason to solve a problem by new standards when there is no clear advantage over what can be achieved within existing standards. Multi-master does provide local availability of updateable replicas, including availability without continuous connectivity, which cannot be achieved by either your proposal or Alans. 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. I cannot think of a way to do it satisfactorily in that environment. I suspect you cannot either, or you would not be turning your mind to future proposals for far more complex fundamental changes to DSA implementations, involving locking a majority of DSAs prior to each update. If you can think of a way for applications that need transactions to supply that support themselves within the currently proposed LDUP multi-master framework, as they can with single master replication, please spell it out. However there is no urgency to do so at the moment. All that is needed now is a clear statement in the requirements document that LDUP standards "SHOULD NOT impede future work on transactions". Actual demonstration, or justifying an inability to do so, can be left to subsequent documents and liason with people actually working on grouping or transactions (an area outside the scope of LDUP because it also applies to single server directories). Outlines of future proposals are of course interesting and relevant to the WG, but your outline concerning future transactional support has only one relevance to the final call on the requirements document. If you are confident about it, you should support adding a requirement that LDUP standards "SHOULD NOT impede future work on transactions", or perhaps a stronger requirement that it "MUST NOT". I have provided a definition of "SHOULD NOT impede" and ("MUST NOT impede"), in my individual submission: http://www.ietf.org/internet-drafts/draft-langer-ldup-mdcr-00.txt [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. Anyway, as you are not seeking a "final call" on URP without a mechanism spelled out for ensuring eventual convergence, I am quite happy to wait and see whether it can be done without a log-based mechanism when you publish a draft. 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. 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. If the current architecture and URP documents have left this for further work, that is fine by me, though it would have been better to have said so explicitly in the drafts. I simply object to the combination of current drafts that indicate intended non-convergence by dropping updates, together with an attempt to finalize a requirements document that does not make it utterly clear that this would be unacceptable. 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? As long as that requirement IS met, I don't really care that much HOW. [Issue D - Atomic operations] > 2) There is no requirement for atomic operations. > > Again this is obscured by poor expression and nonsensical > definitions, but > in fact the architecture and URP drafts merge changes to individual > attribute values made concurrently at different replicas. The > fact that this > obviously breaks the ACL standards being developed in [LDAPEXT], [Steve] URP doesn't merge changes to individual values. The current ldapACI attribute type definition equates two values if they are semantically the same, so URP will only have the effect of changing the meaning of a collection of ACIs because of an explicit user change request to remove ACIs. [Albert] There is obviously no way that URP *could* merge two attribute values that do not match for equality. I was not accusing you of doing an XOR of the individual bits of attribute values! Nor do I see any problem in the fact that URP will sometimes update a value with a slightly different bit string that does match for equality. The problem I was referring to is that URP merges the addition or deletion of different attribute values of a single entry made concurrently by DUA operations at different replicas. That means the set of ACI attribute values which each of two users thought they were establishing, will differ from the set of ACI attribute values that actually result from their concurrent actions. The example below from Alison's document shows the 9 states that could result from concurrent updates to two attributes at one replica with eventual convergence to one of those changes. Exactly the same applies to concurrent changes to two values of a single attribute such as ldapACI. In addition, the eventual convergence can be to a mixture of both changes with some attributes or attribute values changed by one concurrent operation and others changed by the other. If two users delete an attribute value from an attribute with 2 values it ends up empty, and possibly a schema violation, although each thought they were setting it to the single value the other thought they were deleting. Frankly I think that idea should also be just dismissed as "simply absurd". It isn't something people should find out about only after standards are finalized, buried among the other ingredients like monosodium glutamate. It should be highlighted in the requirements document, preferably with a heading like "WARNING: Lark's Vomit". However it has obviously been taken seriously, so I accept an obligation to answer it seriously. I just want to make damn sure that others who would be affected by it, and who could feel equally amazed, are aware of this intention, and may therefore come to the meeting, since I can't be there - and/or join or rejoin discussions of the WG "last call" on requirements in the LDUP mailing list. [Steve] On the other hand, MDCR will arbitrarily throw away previously accepted ACIs because of a potential, but probably non-existent, semantic conflict between the original change requests. MDCR assumes that changes to the same entry at different replicas are automatically in conflict and one of them has to lose. I contend that URP does less damage and therefore has a better chance of achieving a favourable final AC state than MDCR. > despite an > overlap in authorship between the two documents, strongly > confirms that the > consequences for existing applications are simply not > [understood] and should > be studied through a requirements analysis by actively explaining the > implications and soliciting input from other areas > (operations etc) that may > be affected. > > Fixing this would require substantial changes to the current > architecture > and URP. I have sketched one possible way to do so in the draft below. [Albert] Your contention should certainly be examined carefully. (See below). My aim at present is simply to ensure that LDAPEXT is fully aware of the consequences of letting a "final call" on LDUP requirements go unchallenged. The failure to require atomicity clearly affects ACI and I believe also many other aspects of the base LDAP standards and other extensions to them. The requirements document should clearly explain the potential impact and actively solicit input instead of glossing it over and inventing a new and absurd definition of "atomicity" to prevent thought in a thoroughly Orwellian manner. What is needed is not "a better chance of achieving a favorable [Access Control] state". The requirement ought to be: "LDUP standards SHALL absolutely guarantee correct operation of replicated access controls under all circumstances, during convergence as well as after". If either MDCR or URP, or any other proposal, cannot provide that guarantee it is not acceptable, whether or not it has a "better chance" than some other unacceptable proposal. In my view that guarantee can only be met satisfactorily by preserving the current LDAP/X.500 data model, in which entries are the unit on which operations are performed atomically, not individual attribute values. Obviously we disagree about that. Can we nevertheless agree that meeting that guarantee ought to be a requirement? [Issue E - modifiersName] > 3) There is no requirement to support mandatory operational > attributes of > LDAP. > > The operational attribute "modifiersName" cannot be supported > meaningfully > as nobody in particular can be said to be responsible for a > change that has > in fact been merged from two or more concurrent changes made > independently > and without knowledge of each other. [Steve] Even though we talk about changes being "merged" the reality is that one of them will take precedence over the others. The operational attribute updates from that one change also take precedence, so the value of modifiersName corresponds to the latest apparent change to the entry, which is exactly what you'd expect from the single master case. > This severely complicates system > administration as the first thing anybody would want to know > after receiving > a problem report is "who changed what". 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. If problems result from the rare race condition in which DUA B updates an entry between DUA A reading the previous state and writing the change based on that read, it tells you that the application should be fixed to prevent such problems in future - eg by explicitly replacing every attribute not changed as well as replacing the attributes changed, instead of just adding or deleting attribute values that are actually changed. That is usually unnecessary in single master environments but is the sort of thing that DOES become necessary for some existing applications in ANY multi-master environment, due to the much longer interval in which conflicting concurrent changes can occur, despite having read the state of the LOCAL copy of an entry "immediately" before changing that entry. That kind of fix could work, perhaps even with URP, by ensuring that convergence will be to the new state resulting from only one of the concurrent changes having actually occurred, and the others having had no effect. With that fix, modifiersName has the same semantics as on existing X.500/LDAP directories - as required by the existing standards. However, most applications will NOT be initially fixed for transition to a multi-master environment. MDCR attempts to minimize the system administration problems that WILL result, by ensuring convergence to the results of applying only 1 concurrent change, whether the applications have been fixed or not. This means that when something breaks that was not broken before, you know it was broken by something done by the DUA that last changed it. With URP, you just know it broke, and it broke after you turned on multi-master replication. Neither the directory service nor any applications of it are intended to support applications making concurrent changes to a single entry. Such concurrency is an unavoidable problem that must be dealt with by any multi-master system. This should be clearly explained in the requirements document and input actively sought from other areas likely to be affected. With URP, modifiersName only tells you that some of the attributes and values in an entry that is causing a problem were changed by that DUA and were changed blindly by that DUA with no way of knowing what the rest of the entry state that it was changing might actually be, or what the changes of that state might result in, based on unknown concurrent changes by other DUAs. The problem may in fact be due to the unknown concurrent changes by other DUAs. The same is true for entries that are causing no problems and in both cases there is no way to be sure of "who did what". So where does a sysadmin begin when trying to track down a problem? Personally I would start by ripping out multi-master replication, because it is obviously broken and causing problems. For what it is worth, that incidentally is the anecdotal results I have been getting in some discussions about future plans - "we're not interested in multi-master, it looks too complicated and unreliable". Nobody wants to have to administer a "directory" where they cannot be sure "who changed what". In fact the only valid value for a URP "modifiersName" attribute could be "nobody". [Issue F - Predictability and Understandability] > In my view, both an explicit requirement for atomic operations and a > requirement that the results be 1) predictable and 2) make some kind of > sense to users, should be in the final requirements draft. [Steve] I don't think obliterating all trace of a user's previously accepted change to an entry because someone else changed some unrelated information in the same entry qualifies as either predictable or sensible to users. [snip] Regards, Steven [Albert] Neither do I. MDCR keeps not only a trace, but a full audit trail at every replica, in which each change is associated with both the modifiersName of the DUA responsible and the replica at which the change occurred and the previous state of the entry. This makes it possible to make the rejected concurrent changes available for fixing by users instead of administrators - in much the same way that URP does this by placing orphans in "lost and found" for those conflicts that it does resolve atomically instead of "reconciling". It also makes it possible to add notifications in conjunction with LCUP or by email. URP just throws all this information away, pretending that there is no problem with conflicting concurrent changes, by obliterating the fact that there ever was a conflict. I believe it is highly predictable and easily understood by users, that if somebody else changes an entry at around the same time that you do, only 1 of the changes can succeed so their change may be eventually accepted and yours eventually rejected. This also happens on single master and single server directories, except that "around the same time" is a longer interval and it will therefore happen more often, and the successful change does not always have the latest timestamp. MDCR also tries to minimize the frequency with which it will happen, by maintaining a tree to serialize any concurrent changes that *could* be serialized. Some applications would still be affected, and the MDCR draft suggests possible ways of dealing with that, such as moving attributes or attribute values that can safely be updated concurrently into separate child entries, and providing backwards compatability through methods based on David Chadwick's "Compound (families) of entries" draft (expired). However it is still certainly a major concern and if the WG was considering any such proposal on its agenda, the potential problems should also be highlighted in a requirements document, to solicit input from other areas that might be affected, for the same reason that URP's approach should be. The fact is you can have locally available updatable replicas (multi-master), atomic operations and irrevocable operations - pick any 2. The choices that must be made between atomicity and durability of operations for multi-master replication should be clearly explained in requirements drafts, so that the consequences of those choices can be evaluated based on feedback. Instead the LDUP WG has chosen to provide no information and solicit no feedback. In my view that does not merit publication even as an "Informational" RFC, except perhaps with the status "Historic". What is not predictable or easily understood by users or administrators is when changes appear on entries that were not made by anybody in particular and yet identify somebody in particular as "modifiersName". URP produces "Extraordinary States" and "Transient Extraordinary States" and can multiply 2 changes made concurrently into 9 different transient states at different replicas for the same entry (with a combinatorial explosion for larger numbers of attribute values changed or concurrent operations). The consistency model of URP, was summarized in Alison's "Contribution to Profiles Document (Consistency Discussion)": http://www.imc.org/ietf-ldup/mail-archive/msg00548.html The attached Word version, with more easily read tables, is: http://www.imc.org/ietf-ldup/mail-archive/doc00000.doc It certainly isn't predictable. In fact I doubt that it can be analysed in non-polynomial time. If you think that it is predictable and makes some kind of sense to users, how about trying to summarize it for the requirements document. Here's an extract, please write a paragraph summary for the LDUP requirements document, in the marketing brochure style of that document, emphasizing how this predictability and understandability further enhances the "simple, highly efficient and flexible" LDUP standards "to meet the needs of both the internet and enterprise environments". *** 3.1 Latest Known Wins Consistency The "Latest Known Wins" approach has the outcome that all attributes will "eventually" reach the latest value entered into the system. During the "eventuality" being reached, intermediate states reflecting a combination of states which have existed over time may be held by an individual DSA. These intermediate states are best described using an example. Two operations, T1 at time 1 and T2 at time 2, occur on an entry updating attributes A and B. This may be viewed as follows : T0 T1 T2 A0 A1 A2 B0 B1 B2 "Latest Known Wins" consistency has the semantics that all directories will eventually have the state A2, B2 (providing no further operations in the distributed system affect attributes A and B). However, at times between either update occurring and this "eventuality", the directory state may be any combination of the individual states of A and B depending on the primitives currently received and processed by each DSA. That is, any of the following states may exist : * A0, B0 (Neither Operation has yet occurred) * A0, B1 (Partial completion of Operation 1) * A0, B2 (Partial completion of Operation 2) * A1, B0 (Partial completion of Operation 1) * A1, B1 (Operation 1 has occurred) * A1, B2 (Operation 1 completed, Partial completion of Operation 2) * A2, B0 (Partial completion of Operation 2) * A2, B1 (Operation 1 completed, Partial completion of Operation 2) * A2, B2 (Operation 2 has occurred) The length of time for "eventuality" to be reached is dependent on * replication agreement structure, (e.g. does the overall topology supported by all relevant replication agreements allow ease of communication between all DSAs?) * scheduling policies, (e.g. are changes made onchange, or via periodic policies (e.g. one per day?)) * DSA reliability, (e.g. are any DSAs bottlenecks in the transition of updates from one network area to another?) * communications links reliability. (e.g. are any DSAs separated from the remainder of the DSAs through slow or unreliable communications links?) Additionally, the above also influences the number and duration of these intermediate states occupied by a DSA. It is possible within a small community of reliable DSAs with reliable communications links to greatly minimise the period of time spent in these intermediate states. *** In my view the only accurate summary would be "LDUP currently does not have a viable proposal for replication standards as it did not do a requirements analysis before embarking on design and the result has inevitably turned out to be broken. We are therefore seeking input on requirements before proceeding further." The problem for URP is that the directory service has no way of defining what is "unrelated information" in the same entry. The whole basis of the LDAP/X.500 data model is that an "entry" consists of RELATED information about a "single entity". The actual relationships among attributes and attribute values are maintained by users and their applications, not by the directory service, so it simply cannot assume that they are unrelated. It does assume that different entries are unrelated, except for maintaining the tree structure, thus making applications themselves responsible for transactions affecting multiple entries. This is intentionally a VERY weak requirement on the directory service, necessary for it to be distributed and globally scalable. By assuming that attributes of an individual entry are unrelated, Active Directory breaks the LDAP/X.500 data model and could be in a real trouble if a viable standards based approach to multi-master LDAP replication gets going. By going further and treating even attribute values of a single attribute as though they are unrelated, URP makes it highly unlikely that a viable alternative to AD will actually be deployable. Why would anyone want anything even less consistent? Anyway, you seem to be agreeing that predictability and understandability should be a criteria by which proposals are evaluated. Can we agree that this should be written into the requirements document? We obviously disagree about whether atomicity is necessary for predictability and understandability and should also be written into the requirements document, but here's a reminder of the close relationship between the two: "Re: LDUP warmup exercise: atomicity in LDAPv3", from Tim Howes (16 December 1998): *** "Each LDAP operation (add, modify, delete, moddn) as a whole is atomic. The whole operation either happens or it doesn't. Changes cannot be half-applied to any single LDAP server. The replication consistency model must assume and build on this basic fact to define how multiple LDAP replicas converge to the same state over time, in the absence of additional changes. This kind of loose consistency model is pretty fundamental to the notion of a directory. My two cents on what's important in a replication consistency model are that it must be 1) predictable, and that it should 2) make some kind of sense to people using the system. All this talk of consistency at different levels (e.g., between applications using the directory at the same time) is a red herring. Our job is to define a consistency model for the directory itself. Some applications may find this model sufficient for their needs. Others may have to build more elaborate models on top. But let's start with the basics. -- Tim" http://www.imc.org/ietf-ldup/mail-archive/msg00214.html *** Could you please respond to it? Do you agree that LDUP has a responsibility to state its consistency model for entries in the requirements document? Whatever that model should be, the requirements document avoids any input about it by simply not mentioning it, and obscures this by irrelevant discussion of consistency between the state of different replicas. Seeya, Albert PS I have corrected two typos in my original with the intended words "understood" and "LDAPEXT" instead of "understand" and "LDUP", and marked those corrections with [brackets]. Also, I have not attempted to list other areas of LDAPEXT work that would be affected by the current LDUP approach, such as signed operations (RFC 2649) - broken by not maintaining the concept of an "operation". From owner-ietf-ldup@mail.imc.org Sun Jul 30 05:31:17 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 FAA01064 for ; Sun, 30 Jul 2000 05:31:16 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id BAA11767 for ietf-ldup-bks; Sun, 30 Jul 2000 01:48:04 -0700 (PDT) Received: from aspams52.cai.com (aspams52.cai.com [155.35.248.76]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA11763 for ; Sun, 30 Jul 2000 01:48:00 -0700 (PDT) Received: by aspams52.cai.com with Internet Mail Service (5.5.2650.21) id <3X7BBKN2>; Sun, 30 Jul 2000 18:51:01 +1000 Message-ID: <11981F9F5649D411BC92009027D0D18C8AA50F@aspams01.cai.com> From: "Lloyd, Alan" To: Albert.Langer@directory-designs.org, "'Christopher Apple'" , ietf-ldup@imc.org, ietf-ldapext@netscape.com Cc: agenda@ietf.org, johns@cisco.com Subject: RE: LDUP Working Group Agenda - Summary of objections to requirem ents draft Date: Sun, 30 Jul 2000 18:51:07 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is good and should be discussed. Lets put the goals down first - can the LDUP and URP standards make scaleable, reliable directory information systems for business use? I aggree and have voiced the opinion that once we go "sub atomic" on directory objects/entries - then that is implementation - not standardisation. For instance we dismantle in every DSA a complete DSAs NameSpace into RDB tables (32 patents) - so we can automatically index, 2 phase commit, etc.. we can do database replication (sub atomic - product feature) and ,DISP and DSP writethrough (standards feature). Can any vendor/person on this list confirm their desire to do directory entry sub - atomic interoperability testing.. and waht are the tests when they can do that. The rules of the IETF (IMHO) state that 2 or more implementations must interwork - to make an RFC. Can those involved say so.. otherwise - please consider.. Something which is "lightweight" cannot be "Unpredictable" and "Preposterously complex". regards alan -----Original Message----- From: Albert Langer [mailto:Albert.Langer@Directory-Designs.org] Sent: Thursday, July 27, 2000 4:16 PM To: 'Christopher Apple'; ietf-ldup@imc.org; ietf-ldapext@netscape.com Cc: agenda@ietf.org; johns@cisco.com Subject: RE: LDUP Working Group Agenda - Summary of objections to requirements draft [Chris] I. WG Deliverables Review "LDAP Replication Requirements" http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica-req-03.txt Editor(s): Russ Weiser, Ellen Stokes [...] III. Discussion of LDUP Requirements Document [Albert] I am also sending this to LDAPEXT as the direction taken by LDUP could have major consequences for LDAPEXT (eg the current proposals for ACL simply will not replicate correctly and future support for transactions will be difficult if not impossible). Above link shows: *** This Internet-Draft has expired and is no longer available. Unrevised documents placed in the Internet-Drafts directories have a maximum life of six months. After that time, they must be updated, or they will be deleted. This document was deleted on July 17, 2000. *** A copy of the "final" version, which expired on 21 April 2000, is in the LDUP email archive at: http://www.imc.org/ietf-ldup/mail-archive/msg00471.html Despite assurances from at least one person who should know, I remain quite convinced that members of the LDUP WG have NOT read it carefully. It is especially unlikely that anybody else has read it recently, since it expired two months ago and has now been deleted. In view of agenda item III, I strongly urge that you do read it again, carefully. As I cannot attend the discussion, I have included a summary of my formal objection to it below. 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 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. That fix is also consistent with the rest of the current architecture and URP and would not require major re-work of existing drafts. 2) There is no requirement for atomic operations. Again this is obscured by poor expression and nonsensical definitions, but in fact the architecture and URP drafts merge changes to individual attribute values made concurrently at different replicas. The fact that this obviously breaks the ACL standards being developed in LDUP, despite an overlap in authorship between the two documents, strongly confirms that the consequences for existing applications are simply not understand and should be studied through a requirements analysis by actively explaining the implications and soliciting input from other areas (operations etc) that may be affected. Fixing this would require substantial changes to the current architecture and URP. I have sketched one possible way to do so in the draft below. 3) There is no requirement to support mandatory operational attributes of LDAP. The operational attribute "modifiersName" cannot be supported meaningfully as nobody in particular can be said to be responsible for a change that has in fact been merged from two or more concurrent changes made independently and without knowledge of each other. This severely complicates system administration as the first thing anybody would want to know after receiving a problem report is "who changed what". I believe that point 1) would be taken for granted by anybody thinking about LDUP requirements. Until somebody presents an argument against convergence or "eventual consistency" I see no point in even trying to present an argument for it. The current approach is simply absurd. Point 3) is also pretty obvious and is just one of many consequences of point 2. On point 2, there are plausible arguments (which I disagree with) for breaking the current LDAP/X.500 data model. If the WG does intend to do that, it has an obligation to clearly explain its intentions in a requirements draft and actively solicit input. I cannot express the argument against doing so more clearly than has already been done, long ago, without adequate response, in the following comments "Re: LDUP warmup exercise: atomicity in LDAPv3", from Tim Howes (16 December 1998): *** "Each LDAP operation (add, modify, delete, moddn) as a whole is atomic. The whole operation either happens or it doesn't. Changes cannot be half-applied to any single LDAP server. The replication consistency model must assume and build on this basic fact to define how multiple LDAP replicas converge to the same state over time, in the absence of additional changes. This kind of loose consistency model is pretty fundamental to the notion of a directory. My two cents on what's important in a replication consistency model are that it must be 1) predictable, and that it should 2) make some kind of sense to people using the system. All this talk of consistency at different levels (e.g., between applications using the directory at the same time) is a red herring. Our job is to define a consistency model for the directory itself. Some applications may find this model sufficient for their needs. Others may have to build more elaborate models on top. But let's start with the basics. -- Tim" http://www.imc.org/ietf-ldup/mail-archive/msg00214.html *** In my view, both an explicit requirement for atomic operations and a requirement that the results be 1) predictable and 2) make some kind of sense to users, should be in the final requirements draft. The consistency model of URP, was summarized in Alison's "Contribution to Profiles Document (Consistency Discussion)": http://www.imc.org/ietf-ldup/mail-archive/msg00548.html The attached Word version, with more easily read tables, is: http://www.imc.org/ietf-ldup/mail-archive/doc00000.doc In my view it is: 1) Unpredictable. See the explanation of "Extraordinary States" and "Transient Extraordinary States" above. 2) Preposterously complex. See the extensive use of procedural pseudo code for a protocol that simply defies plain description, in the URP draft: http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-03.txt In reviewing the LDUP archives I noted that a number of people had expressed various reservations, especially concerning the consistency model for replication, but subsequently ceased active participation. Hopefully some of them may still be involved in LDAP-EXT and could therefore see this and decide to take part in the discussion. See also my individual submission to LDUP: http://www.ietf.org/internet-drafts/draft-langer-ldup-mdcr-00.txt and my response to the WG chair's request for status reports, which contains links to all relevant discussion of that objection prior to the document expiring: http://www.imc.org/ietf-ldup/mail-archive/msg00561.html Subsequent discussion can be seen by following from the thread of that message in the archive. From owner-ietf-ldup@mail.imc.org Sun Jul 30 09:28: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 JAA12989 for ; Sun, 30 Jul 2000 09:28:07 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id FAA23509 for ietf-ldup-bks; Sun, 30 Jul 2000 05:49:06 -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 FAA23505 for ; Sun, 30 Jul 2000 05:49:04 -0700 (PDT) Received: (qmail 17099 invoked from network); 30 Jul 2000 12:47:25 -0000 Received: from cpe-144-132-68-23.vic.bigpond.net.au (HELO w98sysrec) (144.132.68.23) by relay1.pair.com with SMTP; 30 Jul 2000 12:47:25 -0000 X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: "'Lloyd, Alan'" , "'Christopher Apple'" , , Cc: , Subject: RE: LDUP Working Group Agenda - Summary of objections to requirements draft Date: Sun, 30 Jul 2000 22:52:01 +1000 Message-ID: <000501bffa24$f4f92ac0$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 In-Reply-To: <11981F9F5649D411BC92009027D0D18C8AA50F@aspams01.cai.com> Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [Alan] This is good and should be discussed. Lets put the goals down first - can the LDUP and URP standards make scaleable, reliable directory information systems for business use? I aggree and have voiced the opinion that once we go "sub atomic" on directory objects/entries - then that is implementation - not standardisation. For instance we dismantle in every DSA a complete DSAs NameSpace into RDB tables (32 patents) - so we can automatically index, 2 phase commit, etc.. we can do database replication (sub atomic - product feature) and ,DISP and DSP writethrough (standards feature). Can any vendor/person on this list confirm their desire to do directory entry sub - atomic interoperability testing.. and waht are the tests when they can do that. [Albert] Thanks for the agreement. However I would like to focus on user requirements rather than vendor desires. When reviewing the LDUP archives I noticed your views and others expressing various "reservations", however the previous discussion was focussed on detail design and in the context of what vendors desired to implement. I believe that focus on vendor desires rather than user requirements is what led to the fundamental technical errors in the current architecture and URP drafts. Now that the requirements draft is up for "final call" (regrettably AFTER extensive architecture and design work) a decision MUST be made as to whether these ARE the requirements that users of the directory service have, that must be satisfied by the future proposed standards for meeting them. Let's focus on that REQUIREMENTS issue. It's what is on the agenda NOW. The basic problem, underlying all three of the key issues I summarized, is that the requirements draft simply contains NO requirements whatsoever relevant to multi-master replication. It does start from similar goals to your "scaleable, reliable directory information systems for business use". But then it simply does not state what is required from the standards in order to achieve those goals. All it requires of multi-master standards is: 5.6 The replication model MUST support both master-slave and authoritative multi-updateable replica relationships. Perhaps that's why others didn't find anything to object to? They may have only been looking for requirements that could cause difficulties in their vendor implementations. But even that is completely botched by the meaningless definition: 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. Simple proof reading is clearly required before final call. But how could ANYONE have actually READ that and thought that either the document or the intentions behind it, was ready for "final call"? There is obviously no possibility of an "authoritative master" taking precedence in resolving conflicts, since the definition of multi-master replication, copied from the WG charter correctly specifies: 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. There is no such thing as a "non-authoritative read-writeable copy" in multi-master. Nobody with the slightest understanding of what the WG is actually supposed to be working on could have such a complete misconception about updateable replicas, regardless of their expertize in other areas. Of course its rather hard for people to read the draft, since it is being discussed while expired and deleted, and is only available from the LDUP email archives: http://www.imc.org/ietf-ldup/mail-archive/msg00471.html [Alan] The rules of the IETF (IMHO) state that 2 or more implementations must interwork - to make an RFC. Can those involved say so.. otherwise - please consider.. Something which is "lightweight" cannot be "Unpredictable" and "Preposterously complex". regards alan [Albert] My understanding is that the current architecture and design approach is the result of a "vendor bake-off", so there must be sufficient vendor support for interoperability testing. Presumably Telstra is planning an implementation since the URP design came from there and they already have a simulator. Likewise Novell looks strongly committed together with Netscape and Sun. Even Oracle seems to be involved despite knowing a thing or two about the consequences of non-atomicity in databases. Of the majors, only Microsoft seems to have stayed well clear, perhaps laughing quietly on the way to the bank. Despite the complexities, I don't think the URP draft is unimplementable at all. Presumably there would have been loud screams from the various vendors if it was. The criteria for any testing would presumably be based on whether an implementation complies with the proposed standards. Acceptance of those proposed standards would presumably depend on whether they satisfy the requirements in the requirements document. Since that does not actually state ANY meaningful requirement for multi-master replication, it would not be difficult not to meet those requirements. Actually, as currently drafted, with not even convergence clearly required, an implementation could pass ANY test suite by simply dropping all updates and returning: the error code serverClocksOutOfSync (72). See p40 of: http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-04.txt That's what happens when you let implementors define their own requirements, though it is rather more spectacular than usual in this case, since they have come up with something simply absurd. It is the users, including system administrators, who will be hit by the complexities resulting from non-convergence, inconsistency and no audit trail. There is no shortage of vendor products that are "unpredictable" and "preposterously complex" to use. Sticking an IETF label of approved LDAP standard on such products won't help them as much as they seem to think. The question is whether what the vendors plan to implement will in fact meet user requirements for LDAP replication (whether "business" or other) and whether it will negatively impact existing LDAP standards. If there is a user requirement and LDAP standard for guaranteed eventual convergence it doesn't matter a damn if every potential implementor is ready, willing and able to do something else - the result would be useless to users. Likewise if there is a user requirement for atomic operations or modifiersName. Given the LDAP standards, anything that doesn't provide that just isn't LDAP. BTW a "proposed standard" from a WG does not require 2 or more implementations. That is only essential at a later stage of draft standard. An Informational RFC need not have any implementations at all. It can just be a poem provided it offers some information of interest to the internet community. The requirements draft now being considered for WG "final call" is naturally intended as an "Informational" RFC and would normally go through without much external review. Unfortunately it does not provide ANY useful information as to what requirements the LDUP WG intends to meet for its main focus on multi-master LDAP replication, despite considerable detail on matters common to single-master and multi-master replication. If unchallenged, that would result in the WG continuing to focus on vendor desires instead of user requirements in completing their proposed standards. Since a requirements draft is intended to guide the development of standards, and this one does not, it should be published only with simultaneous application of the status "Historic" (your spelling may vary). From owner-ietf-ldup@mail.imc.org Sun Jul 30 15:17:25 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 PAA23707 for ; Sun, 30 Jul 2000 15:17:25 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA06971 for ietf-ldup-bks; Sun, 30 Jul 2000 11:39:14 -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 LAA06967 for ; Sun, 30 Jul 2000 11:39:12 -0700 (PDT) Received: (qmail 5810 invoked from network); 30 Jul 2000 18:37:36 -0000 Received: from cpe-144-132-68-23.vic.bigpond.net.au (HELO w98sysrec) (144.132.68.23) by relay1.pair.com with SMTP; 30 Jul 2000 18:37:36 -0000 X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: , Cc: Subject: 7. "Revocation notices" Date: Mon, 31 Jul 2000 04:42:26 +1000 Message-ID: <000601bffa55$e9446100$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 In-Reply-To: <001701bff02f$f74e5ba0$17448490@vic.bigpond.net.au> Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Steve, Here's the response to item 7, which I summarized as: *** 7. "Revocation notices". Implicit agreement that MDCR could add them and that URP makes no provision for them because it does not revoke anything. Disagreement as to whether they are useful. http://www.imc.org/ietf-ldup/mail-archive/msg00614.html *** Comments follow original below. *** [Albert] > The conflicts form a tree in reality, whether it is > recognized or not. If > that tree becomes large then URP would produce a high rate of > "Extraordinary > States" and "Transient Extraordinary States" while MDCR would > produce a high > rate of revocation notices because it has at least recognized > the reality. > Neither is appropriate for directory applications. (In my view even an > extremely low rate of "Extraordinary States" without any > means except manual > administration to recover from them is completely unacceptable). [Steve] I don't expect many LDAP client application developers will want to deal with the complexities of out-of-band revocation notices, or deal with restoring the application context of the original change so it can be repeated. The enterprising ones will probably just send a series of spurious changes to an entry after each real change just to "up" the version number and so increase the chance of the real change sticking. In effect, what we have done with URP is hardwire a reasonable conflict resolution mechanism (best effort merge) that is (we think) good enough for most uses of the directory. [... Remainder already replied to as item 8, at end of URL above] *** [Albert] As you mentioned when changing the name from "Conflict Resolution" to "Update Reconciliation", best effort merge is not a conflict resolution method at all, because it sees no modify "conflicts". URP does recognize conflicts when a child is created concurrently with the parent being deleted, or two entries are given the same DN via concurrent creates and/or modifyDN operations. In that situation URP does store all the information necessary for users to fix the problem without sysadmin intervention, and therefore also does store all the information necessary to be able to issue revocation notices. When you publish a draft with a sufficiently robust purge mechanism to maintain eventual convergence despite clock non-monotonicity and DSAs crashing and being restored from backups, you will find that you also have sufficient information to be able to issue confirmation notices (ie notices that no such naming collision can occur), and should then also be able to rename just one of the entries in conflict rather than all of them, without excessive complication. That is necessary avoid entire existing entries, not just changes, mysteriously disappearing silently and without notification. Naming conflicts should be much less frequent than modify conflicts and are immediately obvious. So I have no objection to simply leaving revocation and confirmation notices about them for possible future extensions. No obstacle has been placed in the way of doing it later and you have enabled users to fix the problem themselves (when the renaming is restricted to the results of new operations and not also applied to existing entries). However the trade off for MDCR in avoiding the problems URP has with simple modify conflicts is that even a very low rate of concurrent modify operations eventually failing after a success response to a DUA, would still be a much higher rate than is likely for modifyDN and create operations. Also the eventual suppression of the operation during convergence would be much less obvious than for naming conflicts. Far from being "good enough for most uses of the directory" I regard ANY regular manual sysadmin intervention as completely unacceptable. As you have mentioned, it is especially unacceptable for suppressed ACI changes, but there are also many other situations where silently suppressing a change that has been reported as successful just won't work. Just after its clear requirement for atomicity, RFC 2251 adds: The server will return to the client a single Modify Response indicating either the successful completion of the DIT modification, or the reason that the modification failed. Note that due to the requirement for atomicity in applying the list of modifications in the Modify Request, the client may expect that no modifications of the DIT have been performed if the Modify Response received indicates any sort of error, and that all requested modifications have been performed if the Modify Response indicates successful completion of the Modify Operation. If the connection fails, whether the modification occurred or not is indeterminate. (4.6 Modify Operation, p34) Current client applications ARE designed with that expectation that all requested modifications have been performed when they get a success response. Any for which this is absolutely critical will of course also be aware that servers sometimes crash before being backed up and will be designed accordingly, but most applications do simply rely on that expectation. In a multi-master environment there is no alternative but to either drop atomicity (and isolation) of operations or have some operations eventually suppressed during convergence. That is a harsh reality. In maintaining atomicity and isolation only for naming conflicts, URP suffers from the problems discussed elsewhere. In taking the opposite approach, MDCR has to provide a "best effort" to deal with the very real problems that result from that opposite approach. The best that CAN be done is to issue revocation notices. That isn't difficult since all the information needed to do so is stored anyway. LDUP standards HAVE to work with EXISTING LDAP client APIs and applications. The whole reason LDAP is an important standard is the widespread adoption of standardized client access. I can't think of any application that would achieve anything useful to that application by adding spurious changes to increase the chances of some other instance of that application being suppressed during a conflict. Developers doing so would be stupid, not "enterprising". However if I'm wrong about that, then it's good the facility is available. Email revocation notices just ensure users (and sysadmins) know that a change was eventually suppressed, so they can do something about it before something else breaks as a result. There is unfortunately nothing better that CAN be done about such conflicts in a multi-master LDAP environment with existing clients. I can't see many LDAP application developers dealing with the complexities of automatically restoring application state either. There are of course even less who COULD deal with the complexities of maintaining, let alone restoring, application state based on merging of unknown and unknowable concurrent changes as in URP. NOBODY knows how to develop applications in an environment where the data you thought you were changing isn't necessarily the data you actually changed. So to avoid that absurdity, MDCR just has to do the best it can, which is revocation notices. Of course the more important mitigation is moving attributes and attribute values that can safely be updated concurrently into separate child entries and providing a merged view of the parent as a compound family for existing LDAP clients. Active Directory seems to be getting away with having just one of the concurrent additions or deletions to a security group or distribution list overwriting any others, but I can't see that scaling to really large organizational environments, let alone the global internet environment. So I'm trying to avoid the sort of problems that would result from an organization that just doesn't have any real concept of enterprise scalability, let alone global internet scalability, dominating de facto LDAP standards, as currently looks very likely if LDUP doesn't get its act together. Once replication and distribution is standardized, LDAP will become even more deeply entrenched in internet infrastructure and more complex applications with transactional and synchronization requirements will become more common. The LCUP drafts look like an excellent basis for handling notifications and I am quite confident that client APIs for that will become as widespread as current LDAP client APIs are now. Even without standardization, client APIs that handle three varieties of Microsoft proprietary asynchronous and "out of band" synchronization notifications are already included in every copy of the latest version of the dominant client OS. The information stored by MDCR anyway for actually resolving conflicts and implementing weeding and summarizing robustly, can also be used to simplify implementation of LCUP and servers can combine it with non-email notifications for revocation and confirmation. In that (future) environment it is much more likely that application developers will start dealing with the complexities of restoring application context. It is already being done in Distributed File System projects for mobile and disconnected environments such as Coda, Intermezzo and Bayou and Lotus Notes has been doing something similar for many years. Directory services WILL need to support this, so failing to provide for it in standards being developed now would be a mistake. Incidentally, the same information stored that supports revocation and confirmation notices can also support signed operations per RFC 2649 and will be very useful in future support of transactions. From owner-ietf-ldup@mail.imc.org Sun Jul 30 18:43: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 SAA18948 for ; Sun, 30 Jul 2000 18:43:14 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA08903 for ietf-ldup-bks; Sun, 30 Jul 2000 14:57:53 -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 OAA08899 for ; Sun, 30 Jul 2000 14:57:51 -0700 (PDT) Received: (qmail 23650 invoked from network); 30 Jul 2000 21:56: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; 30 Jul 2000 21:56:16 -0000 X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: , Cc: Subject: 1. "Atomicity and related concepts" and 2. "ModifiersName and Other Operational Attributes" Date: Mon, 31 Jul 2000 08:01:07 +1000 Message-ID: <000701bffa71$aa1ae140$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 In-Reply-To: <001701bff02f$f74e5ba0$17448490@vic.bigpond.net.au> Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Steve, I believe that I have covered item 2, which I summarized as: 2. "ModifiersName and other Operational Attributes". Disagreement about definition, semantics, and implications of URP and MDCR proposals for handling them. Definition and semantics should be clarified in requirements document before final call. URP and MDCR handling should be clarified in further discussion of URP and MDCR. Unclear whether there is a disagreement about a requirement to handle ModifiersName "correctly", because of lack of agreed definition of what would be "correct". This is covered both below in item 1, and in issue E of: http://www.imc.org/ietf-ldup/mail-archive/msg00641.html So this message completes the series of 9 items, except for responding to your further comments on items 3 and 5, and any further comments you may make on other items. Please let me know if I have failed to respond to anything. Here's the response to item 1, which I summarized as: *** 1. "Atomicity and related concepts". Disagreement about definition, importance and relation to other concepts and requirements. Should be clarified and resolved by definitions, explanations and requirements in requirements document before final call. http://www.imc.org/ietf-ldup/mail-archive/msg00614.html *** Comments interspersed with original below. *** > [RM] > On the subject of the requirements / URP draft: > > 1. I still believe the requirements draft should be more > explicit about atomicity of operations being maintained > across replication. In my various re-readings of this > draft, I have at times found justification for both > sides (maintain and do not maintain) and I still think > that maintaining atomicity is necessary. > > 2. The URP draft should be explicit in how it maintains > atomicity of operations across replication. I'm pretty > sure from my last perusal it doesn't now. > > [AL] > Understood. > URP certainly does not maintain atomicity and is explicit > about that. This > problem is not in the URP draft, but in the requirements > draft. If there was > a requirement to maintain atomicity there would be a > completely different > URP (not necessarily MDCR). [Steven] Atomicity is not the right concept to be arguing about in a multimaster replication environment. Consider this example. At server S1 at time t1 a user modify request on an entry adds attribute A1 and replaces the existing values of attribute A2. At server S2 at time t2 (t2 > t1) a user modify request replaces attribute A2. Some time later the modify from server S1 arrives at S2. If S2 performs this operation atomically it will replace the newer (time t2) value(s) of attribute A2 with the older values (time t1). This is clearly the wrong thing to do. If S2 adds the new attribute A1 but ignores the replacement of A2 (as URP would do) then it produces the same outcome as the serial execution of the two modify requests, though the action doesn't fit the usual definition of "atomic". [Albert] The user U1 at S1 wanted to modify the entry (A1,A2) from (-,x) to (y,z). The user U2 at S2 wanted to modify it from (-,x) to (-,w). The attributes A1 and A2 are presumably related, since U1 updated them both at once. They cannot both do what they want, so URP does something that neither of them wanted to do. It modifies (-,x) to (y,w). If U2 had known that the entry was (y,z) instead of just having read that it was (-,x) he or she might have decided to check with U1 before changing it, since U1 would be listed as the modifiersName and has recently changed it. So U1 sees U2 listed as modifiersName for (y,w) and asks U2 "why did you stuff up my change to (y,z) by changing it to (y,w)?". U2 replies "I didn't, the entry was (-,x) and I changed THAT to (y,w). After a few such incidents, one or other of U1 and U2 realize that it is unlikely that the other is making the same stupid mistake over and over again and refusing to admit it. So they report the mysterious behaviour of the application to the Help Desk. After a few attempts to convince them that they must be hallucinating and/or pacify them with muzak, the Help Desk accumulates a sufficient range of credible reports, or a single report from a more senior user who can't be ignored, and passes it on to a sysadmin. The sysadmin runs a few tests. Every time the sysadmin logs in as two different users and makes similar changes they work fine (because they are happening on the same replica). So the sysadmin reports "no fault found". After a few more such incidents the sysadmins that have been called in notice that the users have become more hallucinatory than usual and are becoming "restless". Eventually the problem escalates to the point where a more senior and experienced sysadmin is told "FIND it and FIX it NOW". The experienced sysadmin checks what changed around the time the users starting to hallucinate. After investigating the application, the directory software, the air-conditioning, the water supply, the operating system and so forth, none of which have changed, the experienced sysadmin eventually notices that a very minor configuration change occurred, with two way replication instead of one way replication between directory servers. The wise sysadmin has never heard of atomicity but knows exactly what to do. He or she undoes that minor change, just because it correlates with the hallucinations. Everyone lives happily ever after, except perhaps the directory vendor, who might get sued. Of course with any luck, one of A1 or A2 will be ldapACI, so a CERT advisory warning people not to turn on two way replication will go out relatively quickly, lower level sysadmins will be more likely to see that, and a great deal of wasted time will have been avoided - except of course for the LDUP WG developing standards and the vendors silly enough to implement them. With MDCR the situation is also unsatisfactory, though not as bad. Some time after having made the change from (-, x) to (y, z), U1 will get an email notification explaining that this change was automatically revoked because another user changed the entry at around the same time on a different server. If that happens too often, somebody will either have to reconfigure the replication scheduling or alter the application to separate A1 and A2 into different child entries. But the problem will be a clear and easily understood result of using multi-master in a situation that is unsuitable for it. Not just a mysterious "something's broken". [Steve] If we are going to discuss atomicity in replication then we need a more meaningful definition. URP makes all the replicas produce an outcome that is equivalent to the serial atomic execution of all the updates. That is as atomic as it needs to be. [Albert] The current requirements draft has a completely meaningless definition: 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. In order to discuss and even think about anything at all, we have to use the "usual" definitions. The purpose of Orwellian doublespeak is precisely to prevent discussion and thought. If URP just had to meet that Orwellian definition, it would pass with flying colors - every modification in a single operation is elaborately provided with a sequential modification number, wrapped in a framed operation and propagated to a replica as a single unit. The only point of doing so seems to be to distract attention from the fact that on arrival it is promptly merged, with concurrent changes at that replica and those that have arrived from other replicas, and the merged changes, which are not the result of ANY LDAP operation, are then elaborately sequenced and packaged to repeat the charade elsewhere. This produces a combinatorial explosion of intermediate visible states which can be read by DUAs and be the basis for other changes. When there are no such further changes the result eventually converges (leaving aside problems with timestamps etc) to a MIXTURE of the various concurrent operations. THIS is "clearly the wrong thing to do". It is less atomic than it needs to be because it is the precise opposite of atomic. What is needed is for applications to know that either the whole operation succeeded or the whole operation failed. Since they are built on that assumption they will break when it isn't true. As well as making intermediate partial operations visible to DUAs, URP does NOT converge to "an outcome that is equivalent to the serial atomic execution of all the updates". That can only be done by suppressing changes that are not part of a sequence in which each successor could have read the result of its predecessor - which is the whole point of the tree maintained by MDCR. For example if two users replace the same attribute value with a different new value serially, by deleting the old value and adding the new value, one of the atomic operations MUST fail, since it has attempted to delete a value that isn't there. With URP, both succeed. In fact URP *always* succeeds, whereas atomicity is all about sometimes failing. URP will even "succeed" if two users concurrently delete two different values from a mandatory attribute that originally held two values. It will "succeed" by deleting both and marking it as a schema violation for the sysadmin to clean up. What then was the point of the schema? For LDUP to be "as atomic as it needs to be" it needs to be as atomic as expected by the existing LDAP applications. The "usual" definition isn't just some convention, it is a mandatory standard for LDAP which MUST be complied with by LDUP standards. [Steve] The real question revolves around the preconditions of a user update request. If we look at the equivalent serial processing of a collection of updates performed at two or more multimaster replicas then some of those updates will be "executed" against a different database state than actually existed at the time they were really performed by one of the replicas. [Albert] Stop fantasizing about revolving around aspects of reality that are inconvenient for URP. Here's the REAL requirement that LDUP MUST meet. It isn't a question, it is a command: - modification: A list of modifications to be performed on the entry. The entire list of entry modifications MUST be performed in the order they are listed, as a single atomic operation. While individual modifications may violate the directory schema, the resulting entry after the entire list of modifications is performed MUST conform to the requirements of the directory schema. The values that may be taken on by the 'operation' field in each modification construct have the following semantics respectively: add: add values listed to the given attribute, creating the attribute if necessary; delete: delete values listed from the given attribute, removing the entire attribute if no values are listed, or if all current values of the attribute are listed for deletion; replace: replace all existing values of the given attribute with the new values listed, creating the attribute if it did not already exist. A replace with no value will delete the entire attribute if it exists, and is ignored if the attribute does not exist. (RFC 2251 4.6 Modify Operation, p33) [Steve] The URP philosophy is that most of the time for most applications it doesn't really matter. The MDCR philosophy is that it is better to completely disregard the user's update, after the fact, just in case the state of the entry did matter. [Albert] The URP "philosophy" is that existing standards don't matter and that manual sysadmin fixes for the results of breaking them are acceptable. You *seem* to be also saying that the state of an entry before it is written doesn't really matter to the user changing it. If that was really true ANY of the time, for ANY applications, there wouldn't be much point changing it, would there? MDCR certainly does suppress concurrent changes, "just in case" the state of the entry did matter. Its "philosophy" is that the state matters or they wouldn't be changing it. It does so "after the fact", which WILL cause problems, because there is no other possibility in a multi-master environment. But it doesn't "completely disregard" the suppressed update. See item 7 on Notifications. Faced with the unpleasant consequences of multi-master, the vital thing is to get the widest possible input from people likely to be affected by them, as to what trade offs should be made. If MDCR doesn't pass that scrutiny, something better will be worked out. By failing to present a requirements document that clearly and frankly explains the issues and solicits input, the LDUP WG can guarantee that whatever it decides on will meet vendor requirements and not have to worry about user requirements. That is clearly the wrong thing to do. From owner-ietf-ldup@mail.imc.org Mon Jul 31 17:25:16 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 RAA18138 for ; Mon, 31 Jul 2000 17:25:16 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA21463 for ietf-ldup-bks; Mon, 31 Jul 2000 13:49:08 -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 NAA21459 for ; Mon, 31 Jul 2000 13:49:08 -0700 (PDT) Received: from mail.mirapoint.com (mail.mirapoint.com [192.168.0.18]) by mail.mirapoint.com (Mirapoint) with SMTP id AAA05401; Mon, 31 Jul 2000 13:52:43 -0700 (PDT) Message-Id: <200007312052.AAA05401@mail.mirapoint.com> Date: Mon, 31 Jul 2000 13:53:06 -0700 From: Zachary Amsden Subject: Protocol-02 proposed change To: 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 I would suggest changing start replication response to: StartReplicationResponse ::= [APPLICATION 24] SEQUENCE { requestName [0] LDAPOID requestValue [1] OCTET STRING } requestValue ::= SEQUENCE { replicaUpdateVector Attribute OPTIONAL } This defines it properly as a response, eliminates the redundant response code field, and allows omission of the replicaUpdateVector when it doesn't make sense (consumer initiated replication sessions). Hopefully this can make discussion in the session tomorrow - I am unable to attend. Zach Amsden zamsden@mirapoint.com From owner-ietf-ldup@mail.imc.org Mon Jul 31 20:37: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 UAA16607 for ; Mon, 31 Jul 2000 20:37:15 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA24779 for ietf-ldup-bks; Mon, 31 Jul 2000 17:01:31 -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 RAA24775 for ; Mon, 31 Jul 2000 17:01:29 -0700 (PDT) Received: from mail.mirapoint.com (mail.mirapoint.com [192.168.0.18]) by mail.mirapoint.com (Mirapoint) with SMTP id AAA06550; Mon, 31 Jul 2000 17:05:05 -0700 (PDT) Message-Id: <200008010005.AAA06550@mail.mirapoint.com> Date: Mon, 31 Jul 2000 17:05:30 -0700 From: Zachary Amsden Subject: more proposed protocol changes To: 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 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. This avoids getting duplicate changes from multiple replicas over the wire, and avoids the need to reschedule replications because of "server busy" errors. Another use for this would be for deciding whether to abort a slower connection when a more preferred connection is going to cover the same sequence. It seems clear from the protocol-02 draft that there are no commitments implied by the startReplicationResponse vector - i.e under no circumstances should a supplier update it's known vector based on this response. All commitments should be made via an endReplicationResponse or an unsolicited ReplicationUpdateResponse. So I see no problem with this approach. Alternatively, the consumer could send an immediate replicationUpdateResponse, but there are two problems with this: 1) The current draft states that the response is sent when the consumer wishes the supplier to stop sending updates. I disagree with this. I see no reason the supplier should stop if it has changes not covered by the suppliers vector, unless abortUpdate is set. 2) Sequencing -the supplier may have already queued a large number of replicationUpdates, which defeats the purpose. So that would be: StartReplicationRequest ::= [APPLICATION 23] SEQUENCE { requestName [0] LDAPOID, requestValue [1] OCTET STRING } requestValue ::= SEQUENCE { replicaRoot LDAPDN, replicaID LDAPString, replicationProtocolOID LDAPOID, replicationInitiator ENUMERATED { supplier (0), consumer (1) } replicatUpdateVector Attribute OPTIONAL } Zach Amsden zach@mirapoint.com