From owner-ietf-ldup Thu Dec 4 14:38:16 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA00754 for ietf-ldup-bks; Thu, 4 Dec 1997 14:38:16 -0800 (PST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.41]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA00748 for ; Thu, 4 Dec 1997 14:38:12 -0800 (PST) Received: by INET-01-IMC with Internet Mail Service (5.5.1960.3) id ; Thu, 4 Dec 1997 14:39:59 -0800 Message-ID: From: Chris Weider To: "'ietf-ldup@imc.org'" Cc: "'agenda@ietf.org'" Subject: LDUP BOF Date: Thu, 4 Dec 1997 14:39:53 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ietf-ldup@imc.org Precedence: bulk Hi gang: The LDUP BOF (LDAP Replication) will be held on Tuesday, 12/9, from 15:45 - 16:45. We will be attempting to see if we can come up with a charter consensus for working on LDAP replication in the IETF. Please read the document draft-ietf-asid-replica-req-01.txt. Although the BOF list has just been set up, please feel free to use it for discussions. See you there! Chris From owner-ietf-ldup Mon Dec 8 09:19:49 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA18425 for ietf-ldup-bks; Mon, 8 Dec 1997 09:19:49 -0800 (PST) Received: from folder.critical-angle.com (eden-gw.critical-angle.com [206.81.238.241]) by mail.proper.com (8.8.7/8.7.3) with SMTP id JAA18419 for ; Mon, 8 Dec 1997 09:19:44 -0800 (PST) Received: (qmail 16061 invoked from network); 8 Dec 1997 17:17:10 -0000 Received: from folder.critical-angle.com (206.81.238.241) by folder.critical-angle.com with SMTP; 8 Dec 1997 17:17:10 -0000 From: Mark Wahl To: ietf-ldup@imc.org cc: Mark Wahl Subject: concurrency requirements for LDAP-based replication Date: Mon, 08 Dec 1997 11:17:09 -0600 Message-ID: <16059.881601429@folder.critical-angle.com> Sender: owner-ietf-ldup@imc.org Precedence: bulk There are several possible approaches which this BOF could propose for how to work on replication in LDAP directories. These could range in complexity from dumping a server's directory with search requests to a LDAP-based protocol for coordination amongst multiple masters with schema negotiation. Many of the technical issues, such as access control, would be most relevant to particular forms of replication. One aspect which I believe is common to all is the requirements on LDAP directories for concurrency. As a protocol which describes the interaction between a single client and server on one connection, LDAP does not currently define the server's behavior when there is more than one client actively modifying the directory or multiple master servers. Future extensions to LDAP for providing transaction support to clients will require a clear definition of the requirements on LDAP servers in this area in order to maintain the transaction properties. Replication conventions which are transparent to servers (such as replication by a simple search) need to ensure that changes by clients do not get lost. Replication protocols will have stricter requirements, especially in a multi-master environment. I would like to propose that determining concurrency requirements for LDAP servers is a topic which belongs in a WG resulting from the LDUP BOF. The goal of this work item would then be to document these requirements in standards-track RFC, developed in conjunction with a replication conventions or protocol document. While a replication protocol document would be based on the concurrency requirements document, as well as on the replication requirements and other drafts, I suggest that it would be best developed as a separate document so that this work would be useful to the designers of LDAP transaction specifications. Mark Wahl, Enterprise Directory Integration Critical Angle Inc. From owner-ietf-ldup Tue Dec 9 03:07:41 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id DAA07774 for ietf-ldup-bks; Tue, 9 Dec 1997 03:07:41 -0800 (PST) Received: from fl.dk (ns.fl.dk [193.88.152.146]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id DAA07769 for ; Tue, 9 Dec 1997 03:07:35 -0800 (PST) Received: by gw.fl.dk id <26902-3>; Tue, 9 Dec 1997 12:08:44 +0100 Message-Id: <97Dec9.120844gmt+0100.26902-3@gw.fl.dk> From: Erik Andersen To: "'LDUP'" Cc: Tom Skovgaard Subject: Interchange formats Date: Tue, 9 Dec 1997 11:53:45 +0100 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ietf-ldup@imc.org Precedence: bulk In Denmark, we have a particular requirement for transfer of what could be considered directory information. The telephone operators in Denmark are required to exchange telephone number information to allow for a combined telephone numbering service. This requirement also includes transfer of information to third parties having a legitimate need for numbers, e.g. providing an online or a paper directory for particular purposes. The transfer will include postal addresses. It should also reflect some organisational structure, like the hierarchy within an organisation. The problems involved are very much related to directory replication/synchronisation. We have studied several different format, among those several Danish home grow formats, the X.500 shadowing protocol and the LDIF. Work on LDIF seems to be quite dormant for the time being. The current draft is actually expired. However, I assume that the new BOF will take that up. Transfer of telenumbers is a question about transfering large amount of information, i.e. possible several milion entries in a single batch transfer. Overhead should therefore be kept at a minimum. The format we will suggest should also cope with future requirements, such as inclusion of e-mail addresses, certificates, etc. Our current suggestion is to use an optimised LDIF format. We are working on such an optimised format. What is the current thinking of the BOF? Are you planning to work on these issues? We want a standarised solution to our problem. Hope this gets to you before Washington - have a good meeting. Kind regards, Erik Andersen, Fischer & Lorenz Denmark. From owner-ietf-ldup Tue Dec 9 10:46:07 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA13454 for ietf-ldup-bks; Tue, 9 Dec 1997 10:46:07 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA13450 for ; Tue, 9 Dec 1997 10:46:03 -0800 (PST) Received: from korova ("port 4223"@KOROVA.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IQYU3CZD5C9TCXR6@INNOSOFT.COM> for ietf-ldup@imc.org; Tue, 9 Dec 1997 10:47:59 PST Date: Tue, 09 Dec 1997 10:50:14 -0800 From: Peter Coates Subject: Re: Interchange formats X-Sender: pcoates@thor To: Erik Andersen Cc: "'LDUP'" , Tom Skovgaard Message-id: <3.0.32.19971209105014.00b55440@thor> MIME-version: 1.0 X-Mailer: Windows Eudora Pro Version 3.0 (32) Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ldup@imc.org Precedence: bulk At 11:53 1997/12/09 +0100, Erik Andersen wrote: <<>> >Our current suggestion is to use an optimised LDIF format. We are >working on such an optimised format. > >What is the current thinking of the BOF? Are you planning to work on >these issues? We want a standarised solution to our problem. > Erik, I am interested in what you mean by optimised LDIF. We are using LDIF as a format for directory synchronization, but the delta form of LDIF is awkward both to use and to generate. Instead, we are using a form as follows To add a record, present it just as an absolute LDIF record. This means that to populate an LDAP directory, you can just "add" a file containing absolute LDIF records. To delete a record, write !DN: xxx To modify a record, put a "+" in front of the DN, and then use the modifiers + and ! in front of each attribute to mean modify or delete. For instance +DN: cn=Peter Coates; o=Innosoft +email: peter.coates@innosoft.com !fax !telephone: 818 919 3600 telephone: 626 919 3600 means: modify cn=Peter Coates modify the email attribute to be peter.coates@innosoft.com delete all fax attributes delete the telephone attribute with the value 818 919 3600 add the telephone attribute 626 919 3600 If there is a move afoot to revisit LDIF, and make it easier to use for directory synchronization, I would be interested in what others are doing, and conform. Peter From owner-ietf-ldup Tue Dec 9 16:09:05 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA17133 for ietf-ldup-bks; Tue, 9 Dec 1997 16:09:05 -0800 (PST) Received: from ip78.129.isdn.hogia.net (ip78.129.isdn.hogia.net [195.78.129.78]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA17129 for ; Tue, 9 Dec 1997 16:09:00 -0800 (PST) Received: from [195.78.129.68] by ip78.129.isdn.hogia.net with SMTP (QuickMail Pro Server for MacOS 1.0.2a7); 10 DEC 97 02:09:37 UT X-Sender: paul@mail.objectzone.se Message-Id: In-Reply-To: <3.0.32.19971209105014.00b55440@thor> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 10 Dec 1997 01:10:43 +0100 To: LDUP List From: Paul Panotzki Subject: Re: Interchange formats Sender: owner-ietf-ldup@imc.org Precedence: bulk At 19.50 +0100 97-12-09, Peter Coates wrote: >I am interested in what you mean by optimised LDIF. We are using LDIF as a >format for directory synchronization, but the delta form of LDIF is awkward >both to use and to generate. Instead, we are using a form as follows We also use LDIF to synchronize. Not incrementally yet because we find it awkward, just like you say. >To add a record, present it just as an absolute LDIF record. This means >that to populate an LDAP directory, you can just "add" a file containing >absolute LDIF records. This sounds good. >To delete a record, write > >!DN: xxx Fine. >To modify a record, put a "+" in front of the DN, and then use the >modifiers + and ! in front of each attribute to mean modify or delete. For >instance > >+DN: cn=Peter Coates; o=Innosoft >+email: peter.coates@innosoft.com >!fax >!telephone: 818 919 3600 >telephone: 626 919 3600 > >means: modify cn=Peter Coates >modify the email attribute to be peter.coates@innosoft.com >delete all fax attributes >delete the telephone attribute with the value 818 919 3600 >add the telephone attribute 626 919 3600 Hmmm, there is a problem here with the way you modify an attribute. Since "mail" is multivalued, which of the values are you modifying? Or does this mean that you implicitly delete all values and replace them by the new one? Then how do you modify with several values? Same thing goes for other multivalued attributes. >If there is a move afoot to revisit LDIF, and make it easier to use for >directory synchronization, I would be interested in what others are doing, >and conform. I agree. Best regards, Paul ----------------------------------------------------------------------- Paul Panotzki Phone: +46 8 730 30 98 Object Zone AB Fax: +46 8 444 61 28 ----------------------------------------------------------------------- From owner-ietf-ldup Tue Dec 9 16:47:29 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA17616 for ietf-ldup-bks; Tue, 9 Dec 1997 16:47:29 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA17610 for ; Tue, 9 Dec 1997 16:47:25 -0800 (PST) Received: from korova ("port 4310"@KOROVA.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IQZ6O8Y3C29TD171@INNOSOFT.COM> for ietf-ldup@imc.org; Tue, 9 Dec 1997 16:48:25 PST Date: Tue, 09 Dec 1997 16:50:40 -0800 From: Peter Coates Subject: Re: Interchange formats X-Sender: pcoates@thor To: Paul Panotzki Cc: LDUP List Message-id: <3.0.32.19971209165040.00b61ba0@thor> MIME-version: 1.0 X-Mailer: Windows Eudora Pro Version 3.0 (32) Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ldup@imc.org Precedence: bulk At 01:10 1997/12/10 +0100, Paul Panotzki wrote: >At 19.50 +0100 97-12-09, Peter Coates wrote: >>I am interested in what you mean by optimised LDIF. We are using LDIF as a >>format for directory synchronization, but the delta form of LDIF is awkward >>both to use and to generate. Instead, we are using a form as follows > >We also use LDIF to synchronize. Not incrementally yet because we find it >awkward, just like you say. > >>To add a record, present it just as an absolute LDIF record. This means >>that to populate an LDAP directory, you can just "add" a file containing >>absolute LDIF records. > >This sounds good. > >>To delete a record, write >> >>!DN: xxx > >Fine. > >>To modify a record, put a "+" in front of the DN, and then use the >>modifiers + and ! in front of each attribute to mean modify or delete. For >>instance >> >>+DN: cn=Peter Coates; o=Innosoft >>+email: peter.coates@innosoft.com >>!fax >>!telephone: 818 919 3600 >>telephone: 626 919 3600 >> >>means: modify cn=Peter Coates >>modify the email attribute to be peter.coates@innosoft.com >>delete all fax attributes >>delete the telephone attribute with the value 818 919 3600 >>add the telephone attribute 626 919 3600 > >Hmmm, there is a problem here with the way you modify an attribute. Since >"mail" is multivalued, which of the values are you modifying? Or does this >mean that you implicitly delete all values and replace them by the new one? >Then how do you modify with several values? > >Same thing goes for other multivalued attributes. > Absolutely right: our synchronization tools do not generate these modify attributes. However they are there for completeness, and map onto the LDAP modify operation. *foo: bar is equivalent to !foo foo: bar >>If there is a move afoot to revisit LDIF, and make it easier to use for >>directory synchronization, I would be interested in what others are doing, >>and conform. > >I agree. > >Best regards, >Paul > > > >----------------------------------------------------------------------- >Paul Panotzki Phone: +46 8 730 30 98 >Object Zone AB Fax: +46 8 444 61 28 >----------------------------------------------------------------------- > > > > From owner-ietf-ldup Fri Dec 12 01:51:53 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id BAA03920 for ietf-ldup-bks; Fri, 12 Dec 1997 01:51:53 -0800 (PST) Received: from fl.dk (ns.fl.dk [193.88.152.146]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id BAA03916 for ; Fri, 12 Dec 1997 01:51:47 -0800 (PST) Received: by gw.fl.dk id <26889-2>; Fri, 12 Dec 1997 10:53:18 +0100 Message-Id: <97Dec12.105318gmt+0100.26889-2@gw.fl.dk> From: Erik Andersen To: "'LDUP'" Cc: Tom Skovgaard Subject: More on interchange formats Date: Fri, 12 Dec 1997 10:54:27 +0100 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ietf-ldup@imc.org Precedence: bulk Hi Peter, Paul and Gordon (and others) Thanks for your responses to my note on interchange formats. First some thoughts about an optimised LDIF format and secondly some other limitations we need to get a solution to. The aim must be to make any changes backward compatible, i.e. an implementation supporting an extended format shall also be able to support the current LDIF. I know this is going to be a little difficult. The current LDIF format could be made more compact by: - When specifying the objectClass attribute, it should only be necessary to specify the object classes from which the entry is directly derived. Any superior object classes could be implied, as the object class inheritance hierarchy should be known by the receiver. As an example, for an organizationalPerson it should not be necessary to specify the person and top object classes as well. - A multi-valued attribute could be specified on a single, possibly wrapped line with some kind of separator between values. - All non-text information, like certificates, could be transferred as an octet string instead of the base-64 encoding. We do not see a need to use e-mail for transfer of synchronisation information (this might give backward compatibility problems). - It may not be necessary to transfer the complete distinguished name for entries if entry information is transferred in some particular sequence much as it is done in the X.500 shadowing format. (However, a text oriented format does not allow for a structured data types, such as it is possible in an ASN.1 encoded string. It is therefore not possible to make it as elegant as it is done for the X.500 shadowing format.) Now to the real hard problem by giving an example: Erik Andersen, as a residential person, has two telephone numbers. One fixed telephone number with Tele Denmark and a mobile telephone number with Sonofon. Now, if Sonofon transfer its telephone number information to Tele Denmark, how will Tele Denmark be able to merge the two pieces of information into a single entry? How do we allocate distinguished names to residential persons? The only viable idea is to use social security numbers or some other unique identifiers, which would just be an alias for a social security number. People are quite sensitive with respect to use of social security numbers - the Big Brother syndrome. The current solution today in a Danish e-mail directory is to have a complete flat name space below a postal district. When a service provider today stores information about a subscriber in a directory, it gives the qualifier '1' to the first Erik Andersen he comes upon, number '2' to the next one etc. (there are plenty of them). The same Erik Andersen will get different qualifiers by different service providers, so the distinguished name is service provider specific and cannot be used for merging of information. Merging will have to be based on comparison of some key attributes. What those key attributes are, will depend on the particular situation. If a secure comparison cannot be made, a new entry will be created. I believe that there could be similar problems in an intra-organisation synchronisation where different databases or directory systems may be masters for different pieces of information. I have some ideas about how the above can be reflected in an extended "LDIF format". As Gordon suggests, I will try to draft something and put it on the exploder. I will take a few days but it should be there for pleasant Christmas reading. Kind regards, Erik From owner-ietf-ldup Fri Dec 12 17:04:52 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA15844 for ietf-ldup-bks; Fri, 12 Dec 1997 17:04:52 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id RAA15840 for ; Fri, 12 Dec 1997 17:04:48 -0800 (PST) Received: from korova ("port 4946"@KOROVA.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IR3E6CCYNQ9TD78D@INNOSOFT.COM> for ietf-ldup@imc.org; Fri, 12 Dec 1997 17:06:14 PST Date: Fri, 12 Dec 1997 17:09:20 -0800 From: Peter Coates Subject: Re: More on interchange formats In-reply-to: <97Dec12.105318gmt+0100.26889-2@gw.fl.dk> X-Sender: pcoates@limpet To: Erik Andersen Cc: "'LDUP'" , Tom Skovgaard Message-id: <01IR3E6CGZP49TD78D@INNOSOFT.COM> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Demo Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ldup@imc.org Precedence: bulk At 10:54 1997/12/12 +0100, Erik Andersen wrote: >Hi Peter, Paul and Gordon (and others) > >Thanks for your responses to my note on interchange formats. > >First some thoughts about an optimised LDIF format and secondly some >other limitations we need to get a solution to. > >The aim must be to make any changes backward compatible, i.e. an >implementation supporting an extended format shall also be able to >support the current LDIF. I know this is going to be a little difficult. Is the current delta form of LDIF actually being used? Obviously the absolute form is, but I'm less certain of the delta form. > >The current LDIF format could be made more compact by: > >- When specifying the objectClass attribute, it should only be necessary >to specify the object classes from which the entry is directly derived. >Any superior object classes could be implied, as the object class >inheritance hierarchy should be known by the receiver. As an example, >for an organizationalPerson it should not be necessary to specify the >person and top object classes as well. > >- A multi-valued attribute could be specified on a single, possibly >wrapped line with some kind of separator between values. > >- All non-text information, like certificates, could be transferred as >an octet string instead of the base-64 encoding. We do not see a need to >use e-mail for transfer of synchronisation information (this might give >backward compatibility problems). We *do* use email for directory synchronization. I would prefer to be able to transport ldif unencoded, but it's not that important. We also use the format for directory information from directories other than LDAP or X.500. This means that we have taken a fairly flexible view of what is allowed. >- It may not be necessary to transfer the complete distinguished name >for entries if entry information is transferred in some particular >sequence much as it is done in the X.500 shadowing format. (However, a >text oriented format does not allow for a structured data types, such as >it is possible in an ASN.1 encoded string. It is therefore not possible >to make it as elegant as it is done for the X.500 shadowing format.) >Kind regards, Erik > From owner-ietf-ldup Sat Dec 13 04:11:26 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id EAA25635 for ietf-ldup-bks; Sat, 13 Dec 1997 04:11:26 -0800 (PST) Received: from ip78.129.isdn.hogia.net (ip78.129.isdn.hogia.net [195.78.129.78]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id EAA25624 for ; Sat, 13 Dec 1997 04:11:18 -0800 (PST) Received: from [195.78.129.68] by ip78.129.isdn.hogia.net with SMTP (QuickMail Pro Server for MacOS 1.0.2a7); 13 DEC 97 14:12:09 UT X-Sender: paul@mail.objectzone.se Message-Id: In-Reply-To: <97Dec12.105318gmt+0100.26889-2@gw.fl.dk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 13 Dec 1997 13:13:16 +0100 To: Erik Andersen From: Paul Panotzki Subject: Re: More on interchange formats Cc: "'LDUP'" , Tom Skovgaard Sender: owner-ietf-ldup@imc.org Precedence: bulk At 10.54 +0100 97-12-12, Erik Andersen wrote: >The current LDIF format could be made more compact by: > >- When specifying the objectClass attribute, it should only be necessary >to specify the object classes from which the entry is directly derived. >Any superior object classes could be implied, as the object class >inheritance hierarchy should be known by the receiver. As an example, >for an organizationalPerson it should not be necessary to specify the >person and top object classes as well. This could be OK. Although, if you're using custom object classes (like say myOrgPerson SUP person SUP top) other directories will not be able to import your LDIF file. So you should at least include an object class that is "well known". I.e "person" would be required in the my example, but top wouldn't. In your example, using organizationalPerson would be enough, as it is "well known". >- A multi-valued attribute could be specified on a single, possibly >wrapped line with some kind of separator between values. Could work. >- All non-text information, like certificates, could be transferred as >an octet string instead of the base-64 encoding. We do not see a need to >use e-mail for transfer of synchronisation information (this might give >backward compatibility problems). We're using email for transfer of LDIF files. The Common Indexing Protocol(CIPv3) can be used to transfer replication info. CIPv3 can use SMTP as transport. So this type of transport is actually quite useful, simple and fast to implement. Why not develop a binary LDIF format as well? Define an ASN.1 syntax for LDIF encoded in BER. (Could be very much like the LDAP syntax.) No-brainer to parse, and relatively compact. If someone wants to send it over SMTP, it could be encoded further to base64, uuencode, or whatever that someone preferrs. >- It may not be necessary to transfer the complete distinguished name >for entries if entry information is transferred in some particular >sequence much as it is done in the X.500 shadowing format. (However, a >text oriented format does not allow for a structured data types, such as >it is possible in an ASN.1 encoded string. It is therefore not possible >to make it as elegant as it is done for the X.500 shadowing format.) > >Now to the real hard problem by giving an example: > >Erik Andersen, as a residential person, has two telephone numbers. One >fixed telephone number with Tele Denmark and a mobile telephone number >with Sonofon. Now, if Sonofon transfer its telephone number information >to Tele Denmark, how will Tele Denmark be able to merge the two pieces >of information into a single entry? How do we allocate distinguished >names to residential persons? The only viable idea is to use social >security numbers or some other unique identifiers, which would just be >an alias for a social security number. People are quite sensitive with >respect to use of social security numbers - the Big Brother syndrome. >The current solution today in a Danish e-mail directory is to have a >complete flat name space below a postal district. When a service >provider today stores information about a subscriber in a directory, it >gives the qualifier '1' to the first Erik Andersen he comes upon, number >'2' to the next one etc. (there are plenty of them). The same Erik >Andersen will get different qualifiers by different service providers, >so the distinguished name is service provider specific and cannot be >used for merging of information. >Merging will have to be based on comparison of some key attributes. What >those key attributes are, will depend on the particular situation. If a >secure comparison cannot be made, a new entry will be created. This problem is due to the way you uniquely identify a record in LDAP/X.500. I have no idea how to solve this problem nicely (I've encountered it myself). Right now we're just using heuristics to guess which records should be merged, just like you described. Best regards, Paul ----------------------------------------------------------------------- Paul Panotzki Phone: +46 8 730 30 98 Object Zone AB Fax: +46 8 444 61 28 ----------------------------------------------------------------------- From owner-ietf-ldup Sat Dec 13 07:21:44 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA07290 for ietf-ldup-bks; Sat, 13 Dec 1997 07:21:44 -0800 (PST) Received: from folder.critical-angle.com (eden-gw.critical-angle.com [206.81.238.241]) by mail.proper.com (8.8.7/8.7.3) with SMTP id HAA07283 for ; Sat, 13 Dec 1997 07:21:39 -0800 (PST) Received: (qmail 3146 invoked from network); 13 Dec 1997 15:19:11 -0000 Received: from folder.critical-angle.com (206.81.238.241) by folder.critical-angle.com with SMTP; 13 Dec 1997 15:19:11 -0000 From: Mark Wahl To: Peter Coates cc: ietf-ldup@imc.org Subject: Re: More on interchange formats In-reply-to: Your message of "Fri, 12 Dec 1997 17:09:20 PST." <01IR3E6CGZP49TD78D@INNOSOFT.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 13 Dec 1997 09:19:10 -0600 Message-ID: <3144.882026350@folder.critical-angle.com> Sender: owner-ietf-ldup@imc.org Precedence: bulk > Is the current delta form of LDIF actually being used? Obviously the > absolute form is, but I'm less certain of the delta form. Yes, it is used in the change log. The generation of changerecords by the LDAP server is straightforward. In draft-ietf-asid-ldif-02: There is a one-to-one correlation between LDAP operations which modify the directory (add, delete, modify, and modrdn), and the types of changerecords described below ("add", "delete", "modify", and "modrdn" or "moddn"). This correspondence is intentional, and permits a straightforward translation from LDIF changerecords to protocol operations. Mark Wahl, Enterprise Directory Integration Critical Angle Inc. From owner-ietf-ldup Mon Dec 15 05:29:56 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id FAA06333 for ietf-ldup-bks; Mon, 15 Dec 1997 05:29:56 -0800 (PST) Received: from arista.iris.com (arista.iris.com [198.112.211.22]) by mail.proper.com (8.8.7/8.7.3) with SMTP id FAA06327 for ; Mon, 15 Dec 1997 05:29:52 -0800 (PST) From: Bob_Huston@iris.com Received: by arista.iris.com(Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997)) id 8525656E.004AA2B9 ; Mon, 15 Dec 1997 08:35:13 -0500 X-Lotus-FromDomain: IRIS To: ietf-ldup@imc.org Message-ID: <8525656E.004A4200.00@arista.iris.com> Date: Mon, 15 Dec 1997 08:32:16 -0500 Subject: Re: More on interchange formats Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ldup@imc.org Precedence: bulk >>The current LDIF format could be made more compact by: >> >>- When specifying the objectClass attribute, it should only be necessary >>to specify the object classes from which the entry is directly derived. >>Any superior object classes could be implied, as the object class >>inheritance hierarchy should be known by the receiver. As an example, >>for an organizationalPerson it should not be necessary to specify the >>person and top object classes as well. >This could be OK. Although, if you're using custom object classes (like say >myOrgPerson SUP person SUP top) other directories will not be able to >import your LDIF file. So you should at least include an object class that >is "well known". I.e "person" would be required in the my example, but top >wouldn't. In your example, using organizationalPerson would be enough, as >it is "well known". This is not necessarily true. One of the main objectives to getting ldap dir synch to work will be to ensure that extended and customized schemas will be accounted for. At the recent BOF opinions were expressed along the lines of not including these non-standard schema objects severly restricts the usefullness of dir synch. If we work out a way to register your schema, then having a custom object class like myOrgPerson would be ok, all servers participating in the dir synch would have at least a base understanding of the extended object. Bob Huston Iris Associates. From owner-ietf-ldup Mon Dec 15 07:55:59 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA08465 for ietf-ldup-bks; Mon, 15 Dec 1997 07:55:59 -0800 (PST) Received: from ip78.129.isdn.hogia.net (ip78.129.isdn.hogia.net [195.78.129.78]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id HAA08461 for ; Mon, 15 Dec 1997 07:55:51 -0800 (PST) Received: from [195.78.129.68] by ip78.129.isdn.hogia.net with SMTP (QuickMail Pro Server for MacOS 1.0.2a7); 15 DEC 97 17:56:51 UT X-Sender: paul@mail.objectzone.se Message-Id: In-Reply-To: <8525656E.004A4200.00@arista.iris.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 15 Dec 1997 16:58:01 +0100 To: Bob_Huston@iris.com From: Paul Panotzki Subject: Re: More on interchange formats Cc: ietf-ldup@imc.org Sender: owner-ietf-ldup@imc.org Precedence: bulk At 14.32 +0100 97-12-15, Bob_Huston@iris.com wrote: >>>The current LDIF format could be made more compact by: >>> >>>- When specifying the objectClass attribute, it should only be necessary >>>to specify the object classes from which the entry is directly derived. >>>Any superior object classes could be implied, as the object class >>>inheritance hierarchy should be known by the receiver. As an example, >>>for an organizationalPerson it should not be necessary to specify the >>>person and top object classes as well. > >>[Paul said:] >>This could be OK. Although, if you're using custom object classes (like >say >>myOrgPerson SUP person SUP top) other directories will not be able to >>import your LDIF file. So you should at least include an object class that >>is "well known". I.e "person" would be required in the my example, but top >>wouldn't. In your example, using organizationalPerson would be enough, as >>it is "well known". > >This is not necessarily true. One of the main objectives to getting ldap >dir synch to work will be to ensure that extended and customized schemas >will be accounted for. At the recent BOF opinions were expressed along >the lines of not including these non-standard schema objects severly >restricts the usefullness of dir synch. If we work out a way to register >your schema, then having a custom object class like myOrgPerson would be >ok, >all servers participating in the dir synch would have at least a base >understanding of the extended object. I'm not sure what you mean about registration. Fine, as long as that information is available in the LDIF file itself. For instance, somewhere in the begining of the LDIF file you could have something specifying the inheritance: myOrgPerson -> organizationalPerson -> person -> top Then a directory service which doesn't know what a myOrgPerson is, could still use the data to create organizationalPerson objects, discarding/ignoring those attributes that are new in myOrgPerson Best regards, Paul ----------------------------------------------------------------------- Paul Panotzki Phone: +46 8 730 30 98 Object Zone AB Fax: +46 8 444 61 28 ----------------------------------------------------------------------- From owner-ietf-ldup Mon Dec 15 07:27:44 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA08160 for ietf-ldup-bks; Mon, 15 Dec 1997 07:27:44 -0800 (PST) Received: from fl.dk (ns.fl.dk [193.88.152.146]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id HAA08155 for ; Mon, 15 Dec 1997 07:27:36 -0800 (PST) Received: by gw.fl.dk id <26886-2>; Mon, 15 Dec 1997 16:29:29 +0100 Message-Id: <97Dec15.162929gmt+0100.26886-2@gw.fl.dk> From: Erik Andersen To: "'LDUP'" Cc: Tom Skovgaard Subject: Extended "LDIF" format Date: Mon, 15 Dec 1997 16:30:35 +0100 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldup@imc.org Precedence: bulk As promised, I have worked on a suggestion for an extension to LDIF that could fulfil our requirements. It is not complete. It needs at least some more work on uddate operations. For different notes, I have seen some concerns about the current format for updates. Updates is centainly very important to us. However, I am including the initial work for comments to get some feed back on whether I am on a completely wrong track. ------------------------------------------------------------------------ ----------------------------- This note suggests some changes to the current LDIF format to extend its usability to more areas. It should be read as a delta to the current Internet draft. The note is not in the form of an Internet draft. It is put up on the LDUP mailing list for comments. ------------------------------------------------------------------------ ----- Background and Intended Usage (addition) Different directory systems may hold different pieces of directory information about the same object. Such systems may have a requirement to update each other or to update a central directory system to merge all relevant information. In some cases it may be difficult to have a common scheme for allocating distinguished names. As an example, it may be possible to get some agreement on how a country should be structured into some hierarchy of localities. However, it is quite difficult to allocate RDNs for residential persons common for all directory system. Formal Syntax Definition of LDIF The following definition uses the augmented Backus-Naur Form specified in RFC 822 [2]. ldif-file = ldif-content / ldif-changes ldif-content = ["total" 1*SEP] heading own-content [other-content] ldif-changes = ["incremental" 1*SEP] heading own-change [other-change] heading = 0,1*(["total" SPACE] version-spec 1*SEP) ["agreement-id:" *SPACE agreement-id 1*SEP] agreement-id = 1*safe-initval own-content = ["own" 1*SEP] ldif-attrval-record *(1*SEP ldif-attrval-record) other-content = "other" 1*SEP ldif-attrval-record *(1*SEP ldif-attrval-record) own-change = ["own" 1*SEP] ldif-change-record *(1*SEP ldif-change-record) other-change = "other" 1*SEP ldif-change-record *(1*SEP ldif-change-record) ldif-attrval-record = dn-spec SEP 1*(attrval-spec) ldif-change-record = dn-spec SEP 1*(changerecord SEP) version-spec = "version:" *SPACE version-number version-number = 1*DIGIT ; version-number MUST be "2" for the ; LDIF format described in this document. dn-spec = ("dn:" *SPACE dn) / ("dn::" *SPACE base64-dn) / ("sup:" *SPACE dn) / "sup::" *SPACE base64-dn) dn = base64-dn = rdn = base64-rdn = attrval-spec = attribute-description ((":") / (":" *SPACE value *(*SPACE "\" *SPACE value)) / ("::" *SPACE base64-value *(*SPACE "\" *SPACE base64-value)) / (":<" *SPACE url*(*SPACE "\" *SPACE url))) url = ; (See Note 6, below) attribute-description = charset-option = "charset=" ( "*" / charset-name ) charset-name = a character set name, as registered with IANA [10] value = 1*safe-initval *safe safe = safe-initval = base64-value = changerecord = change-add / change-delete / change-modify / change-moddn change-add = "changetype:" *SPACE "add" 1*(SEP attrval-spec) change-delete = "changetype:" *SPACE "delete" change-moddn = "changetype:" *SPACE ("modrdn" / "moddn") SEP ("newrdn:" *SPACE rdn / "newrdn::" *SPACE base-64-rdn) SEP "deleteoldrdn:" *SPACE ("0" / "1") 0,1*(SEP (("newsuperior:" *SPACE dn) / ("newsuperior:: *SPACE base-64-dn))) change-modify = "changetype:" *SPACE "modify" 1*(SEP mod-spec) mod-spec = mod-add-spec / mod-delete-spec / mod-replace-spec mod-add-spec = "add:" *SPACE attribute-description 1*(SEP attrval-spec) SEP "-" mod-delete-spec = "delete:" *SPACE attribute-description *(SEP attrval-spec) SEP "-" mod-replace-spec = "replace:" *SPACE attribute-description *(SEP attrval-spec) SEP "-" SPACE = SEP = (CR LF / LF) CR = LF = DIGIT = Agreements An agreement ID can optionally be in the first part of an LDIF file. This agreement specification can be used to give a unique identification of the scope of an information exchange. Such an agreement can be include such things as: 1) What information has to be transferred and possibly kept updated by the sender. 2) The attribute types and object classes that are part of the transport including what textual representations are going to use. In case of high-volume exchanges, the two parties can agree on an abbreviated form of textual representation. As an example "tel" could be an abbreviated form of TelephoneNumber. 3) An understanding of what information is necessary to transfer to aid in the correlation process. 4) How much of a distinguished name that needs to be transferred. As an example, the country name could have a default value. 5) How much information that is needed for the objectClass attribute. If the object class for the entry information is, say, residentialPerson, it may not be necessary also to specify the super-classes person and top. They could be implied. 6) Agreement on not to use spaces where they are optional. 6) Update frequency. Establishment of an agreement is a completely off-line activity not directly reflected in the protocol. If there is no agreement-id specified, an implied agreement is assumed. There can only be one implicit agreement between a particular sender and a particular recipient. Note on LDIF syntax and usage 1) The "total" specification indicates that all information related to the agreement should be purged and replaced by the information in the current transfer. This does not necessarily mean that current entries are deleted during the first part of this process as there may be local information or information from other agreements within those entries. 2) When doing incremental updates, a "delete" record MUST contain sufficient information to allow locating the entry in question. The delete operation only applies to the part of the entry holding information owned by the sender according to the agreement. 3) The optional "own" specification starts a block of information for which the sender is master, and which by the receiver can be added to its local database or update previously received information. As an example, a mobile telephone number allocated by a mobile telephone operator is owned by that operator and will be present in this block when this mobile operator is transmitting information to other parties. 4) The optional "other" specification starts a block of information assumed to be owed by other organisations or systems, which could include the receiver of the information. This information is primarily intended for identifying an already existing entry. As an example, a mobile operator may supply the fixed telephone number in a record, although the fixed telephone is subscribed from another operator. If there is information in this block that is currently not present at the recipient, it a local option for the receiver whether to store it or dispose of it in any other way. 5) Any attribute information placed before an "own" or an "other" specification is considered part of the "own" part. If none of the two specifications are present, all attribute information is considered "own" information. 6) The "dn" is the distinguished name of the entry. This is not a mandatory field. However, if this field is not present, the "sup" field MUST be explicitly or implicitly present. This filed MUST NOT be present if the "sup" field is present. This field shall only be used if the complete distinguished name is understood by both parties to denote the same object. As an example, the name of a reasonable seize company is assumed to be unique within a certain geographical area. This field MUST be used if the entry has subordinate entries. 7) The "sup" is the distinguished name of the superior entry. This field can only be used for leaf entries, e.g. residential persons, and it shall only be used if it not possible to establish a distinguished name that is globally recognised. When this field is present, it is assumed that the receiver of the information can from other included information, e.g. name, telephone number, postal address, etc. can determine whether the object is already present and should be updated 8) If both the "dn" and the "sup" specifications are absent, it is treated as an implicit "sup" specification being equal to the one in the previous record. Such an implicit "sup" specification is only allowed if the previous record did not have en "dn" specification. 9) For multi-valued attribute types, it is possible either to put all values on a single line or include a line for each attribute value. Differences from Version 1 of LDIF 1) It is possible in a header besides giving version information to indicate whether an LDIF file is a complete transfer of all information or whether is an updating file 2) It is possible in the header to optionally indicate an agreement ID in case two parties have several agreements on exchanging synchronization information. 3) It is possible for each record to indicate two different blocks of information. One block, where the transmitter is the master for the information and one block of information where other systems have the master role, but is information that can be used for correlation. 4) It is possible to only transfer the distinguished name of the superior of an entry in case the receiver is expected to generate the complete distinguished following local algorithms. 5) Several values for a multi-valued attribute can be on the same, possibly folded line. The separator between values is a back-slash ("\") Examples of LDAP Interchange Format Example 1: A simple LDIF file with a few records sent from a mobile telephone operator to some central information service total version 2 agreement-id: op1-to-op2, ver.1 dn:dn:o=F&L,c=DK own mobile:+4533333333\+4544444444 other tel:+4539450700 fax:+4539450777 dn:cn=Tom Finkelstein,o=F&L,c=DK own mobile:+4512345678 other objcl:orgPers sn:Finkdelstein tel:+4539450999 822:tfs@fl.dk sup:loc=1815,sOpName=Copenhagen own mobile:+4520971490 other sn:Andersen gn:Erik street:Paludan Mullersvej num:3 floor:2 floorentity:tv city:Frederiksberg tel:+4531230490 own mobile:+4587654321 other sn:Petersen gn:Peter street:Paludan Mullersvej num:5 floor:3 city:Frederiksberg tel:+4523456789 From owner-ietf-ldup Mon Dec 15 08:13:45 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA08714 for ietf-ldup-bks; Mon, 15 Dec 1997 08:13:45 -0800 (PST) Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.7/8.7.3) with SMTP id IAA08710 for ; Mon, 15 Dec 1997 08:13:39 -0800 (PST) Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Mon, 15 Dec 1997 09:10:57 -0700 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Mon, 15 Dec 1997 09:10:29 -0700 From: Ed Reed To: ietf-ldup@imc.org, Bob_Huston@iris.com Subject: Re: More on interchange formats Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: owner-ietf-ldup@imc.org Precedence: bulk In the spirit of schema synchronization (;-) I'd really like to see an extended LDIF format that includes schema representation in an agreed-to meta-schema format that could be (should be/must be, whatever) prepended to any LDIF file that includes objects/attributes which are extensions beyond some agreed-to base schema. As an optimization, servers could simply reference the extensions, and provide the meta-schema representation if a response from the receiving server indicates they lack understanding of the noted extension and would like to receive the sending servers interpretation. This would kill two birds with one stone: 1) establish general use of the ldap meta-schema representation used by the listing service for real-time, interactive update operations between coooperating servers, 2) provide a means to propagate locally initiated extensions of schema among cooperating servers even in the absense of a listing in the listing server, or connectivity thereto. Not every system administrator using LDAP extended schema will know about or care about the listing service, and I'm not at all sure we want 152,328 different variations on the Employee user class registered, even if they know about the service. Extending the LDIF format to include the ability to provide the schema extension would be generally useful, no? Even as a way to dynamically extend the schema on servers which support such a thing? Ed ------------------- Ed Reed, Chief Architect Network Services Group Novell, Inc. +1 801 861 3320 >>> 12/15/1997 06:32:16 >>> >>The current LDIF format could be made more compact by: >> >>- When specifying the objectClass attribute, it should only be necessary >>to specify the object classes from which the entry is directly derived. >>Any superior object classes could be implied, as the object class >>inheritance hierarchy should be known by the receiver. As an example, >>for an organizationalPerson it should not be necessary to specify the >>person and top object classes as well. >This could be OK. Although, if you're using custom object classes (like say >myOrgPerson SUP person SUP top) other directories will not be able to >import your LDIF file. So you should at least include an object class that >is "well known". I.e "person" would be required in the my example, but top >wouldn't. In your example, using organizationalPerson would be enough, as >it is "well known". This is not necessarily true. One of the main objectives to getting ldap dir synch to work will be to ensure that extended and customized schemas will be accounted for. At the recent BOF opinions were expressed along the lines of not including these non-standard schema objects severly restricts the usefullness of dir synch. If we work out a way to register your schema, then having a custom object class like myOrgPerson would be ok, all servers participating in the dir synch would have at least a base understanding of the extended object. Bob Huston Iris Associates. From owner-ietf-ldup Mon Dec 15 08:45:24 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA09101 for ietf-ldup-bks; Mon, 15 Dec 1997 08:45:24 -0800 (PST) Received: from bbmail1.unisys.com (192-63-2005.unisys.com [192.63.200.5]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA09097 for ; Mon, 15 Dec 1997 08:45:18 -0800 (PST) Received: from trsvr.tr.unisys.com (trsvr.tr.unisys.com [192.63.216.7]) by bbmail1.unisys.com (8.8.5/8.8.5) with ESMTP id QAA02485 for ; Mon, 15 Dec 1997 16:47:30 GMT Received: from tr-exchange-2.tr.unisys.com by trsvr.tr.unisys.com (8.6.12/8.6.12) id QAA09008 ; Mon, 15 Dec 1997 16:47:25 GMT Received: by tr_exchange_2.tr.unisys.com with Internet Mail Service (5.0.1458.49) id ; Mon, 15 Dec 1997 11:48:22 -0500 Message-ID: <7B5973973C58D111BE4400600837760B3BCB31@tr-exchange-1.tr.unisys.com> From: "Salter, Thomas A" To: ietf-ldup@imc.org Subject: RE: More on interchange formats Date: Mon, 15 Dec 1997 11:46:28 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldup@imc.org Precedence: bulk Most of this definition is already done. Since Ldap V3 defines subschema objects, it falls out that there is an LDIF representation of schema information. What I think is missing is a consistent way of constraining the subschema information to pertain to a particular set of objects, as X.500 does through subtrees, or perhaps an operational attribute that links an entry to a particular subschema. > ---------- > From: Ed Reed[SMTP:ED_REED@novell.com] > Sent: Monday, December 15, 1997 11:10 AM > To: ietf-ldup@imc.org; Bob_Huston@iris.com > Subject: Re: More on interchange formats > > In the spirit of schema synchronization (;-) I'd really like to see an > extended LDIF format that includes schema representation in an > agreed-to meta-schema format that could be (should be/must be, > whatever) prepended to any LDIF file that includes objects/attributes > which are extensions beyond some agreed-to base schema. As > an optimization, servers could simply reference the extensions, and > provide the meta-schema representation if a response from the > receiving server indicates they lack understanding of the noted > extension and would like to receive the sending servers > interpretation. > > This would kill two birds with one stone: > > 1) establish general use of the ldap meta-schema representation used > by the listing service for real-time, interactive update operations > between > coooperating servers, > 2) provide a means to propagate locally initiated extensions of schema > among cooperating servers even in the absense of a listing in the > listing > server, or connectivity thereto. > > Not every system administrator using LDAP extended schema will know > about or care about the listing service, and I'm not at all sure we > want > 152,328 different variations on the Employee user class registered, > even > if they know about the service. Extending the LDIF format to include > the ability to provide the schema extension would be generally useful, > no? > Even as a way to dynamically extend the schema on servers which > support such a thing? > > Ed > > ------------------- > Ed Reed, Chief Architect > Network Services Group > Novell, Inc. > +1 801 861 3320 > > >>> 12/15/1997 06:32:16 >>> > > >>The current LDIF format could be made more compact by: > >> > >>- When specifying the objectClass attribute, it should only be > necessary > >>to specify the object classes from which the entry is directly > derived. > >>Any superior object classes could be implied, as the object class > >>inheritance hierarchy should be known by the receiver. As an > example, > >>for an organizationalPerson it should not be necessary to specify > the > >>person and top object classes as well. > > >This could be OK. Although, if you're using custom object classes > (like > say > >myOrgPerson SUP person SUP top) other directories will not be able to > >import your LDIF file. So you should at least include an object class > that > >is "well known". I.e "person" would be required in the my example, > but top > >wouldn't. In your example, using organizationalPerson would be > enough, as > >it is "well known". > > This is not necessarily true. One of the main objectives to getting > ldap > dir synch to work will be to ensure that extended and customized > schemas > will be accounted for. At the recent BOF opinions were expressed along > the lines of not including these non-standard schema objects severly > restricts the usefullness of dir synch. If we work out a way to > register > your schema, then having a custom object class like myOrgPerson would > be > ok, > all servers participating in the dir synch would have at least a base > understanding of the extended object. > > Bob Huston > Iris Associates. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-ietf-ldup Mon Dec 15 13:36:16 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA13175 for ietf-ldup-bks; Mon, 15 Dec 1997 13:36:16 -0800 (PST) Received: from insanus.matematik.su.se (root@insanus.matematik.su.se [130.237.198.12]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA13171 for ; Mon, 15 Dec 1997 13:36:11 -0800 (PST) Received: from localhost (leifj@uggla.matematik.su.se [130.237.198.17]) by insanus.matematik.su.se (8.8.8/8.6.9) with ESMTP id WAA23844; Mon, 15 Dec 1997 22:38:29 +0100 (MET) Message-Id: <199712152138.WAA23844@insanus.matematik.su.se> X-Address: Department of Mathematics, Stockholm University S-106 91 Stockholm SWEDEN X-Phone: int+46 8 162000 X-Fax: int+46 8 6126717 X-Url: http://www.matematik.su.se To: Paul Panotzki cc: Bob_Huston@iris.com, ietf-ldup@imc.org Subject: Re: More on interchange formats In-reply-to: Your message of "Mon, 15 Dec 1997 16:58:01 +0100." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18717.882221907.1@matematik.su.se> Date: Mon, 15 Dec 1997 22:38:28 +0100 From: Leif Johansson Sender: owner-ietf-ldup@imc.org Precedence: bulk >I'm not sure what you mean about registration. Fine, as long as that >information is available in the LDIF file itself. For instance, somewhere >in the begining of the LDIF file you could have something specifying the >inheritance: I believe that registration should be taken to mean registration of the schema with the IANA schema registration service for which there is soon a wg in the ietf. Best Regards Leif Johansson Leif Johansson Phone: +46 8 164541 Department of Mathematics Fax : +46 8 6126717 Stockholm University email: leifj@matematik.su.se From owner-ietf-ldup Tue Dec 16 04:08:38 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id EAA23644 for ietf-ldup-bks; Tue, 16 Dec 1997 04:08:38 -0800 (PST) Received: from ip78.129.isdn.hogia.net (ip78.129.isdn.hogia.net [195.78.129.78]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id EAA23640 for ; Tue, 16 Dec 1997 04:08:33 -0800 (PST) Received: from [195.78.129.68] by ip78.129.isdn.hogia.net with SMTP (QuickMail Pro Server for MacOS 1.0.2a7); 16 DEC 97 14:09:33 UT X-Sender: paul@mail.objectzone.se Message-Id: In-Reply-To: <199712152138.WAA23844@insanus.matematik.su.se> References: Your message of "Mon, 15 Dec 1997 16:58:01 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 16 Dec 1997 13:10:44 +0100 To: ietf-ldup@imc.org From: Paul Panotzki Subject: Re: More on interchange formats Sender: owner-ietf-ldup@imc.org Precedence: bulk At 22.38 +0100 97-12-15, Leif Johansson wrote: >>I'm not sure what you mean about registration. Fine, as long as that >>information is available in the LDIF file itself. For instance, somewhere >>in the begining of the LDIF file you could have something specifying the >>inheritance: > >I believe that registration should be taken to mean registration of the >schema with the IANA schema registration service for which there is soon >a wg in the ietf. That's what I'm afraid of. (The registration, that is. Not the wg.) -Paul ----------------------------------------------------------------------- Paul Panotzki Phone: +46 8 730 30 98 Object Zone AB Fax: +46 8 444 61 28 ----------------------------------------------------------------------- From owner-ietf-ldup Tue Jan 6 08:20:24 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA17201 for ietf-ldup-bks; Tue, 6 Jan 1998 08:20:24 -0800 (PST) Received: from fl.dk (ns.fl.dk [193.88.152.146]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA17197 for ; Tue, 6 Jan 1998 08:20:18 -0800 (PST) Received: by gw.fl.dk id <26882-3>; Tue, 6 Jan 1998 17:25:04 +0100 Message-Id: <98Jan6.172504gmt+0100.26882-3@gw.fl.dk> From: Erik Andersen To: "'LDUP'" Subject: Extended LDIF Date: Tue, 6 Jan 1998 17:25:22 +0100 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ietf-ldup@imc.org Precedence: bulk Just before Christmas I put on the list an initial proposal for an extend the LDIF format to suit some elaborate needs. I have gotten no reactions so far. In the meantime, I have worked on the subject. I found several errors in the first proposal. The intention has been to maintain backward compatibility, i.e. a system supporting the extended format will also (if I got it right) support version 1. A system supporting the extended version could also be customized to transmit only a version 1 file. As mentioned earlier, we need a interchange format for exchanging telephone number information among telephone operators and for collection of all information in a central repository. The current LDIF does not cover our requirements and we have found no other standardised format that does. On the 15th this month we will have the first meeting on the subject. I have been charged with making a proposal for an interchange format. The action is initiated and funded by the Danish Ministry for Research and Information Technology. It is my intention, unless I am greatly discouraged by responses, to propose the included extended format possibly amended due to comments and found mistakes. As I believe that others may or will in the future experience the same requirement as we have, a standardised approached is much to desire. It will also allow vendors of LDIF products to expand into new areas. As you can gather, I do have a heavy desire for comments from experts in the field. Erik Andersen Fischer & Lorenz Telecommunications Consultency Denmark From owner-ietf-ldup Mon Jan 12 01:43:39 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id BAA06002 for ietf-ldup-bks; Mon, 12 Jan 1998 01:43:39 -0800 (PST) Received: from fl.dk (ns.fl.dk [193.88.152.146]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id BAA05998 for ; Mon, 12 Jan 1998 01:43:28 -0800 (PST) Received: by gw.fl.dk id <26884-4>; Mon, 12 Jan 1998 10:48:58 +0100 Message-Id: <98Jan12.104858gmt+0100.26884-4@gw.fl.dk> From: Erik Andersen To: "'LDUP'" , "'Gordon Good'" Subject: FW: Extended LDIF Date: Mon, 12 Jan 1998 10:48:20 +0100 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BD1F47.99D034A0" Sender: owner-ietf-ldup@imc.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_000_01BD1F47.99D034A0 Content-Type: text/plain Hi Folks, Apparently, I forgot to include the file. Sorry about that. Also, in a note Gordon has stated that records are separated by two new lines. I have not been able to gather that from the current LDIF specification, which may easily be a shortcoming of mine. This would require some small changes as indicated by temporary notes in the text. Kind regards, Erik > -----Original Message----- > From: Erik Andersen > Sent: 6. januar 1998 17:25 > To: 'LDUP' > Subject: Extended LDIF > > Just before Christmas I put on the list an initial proposal for an > extend the LDIF format to suit some elaborate needs. I have gotten no > reactions so far. In the meantime, I have worked on the subject. I > found several errors in the first proposal. > > The intention has been to maintain backward compatibility, i.e. a > system supporting the extended format will also (if I got it right) > support version 1. A system supporting the extended version could also > be customized to transmit only a version 1 file. > > As mentioned earlier, we need a interchange format for exchanging > telephone number information among telephone operators and for > collection of all information in a central repository. The current > LDIF does not cover our requirements and we have found no other > standardised format that does. > > On the 15th this month we will have the first meeting on the subject. > I have been charged with making a proposal for an interchange format. > The action is initiated and funded by the Danish Ministry for Research > and Information Technology. It is my intention, unless I am greatly > discouraged by responses, to propose the included extended format > possibly amended due to comments and found mistakes. > > As I believe that others may or will in the future experience the same > requirement as we have, a standardised approached is much to desire. > It will also allow vendors of LDIF products to expand into new areas. > > As you can gather, I do have a heavy desire for comments from experts > in the field. > > Erik Andersen > Fischer & Lorenz Telecommunications Consultency > Denmark ------ =_NextPart_000_01BD1F47.99D034A0 Content-Type: text/plain; name="LDIF_EXT.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="LDIF_EXT.txt" This note suggests some changes to the current LDIF format to extend = its=20 usability to more areas. It should be read as a delta to the current = Internet=20 draft. The note is not in the form of an Internet draft. It is put up = on the=20 LDUB mailing list for comments. ------------------------------------------------------------------------= ----- Background and Intended Usage (addition) Different directory systems may hold different pieces of directory=20 information about the same object. Such systems may have a = requirement to=20 update each other or to update a central directory system to merge = all=20 relevant information. A record that is sent by one system to another may represent a = complete=20 entry by the transmitter. However, the recipient may already have=20 information about the object in question. Adding a new entry through = LDIF=20 may not actually cause creation of a new entry, but may add = information to=20 an already existing entry. In this case, the recipient will have to=20 perform correlation by different means to try to locate an existing = entry=20 corresponding to the received record. If a globally unique = distinguished=20 name is transferred, correlation is straightforward. However, if = such a=20 distinguished name is not available, additional information carried = in the=20 record may be used for this correlation. It is application dependent = what=20 information that is then necessary. A high level of correlation=20 accurateness is necessary not to corrupt the directory information. In some cases it may be difficult to have a common scheme for = allocating=20 distinguished names. As an example, it may be possible to get some=20 agreement on how a country should be structured into some hierarchy = of=20 localities. However, it is quite difficult to allocate RDNs for=20 residential persons common to all directory systems. Formal Syntax Definition of LDIF The following definition uses the augmented Backus-Naur Form specified in RFC 822 [2]. ldif-file =3D ldif-content / ldif-changes ldif-content =3D ["total" 1*SEP] heading own-content [other-content] ldif-changes =3D ["incremental" 1*SEP] heading own-change [own-content] [other-content] heading =3D 0,1*(["total" SPACE] version-spec 1*SEP) ["agreement-id:" *SPACE agreement-id 1*SEP] agreement-id =3D 1*safe-initval own-content =3D ["own" 1*SEP]=20 ldif-attrval-record *(1*SEP = ldif-attrval-record) other-content =3D "other" 1*SEP=20 ldif-attrval-record *(1*SEP = ldif-attrval-record) own-change =3D ["own" 1*SEP]=20 ldif-change-record *(1*SEP = ldif-change-record) ldif-attrval-record =3D dn-spec SEP 1*(attrval-spec) ldif-change-record =3D dn-spec SEP 1*(changerecord SEP) version-spec =3D "version:" *SPACE version-number version-number =3D 1*DIGIT ; version-number MUST be "2" for = the ; LDIF format described in this = document. dn-spec =3D ("dn:" *SPACE dn) / ("dn::" *SPACE = base64-dn) / ("dn:" *SPACE 1*DIGIT rdn *(("," / ";") *SPACE rdn)) / ("dn::" *SPACE 1*DIGIT base64-rdn *(("," / ";") *SPACE base64-rdn )) / ("s:" *SPACE dn) / ("s::" *SPACE base64-dn) dn =3D base64-dn =3D rdn =3D base64-rdn =3D attrval-spec =3D attribute-description ((":") / (":" *SPACE value *(*SPACE "\" *SPACE = value)) / ("::" *SPACE base64-value=20 *(*SPACE "\" *SPACE base64-value)) / (":<" *SPACE url*(*SPACE "\" *SPACE url))) url =3D ; (See Note 6, below) attribute-description =3D charset-option =3D "charset=3D" ( "*" / charset-name ) charset-name =3D a character set name, as registered with = IANA [10] value =3D 1*safe-initval *safe safe =3D safe-initval =3D base64-value =3D changerecord =3D change-add / change-delete / change-modify = / change-moddn change-add =3D "changetype:" *SPACE "add" 1*(SEP = attrval-spec) change-delete =3D "changetype:" *SPACE "delete" change-moddn =3D "changetype:" *SPACE ("modrdn" / "moddn") = SEP ("newrdn:" *SPACE rdn / "newrdn::" *SPACE base-64-rdn) SEP "deleteoldrdn:" *SPACE ("0" / "1") 0,1*(SEP (("newsuperior:" *SPACE dn) / ("newsuperior:: *SPACE base-64-dn))) change-modify =3D "changetype:" *SPACE "modify" 1*(SEP = mod-spec) mod-spec =3D mod-add-spec / mod-delete-spec / = mod-replace-spec mod-add-spec =3D "add:" *(*SPACE attribute-description) 1*(SEP attrval-spec) SEP "-" mod-delete-spec =3D "delete:" *(*SPACE attribute-description) *(SEP attrval-spec) SEP "-" mod-replace-spec =3D "replace:" *(*SPACE attribute-description) *(SEP attrval-spec) SEP "-" SPACE =3D SEP =3D (CR LF / LF) CR =3D LF =3D DIGIT =3D Agreements An agreement ID can optionally be in the first part of an LDIF file. = This=20 agreement specification can be used to give a unique identification = of the=20 scope of an information exchange. Such an agreement can be include = such=20 things as: 1) What information has to be transferred and possibly kept updated = by the=20 sender. 2) The attribute types and object classes that are part of the = transport=20 including what textual representations are going to be used. In case = of=20 high-volume exchanges, the two parties can agree on an abbreviated = form of=20 textual representation. As an example "tel" could be an abbreviated = form=20 of TelephoneNumber. 3) An understanding of what information is necessary to transfer to = ensure=20 the correlation process, i.e. locating an existing entry, if any. 4) How much of a distinguished name that needs to be transferred. As = an=20 example, the country name could have a default value. 5) How much information that is needed for the objectClass = attribute. If=20 the object class for the entry information is, say, = residentialPerson, it=20 may not be necessary also to specify the super-classes person and = top.=20 They could be implied. 6) Agreement on not to use spaces where they are optional. 7) Update frequency. Establishment of an agreement is a completely off-line activity not=20 directly reflected in the protocol. If there is no agreement-id specified, an implied agreement is = assumed.=20 There can only be one implicit agreement between a particular sender = and a=20 particular recipient. Note on LDIF syntax and usage 1) The "dn:" or the "s:" specification signals the start of a new = record.=20 The end of a record is implicitly signalled by the start of a new = record=20 or by the end of file. (Temporary note: From a message from Gordon, = I understand that the records are separated by two SEP fields. I have = not been able to gather that from the current LDIF specification. It may = be my lack of understanding the Backus-Nauer notation. I prefer the = separation by two SEP fields. This note should therefore probably be deleted.) 2) The "total" specification indicates that all information related = to the=20 agreement should be purged and replaced by the information in the = current=20 transfer. This does not necessarily mean that current entries are=20 completely deleted during the first part of this process as there = may be=20 local information or information from other agreements within those=20 entries. 3) When doing incremental updates: a) Only information owned by the sender can be changed. Additional = information may be transmitted to allow identification of the = entries to=20 be changed. If the "dn:" specification is used, only the = distinguished=20 name should be supplied in addition to change or delete = specifications to=20 ensure compatibility with earlier versions. For "s:" = specifications,=20 additional information will have to be supplied to identify the = entries in=20 question. b) Records without any "changetype" specification are to be = considered as=20 new entries to be added. c) A "delete" operation only applies to the part of the entry = holding=20 information owned by the sender according to the current = agreement. 4) The optional "own" specification starts a block of information, = for=20 which the sender is the master, and which by the receiver can be = added to=20 its local database or update previously received information. As an=20 example, a mobile telephone number allocated by a mobile telephone=20 operator is owned by that operator and will be present in this block = when=20 this mobile operator is transmitting information to other parties. 5) The optional "other" specification starts a block of information=20 assumed to be owed by other organisations or systems including the=20 recipient system. This information is primarily intended for = identifying=20 an already existing entry. As an example, a mobile operator may = supply the=20 fixed telephone number in a record, although the fixed telephone is=20 subscribed from another operator. If there is information in this = block=20 that is currently not present at the recipient, it a local option = for the=20 receiver whether to store it or dispose of it in any other way. 6) Any attribute information placed before an "own" or an "other"=20 specification is considered part of the "own" part. If none of the = two=20 specifications are present, all attribute information is considered = "own"=20 information. 7) In some cases it may not be possible to denote some pieces of=20 information belonging to anyone. As an example, object class=20 specification, postal address, etc. may be considered general = information=20 maintained independently by each system. If such information is not=20 consistent across systems, correlation may not be possible. Such = general=20 information should be in the "other" block. 8) The "dn" is the distinguished name of the entry. This is not a=20 mandatory field. However, if this field is not present, the "s" = field MUST=20 be explicitly or implicitly present. This filed MUST NOT be present = if the=20 "s" field is present. This field shall only be used if the complete=20 distinguished name is understood by both parties to denote the same=20 object. As an example, the name of a reasonable seized company is = assumed=20 to be unique within a certain geographical area. This field MUST be = used=20 if the entry has subordinate entries. 9) An abbreviated form of distinguished name may be used. This = abbreviated=20 form MUST NOT be used unless the preceding record has a "dn"=20 specification. The first item on in the abbreviated specification is = a=20 level indication telling how large a part of the distinguished name = of the=20 preceding record that is inherited. The remaining items are one or = more=20 RDNs that are prefixed the inherited part to get a complete = distinguished=20 name. 10) The "s" field gives the distinguished name of the superior = entry. This=20 field can only be used for leaf entries, e.g. residential persons, = and it=20 is used if it not possible to establish a distinguished name that is = globally recognised. When this field is present, it is assumed that = the=20 recipient from other included information, e.g. name, telephone = number,=20 postal address, etc. can determine whether the object is already = present=20 and should be updated. Otherwise, if an existing entry is not found, = the=20 receiver will generate an RDN based on local algorithms to produce a = complete distinguished name. 11) If "s" field has no associated value, the value is assumed to be = the=20 same as for the preceding record. (Temporary note: This note should probably be changed to say that if there is no "s" or "dn" = specification,=20 an "s" field is assumed having the same value as in the previous = record.=20 The absence of both the "dn" and the "s" specification, is only = allowed if=20 the previous record had an explicit or implicit "s" specification.) 12) For multi-valued attribute types, it is possible either to put = all=20 values on a single line or include a line for each attribute value. 13) If the object class attribute is not included for a record in a=20 "total" transfer, the value(s) is the same as for the previous = record. Differences from Version 1 of LDIF 1) It is possible in a header beside giving version information to=20 indicate whether an LDIF file is a complete transfer of all = information or=20 whether is an updating file 2) It is possible in the header to optionally indicate an agreement = ID in=20 case two parties have several agreements on exchanging = synchronization=20 information. 3) It is possible for each record to indicate two different blocks = of=20 information. One block, where the transmitter is the master for the=20 information and one block of information where other systems have = the=20 master role, but is information that can be used for correlation. 4) It is possible to only transfer the distinguished name of the = superior=20 of an entry in case the receiver is expected to generate the = complete=20 distinguished following local algorithms. 5) Several values for a multi-valued attribute can be on the same,=20 possibly folded line. The separator between values is a back-slash = ("\") Examples of LDAP Interchange Format Example 7: A simple LDIF file with a few records sent from a mobile=20 telephone operator to some central information service total version 2 agreement-id: op1-to-op2, ver.1 dn:o=3DF&L,c=3DDK own mobile:+4533333333\+4544444444 other tel:+4539450700 fax:+4539450777 =20 dn:2 cn=3DTom Finkelstein own mobile:+4512345678 other objcl:orgPers sn:Finkdelstein gn:Tom tel:+4539450999 822:tfs@fl.dk dn:2 cn=3DPer Futtesen own mobile:+4587654321 other sn:Futtesen gn:Per tel:+4539450998 822:tfs@fl.dk s:L=3D1815,ST=3DCopenhagen own mobile:+4520971490 other objcl:resPers sn:Andersen gn:Erik street:Paludan Mullersvej num:3 floor:2 floorentity:tv city:Frederiksberg tel:+4531230490 s: own mobile:+4587654321 other sn:Petersen gn:Peter street:Paludan Mullersvej num:114 floor:3 city:Frederiksberg tel:+4523456789 Example 8: A simple LDIF file with a few update records sent from a = mobile=20 telephone operator to some central information service incremental version 2 agreement-id: op1-to-op2, ver.1 # Delete an entry. The mobile number and the name is considered = sufficient=20 # information for locating the right entry s:L=3D1815,ST=3DCopenhagen own changetype:delete mobile:+4520971490 other sn:Andersen gn:Erik # Update existing entry s: own replace: mobile:+4587654321 mobile:+4598765432 - other sn:Petersen gn:Peter # Add new entry =20 s:L=3D1864,ST=3DCopenhagen own mobile:+4534567890 other objcl:resPers sn:Frederiksen gn:John street:Grundtvigsvej num:245 floor:5 floorentity:tv city:Frederiksberg tel:+4531230490 ------ =_NextPart_000_01BD1F47.99D034A0-- From owner-ietf-ldup Mon Jan 12 02:39:34 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id CAA07761 for ietf-ldup-bks; Mon, 12 Jan 1998 02:39:34 -0800 (PST) Received: from penrose.isocor.ie (penrose.isocor.ie [194.106.155.117]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id CAA07757 for ; Mon, 12 Jan 1998 02:39:27 -0800 (PST) Received: from paradise.isocor.ie (194.106.155.200) by penrose.isocor.ie; 12 Jan 1998 10:42:45 +0000 Received: from mcbain.isocor.ie (194.106.155.229) by paradise.isocor.ie (NPlex 2.0.066); 12 Jan 1998 10:42:58 +0000 Received: by mcbain.isocor.ie with Microsoft Mail id <01BD1F46.B3D0F6B0@mcbain.isocor.ie>; Mon, 12 Jan 1998 10:41:56 -0000 Message-ID: <01BD1F46.B3D0F6B0@mcbain.isocor.ie> From: david sutton To: "'gordon.good@netscape.com'" Cc: "'ietf-ldup@imc.org'" Subject: Comments on draft-ietf-asid-changelog-01.txt Date: Mon, 12 Jan 1998 10:41:55 -0000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BD1F46.B3D0F6B0" Sender: owner-ietf-ldup@imc.org Precedence: bulk ------ =_NextPart_000_01BD1F46.B3D0F6B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Gordon, I was scanning through draft-ietf-asid-changelog-01.txt and have a = couple of comments: 1) Comments on 'Background and Intended Usage' "Existing replication methods used by the X.500 directory, and by certain standalone LDAP implementations (namely, the University of Michigan ldap-3.3 release) are supplier-initiated in nature. That is, a server which holds authoritative data for some directory subtree connects to another server and synchronizes the other server's copy of the data. This approach requires that a pre- arranged replication agreement exist between the two servers exchanging data. This restriction is an impediment to implementation of ad-hoc replication configurations which might be desirable in a corporate intranet." and later "We term this approach "consumer-initiated replication" to differentiate it from the existing method, which we call "supplier-initiated replication"." This is not correct as the X.500 model allows either side to initiate = the exchange (i.e. both consumer-initiated and supplier-initiated = replication are supported). The real point of comparision with X.500 is = that a pre-existing replication agreement is required before replication = can take place -- whereas the change log method doesn't require this = (subject to security considerations of course). So I'd suggest replacing: Existing replication methods used by the X.500 directory, and by certain standalone LDAP implementations (namely, the University of Michigan ldap-3.3 release) are supplier-initiated in nature. That is, a server which holds authoritative data for some directory subtree connects to another server and synchronizes the other server's copy of the data. This approach requires that a pre- arranged replication agreement exist between the two servers exchanging data. This restriction is.... with: Existing replication methods used by the X.500 directory, and by certain standalone LDAP implementations (namely, the University of Michigan ldap-3.3 release) require that a pre-arranged replication=20 agreement exist between the two servers exchanging data. = Additionally, in some standalone LDAP implementations the replication method is supplier-initiated in nature requiring that the server which holds=20 authoritative data for some directory subtree connects to another = server and synchronizes the other server's copy of the data. These = restrictions are.... and deleting the sentence We term this approach "consumer-initiated replication" to differentiate = it from the existing method, which we call "supplier-initiated = replication". completely. The phrase "consumer-initated replication" is not used = anywhere else in the draft. 2) Security Considerations In the section dealing with security it is stated: <> In fact it is equally true that the "targetDN" attribute MUST NOT be = generally readable either. It could be just as serious a security breach = for the existence of an entry to be exposed in the ChangeLogs when the = access controls for the entry itself have tight restrictions on = revealing its existence. However, it doesn't seem to make much sense to = have a readable ChangeLogEntry if the "targetDN" attribute isn't = readble. So its probably worth expanding the security considerations = section a little by replacing the first two paragraphs with these three. Security Considerations Servers implementing this scheme MUST NOT allow the ChangeLogEntry = objects to=20 be generally readable. Generally they will only be readable by = certain trusted DNs. =20 Furthermore, it is likely that there could be even stricter controls = on individual attributes within individual ChangeLogEntry objects, so that it = should not be assumed by=20 replicating clients that access to an individual ChangeLogEntry = object implies access to all of its attributes. For example the "changes" attribute = contains all modifications made to an entry, and some changes may contain sensitive data, e.g. passwords. If a server does allow read access on the "changes" or "targetDN" = attribute to a particular bound DN, then that DN should be trusted. For example, = two cooperating servers may exchange the password for some DN which is granted read access to the "changes" attribute of the changeLog. = This would allow one server to retrieve changes and apply them directly to its database. =20 ..... and so on .... ------ =_NextPart_000_01BD1F46.B3D0F6B0 Content-Type: text/x-vcard; name="David Sutton (E-mail).vcf" Content-Transfer-Encoding: 7bit BEGIN:VCARD VERSION:2.1 N:;David Sutton;;; FN:David Sutton (E-mail) ORG:ISOCOR; TITLE:Directory Architect TEL;WORK;VOICE:+ 353 1 676 0366 TEL;WORK;FAX:+ 353 1 676 0856 ADR;WORK:;;42 - 47 Lower Mount St.;Dublin 2;;;Ireland LABEL;WORK;ENCODING=QUOTED-PRINTABLE:42 - 47 Lower Mount St.=0D=0ADublin 2, =0D=0AIreland EMAIL;PREF;INTERNET:david.sutton@isocor.com REV:19971219T110312Z END:VCARD ------ =_NextPart_000_01BD1F46.B3D0F6B0-- From owner-ietf-ldup Mon Jan 12 13:47:31 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA19548 for ietf-ldup-bks; Mon, 12 Jan 1998 13:47:31 -0800 (PST) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA19543 for ; Mon, 12 Jan 1998 13:47:27 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id NAA00087 for ; Mon, 12 Jan 1998 13:51:09 -0800 (PST) Received: from netscape.com ([205.217.229.74]) by dredd.mcom.com (Netscape Messaging Server 3.0) with ESMTP id AAA29392; Mon, 12 Jan 1998 13:51:09 -0800 Message-ID: <34BA904B.F4E7A163@netscape.com> Date: Mon, 12 Jan 1998 13:51:07 -0800 From: ggood@netscape.com (Gordon Good) X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Erik Andersen CC: "'LDUP'" Subject: Re: FW: Extended LDIF References: <98Jan12.104858gmt+0100.26885-4@gw.fl.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk Erik Andersen wrote: > Hi Folks, > > Apparently, I forgot to include the file. Sorry about that. Also, in a > note Gordon has stated that records are separated by two new lines. I > have not been able to gather that from the current LDIF specification, > which may easily be a shortcoming of mine. It's not explicitly written that way, but note that an LDIF file consists of a series of either ldif-content or ldif-changes constructs terminated by newlines. These ldif-content and ldif-changes constructs are themselves composed of records which are terminated by a newline. The end of either an ldif-content, or ldif-changes construct, then, is signaled by the two consecutive newlines which, respectively, terminate the last record in the construct, and terminate the construct itself. From owner-ietf-ldup Tue Jan 13 01:15:57 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id BAA28027 for ietf-ldup-bks; Tue, 13 Jan 1998 01:15:57 -0800 (PST) Received: from fl.dk (ns.fl.dk [193.88.152.146]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id BAA28020 for ; Tue, 13 Jan 1998 01:15:47 -0800 (PST) Received: by gw.fl.dk id <26885-2>; Tue, 13 Jan 1998 10:21:00 +0100 Message-Id: <98Jan13.102100gmt+0100.26885-2@gw.fl.dk> From: Erik Andersen To: "'LDUP'" Subject: RE: FW: Extended LDIF Date: Tue, 13 Jan 1998 10:20:24 +0100 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ietf-ldup@imc.org Precedence: bulk Hi Gorden and others, I see what you mean, although I am missing a SEP at the end of ldif-attrval-record construct. I probably messed-up the whole issue of SEPs. Also, I forgot a few changes here end there. I will send a new version later today. What is the attitute. Will I be able to progress a corrected version of my proposal to LDIF extensions through the LDUP group? Kind regards, Erik > -----Original Message----- > From: ggood@netscape.com [SMTP:ggood@netscape.com] > Sent: 12. januar 1998 22:51 > To: Erik Andersen > Cc: 'LDUP' > Subject: Re: FW: Extended LDIF > > Erik Andersen wrote: > > > Hi Folks, > > > > Apparently, I forgot to include the file. Sorry about that. Also, in > a > > note Gordon has stated that records are separated by two new lines. > I > > have not been able to gather that from the current LDIF > specification, > > which may easily be a shortcoming of mine. > > It's not explicitly written that way, but note that an LDIF file > consists of a > series of either ldif-content or ldif-changes constructs terminated by > newlines. These ldif-content and ldif-changes constructs are > themselves > composed of records which are terminated by a newline. The end of > either an > ldif-content, or ldif-changes construct, then, is signaled by the two > consecutive newlines which, respectively, terminate the last record in > the > construct, and terminate the construct itself. From owner-ietf-ldup Tue Jan 13 06:10:12 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id GAA04306 for ietf-ldup-bks; Tue, 13 Jan 1998 06:10:12 -0800 (PST) Received: from fl.dk (ns.fl.dk [193.88.152.146]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id GAA04300 for ; Tue, 13 Jan 1998 06:10:04 -0800 (PST) Received: by gw.fl.dk id <26886-2>; Tue, 13 Jan 1998 15:15:39 +0100 Message-Id: <98Jan13.151539gmt+0100.26886-2@gw.fl.dk> From: Erik Andersen To: "'LDUP'" Subject: Extended LDIF format Date: Tue, 13 Jan 1998 15:15:05 +0100 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BD2036.08676AC0" Sender: owner-ietf-ldup@imc.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_000_01BD2036.08676AC0 Content-Type: text/plain As promised in an earlier note, I have produced a new version of my proposal for an extended LDIF. During this process I discovered som very fatal error in my Backus-Naur specification for which I am quite ashame. I have also made a few simplifications. The result of all this is that the proposed changes do look as drastic as before. Any comments? Kind regards, Erik ------ =_NextPart_000_01BD2036.08676AC0 Content-Type: text/plain; name="LDIF_EXT.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="LDIF_EXT.txt" This note suggests some changes to the current LDIF format to extend = its=20 usability to more areas. It should be read as a delta to the current = Internet=20 draft. The note is not in the form of an Internet draft. It is put up = on the=20 LDUP mailing list for comments. ------------------------------------------------------------------------= ----- Background and Intended Usage (addition) Different directory systems may hold different pieces of directory=20 information about the same object. Such systems may have a = requirement to=20 update each other or to update a central directory system to merge = all=20 relevant information. A record that is sent by one system to another may represent a = complete=20 entry by the sender. However, the recipient may already have = information=20 about the object in question. Adding a new entry through LDIF may = not=20 actually cause creation of a new entry, but may add information to = an=20 already existing entry. In this case, the recipient will have to = perform=20 correlation by different means to try to locate an existing entry=20 corresponding to the received record. If a globally unique = distinguished=20 name is transferred, correlation is straightforward. However, if = such a=20 distinguished name is not available, additional information carried = in the=20 record may be used for this correlation. It is application dependent = what=20 information that is then necessary. A high level of correlation=20 accurateness is necessary not to corrupt the directory information. In some cases it may be difficult to have a common scheme for = allocating=20 distinguished names. As an example, it may be possible to get some=20 agreement on how a country should be structured into some hierarchy = of=20 localities. However, it is quite difficult to allocate RDNs for=20 residential persons common to all directory systems. Formal Syntax Definition of LDIF The following definition uses the augmented Backus-Naur Form specified in RFC 822 [2]. ldif-file =3D ldif-content / ldif-changes ldif-content =3D ["total" 1*SEP] heading = ldif-attrval-record *(1*SEP ldif-attrval-record) ldif-changes =3D ["incremental" 1*SEP] heading = ldif-change-record *(1*SEP ldif-change-record) heading =3D 0,1*(version-spec 1*SEP) ["agreement-id:" *SPACE agreement-id 1*SEP] agreement-id =3D 1*safe-initval ldif-attrval-record =3D dn-spec SEP 1*(attrval-spec SEP) ["other" SEP 1*(attrval-spec SEP)] ldif-change-record =3D dn-spec SEP 1*(changerecord SEP) ["own" SEP 1*(attrval-spec SEP)] ["other" SEP 1*(attrval-spec SEP)] version-spec =3D "version:" *SPACE version-number version-number =3D 1*DIGIT ; version-number MUST be "2" for = the ; LDIF format described in this = document. dn-spec =3D ("dn:" *SPACE dn) / ("dn::" *SPACE = base64-dn) / ("dn:" *SPACE 1*DIGIT rdn *(("," / ";") *SPACE rdn)) / ("dn::" *SPACE 1*DIGIT base64-rdn *(("," / ";") *SPACE base64-rdn )) / ("s:" *SPACE dn) / ("s::" *SPACE base64-dn) dn =3D base64-dn =3D rdn =3D base64-rdn =3D attrval-spec =3D attribute-description ((":") / (":" *SPACE value *(*SPACE "\" *SPACE = value)) / ("::" *SPACE base64-value=20 *(*SPACE "\" *SPACE base64-value)) / (":<" *SPACE url*(*SPACE "\" *SPACE url))) url =3D ; (See Note 6, below) attribute-description =3D charset-option =3D "charset=3D" ( "*" / charset-name ) charset-name =3D a character set name, as registered with = IANA [10] value =3D 1*safe-initval *safe safe =3D safe-initval =3D base64-value =3D changerecord =3D change-add / change-delete / change-modify = / change-moddn change-add =3D "changetype:" *SPACE "add" 1*(SEP = attrval-spec) change-delete =3D "changetype:" *SPACE "delete" change-moddn =3D "changetype:" *SPACE ("modrdn" / "moddn") = SEP ("newrdn:" *SPACE rdn / "newrdn::" *SPACE base-64-rdn) SEP "deleteoldrdn:" *SPACE ("0" / "1") 0,1*(SEP (("newsuperior:" *SPACE dn) / ("newsuperior:: *SPACE base-64-dn))) change-modify =3D "changetype:" *SPACE "modify" 1*(SEP = mod-spec) mod-spec =3D mod-add-spec / mod-delete-spec / = mod-replace-spec mod-add-spec =3D "add:" *(*SPACE attribute-description) 1*(SEP attrval-spec) SEP "-" mod-delete-spec =3D "delete:" *(*SPACE attribute-description) *(SEP attrval-spec) SEP "-" mod-replace-spec =3D "replace:" *(*SPACE attribute-description) *(SEP attrval-spec) SEP "-" SPACE =3D SEP =3D (CR LF / LF) CR =3D LF =3D DIGIT =3D Agreements An agreement ID can optionally be in the first part of an LDIF file. = This=20 agreement specification can be used to give a unique identification = of the=20 scope of an information exchange. Such an agreement can be include = such=20 things as: 1) What information has to be transferred and possibly kept updated = by the=20 sender. 2) The attribute types and object classes that are part of the = transport=20 including what textual representations that are going to be used. In = case=20 of high-volume exchanges, the two parties can agree on an = abbreviated form=20 of textual representation. As an example "tel" could be an = abbreviated=20 form of TelephoneNumber. Textual representations of attribute types = MUST=20 be unique within an agreement. Likewise for textual representation = of=20 object classes. 3) An understanding of what information is necessary to transfer to = ensure=20 the correlation process, i.e. locating an existing entry, if any. 4) How much of a distinguished name that needs to be transferred. As = an=20 example, the country name could have a default value. 5) How much information that is needed for the objectClass = attribute. If=20 the object class for the entry information is, say, = residentialPerson, it=20 may not be necessary also to specify the super-classes person and = top.=20 They could be implied. Also auxiliary object classes can be implied. = It=20 MUST be completely understood by both parties what set of object = classes=20 is behind a single object class textual specification. 6) Agreement on not to use spaces where they are optional. 7) Agreement not to use any unnecessary SEPs, i.e. consider the = 1*SEP=20 specification as equal to just SEP. 8) Agreement on only using LF for SEP. 9) Update frequency. Establishment of an agreement is a completely off-line activity not=20 directly reflected in the protocol. If there is no agreement-id specified, an implied agreement is = assumed.=20 There can only be one implicit agreement between a particular sender = and a=20 particular recipient. Note on LDIF syntax and usage 1) Some of the information in a record is "owned" by the sender, = i.e. the=20 sender is master for that information. This information is located = just=20 after the "dn" or the "s" specification, and may be the only = information=20 in a record. Additional information may be supplied in a record to = aid the=20 receiver in uniquely identifying the identity of the corresponding = entry. 2) The optional "own" specification starts a block of information, = for=20 which the sender is the master. The optional "other" specification = starts=20 a block of information assumed to be owed by other organizations or=20 systems including the recipient system. Such types of information = are=20 primarily intended for identifying an already existing entry. As an=20 example, a mobile operator may supply the fixed telephone number in = a=20 record, although the fixed telephone is subscribed from another = operator.=20 If there is information in these blocks that is currently not = present at=20 the recipient, it a local option for the recipient whether to store = it or=20 dispose of it in any other way. 3) When doing total update: a) All information related to the agreement SHOULD be purged and=20 replaced by the information in the current transfer. This does = not=20 necessarily mean that current entries are completely deleted = during=20 the first part of this process, as there may be local information = or=20 information from other agreements within those entries. b) Information following the "other" specification is only = intended=20 for entry identification. Such information MUST be included if = the "s"=20 specification is used. 4) When doing incremental update: a) Only information owned by the sender can be changed. = Additional=20 information may be transmitted to allow identification of the = entries=20 to be changed. If the "dn:" specification is used, only the=20 distinguished name SHOULD be supplied in addition to change or = delete=20 specifications to ensure compatibility with earlier versions. For = records starting with an implicit or explicit "s:" specification, = additional information MUST be supplied for entry identification. b) Records without any "changetype" specification are to be = considered=20 as new entries to be added. Such a record MAY NOT have an = explicit=20 "own" part. For records starting with an implicit or explicit = "s:"=20 specification, an "other" part MUST be supplied for entry=20 identification. c) A record with "changetype" equal to "delete" only applies to = the=20 part of the entry holding information owned by the sender = according to=20 the current agreement. For records starting with an implicit or=20 explicit "s:" specification MUST beside the delete specification = have=20 an "own" and/or an "other" part for entry identification. d) A record with "changetype" equal to "modify" and which starts = with=20 an implicit or explicit "s:" specification MUST besides the = change=20 specifications have an "own" and/or an "other" part for entry=20 identification. 5) In some cases it may not be possible to denote some pieces of=20 information belonging to anyone. As an example, object class=20 specification, postal address, etc. may be considered general = information=20 maintained independently by each system. If such information is not=20 consistent across systems, correlation may not be possible. Such = general=20 information should be in the "other" block. 6) The "dn" is the distinguished name of the entry. This is not a=20 mandatory field. However, if this field is not present, the "s" = field MUST=20 be explicitly or implicitly present. This filed MUST NOT be present = if the=20 "s" field is present. This field shall only be used if the complete=20 distinguished name is understood by both parties to denote the same=20 object. As an example, the name of a reasonable seized company is = assumed=20 to be unique within a certain geographical area. This field MUST be = used=20 if the entry has subordinate entries. 7) An abbreviated form of distinguished name may be used. This = abbreviated=20 form MAY NOT be used unless the preceding record has a "dn" = specification.=20 The first item on in the abbreviated specification is a level = indication=20 telling how large a part of the distinguished name of the preceding = record=20 that is inherited. This item MUST include the defaulted part of the=20 distinguished. AS an example, if the country name is implied, the = country=20 name component is still counted. The remaining items are one or more = RDNs=20 that are prefixed the inherited part to get a complete distinguished = name. 8) The "s" field gives the distinguished name of the superior entry. = This=20 field can only be used for leaf entries, e.g. residential persons, = and it=20 is used if it not possible to establish a distinguished name that is = globally recognized. When this field is present, it is assumed that = the=20 recipient from other included information, e.g. name, telephone = number,=20 postal address, etc. can determine whether the object is already = present=20 and should be updated. Otherwise, if an existing entry is not found, = the=20 receiver will generate an RDN based on local algorithms to produce a = complete distinguished name for its own use. 9) If there is no "s" or "dn" specification, an "s" field is assumed = having the same value as in the previous record. The absence of both = the=20 "dn" and the "s" specification is only allowed if the previous = record had=20 an explicit or implicit "s" specification. 10) For multi-valued attribute types, it is possible either to put = all=20 values on a single line or include a line for each attribute value. 11) If the object class attribute is not included for a record in a=20 "total" transfer, the value(s) is the same as for the previous = record. Differences from Version 1 of LDIF 1) It is possible in a header besides giving version information to=20 indicate whether an LDIF file is a complete transfer of all = information or=20 whether is an updating file 2) It is possible in the header to optionally indicate an agreement = ID in=20 case two parties have several agreements on exchanging = synchronization=20 information. 3) It is possible for each record to include information that is not = intended for storage by the receiver, but is aiding the receiver in=20 identifying a particular entry. 4) It is possible to only transfer the distinguished name of the = superior=20 of an entry in case the receiver is expected to generate the = complete=20 distinguished following local algorithms. 5) Several values for a multi-valued attribute can be on the same,=20 possibly folded line. The separator between values is a back-slash = ("\") Examples of LDAP Interchange Format Example 7: A simple LDIF file with a few records sent from a mobile=20 telephone operator to some central information service total version 2 agreement-id: op1-to-op2, ver.1 dn:o=3DF&L,c=3DDK mobile:+4533333333\+4544444444 other tel:+4539450700 fax:+4539450777 =20 dn:2 cn=3DTom Finkelstein mobile:+4512345678 other objcl:orgPers sn:Finkdelstein gn:Tom tel:+4539450999 822:tfs@fl.dk dn:2 cn=3DPer Futtesen mobile:+4587654321 other sn:Futtesen gn:Per tel:+4539450998 822:tfs@fl.dk s:L=3DFrederiksberg C,ST=3DCopenhagen mobile:+4520971490 other objcl:resPers sn:Andersen gn:Erik street:Paludan Mullersvej num:3 floor:2 floorentity:tv tel:+4531230490 mobile:+4587654321 other sn:Petersen gn:Peter street:Paludan Mullersvej num:114 floor:3 tel:+4523456789 Example 8: A simple LDIF file with a few update records sent from a = mobile=20 telephone operator to some central information service incremental version 2 agreement-id: op1-to-op2, ver.1 # Delete an entry. The mobile number and the name is considered = sufficient # information for locating the right entry s:L=3D1815,ST=3DCopenhagen changetype:delete own mobile:+4520971490 other sn:Andersen gn:Erik # Update existing entry replace: mobile:+4587654321 mobile:+4598765432 - other sn:Petersen gn:Peter # Add new entry s:L=3DHellerup,ST=3DCopenhagen mobile:+4534567890 other objcl:resPers sn:Frederiksen gn:John street:Grundtvigsvej num:245 floor:5 floorentity:tv tel:+4531230490 ------ =_NextPart_000_01BD2036.08676AC0-- From owner-ietf-ldup Fri Jan 16 15:56:36 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA08991 for ietf-ldup-bks; Fri, 16 Jan 1998 15:56:36 -0800 (PST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.41]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA08964 for ; Fri, 16 Jan 1998 15:56:31 -0800 (PST) Received: by INET-01-IMC with Internet Mail Service (5.5.1960.3) id ; Fri, 16 Jan 1998 16:00:46 -0800 Message-ID: From: Chris Weider To: "'minutes@ietf.org'" , "'ietf-ldup@imc.org'" Cc: "'rweiser@novell.com'" Subject: Final minutes from LDUP Date: Fri, 16 Jan 1998 16:00:42 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ietf-ldup@imc.org Precedence: bulk No corrections were received. Chris Minutes from the LDUP BOF, Washington, DC The agenda was as follows: 10 minutes on terminology, 30 minutes on approaches, 20 minutes on charter The intent was to define an approach on how to do LDAP replication, get a charter to form a wg, and then go forth. The group generally agreed that the focus of an LDUP working group should be on directory synchronization, rather than making server A look exactly like server B in terms of functionality, which will be impossible in an environment where vendors are providing value-add functionality on top of their servers. The first two items an LDUP working group would work on would be a requirements document and an applicability statement. There were 4 major work items identified as possibilities after that: One-way directory synchronization (dir synch), 2-way dir synch, floating single-master operations, and multi-master dir synch. 1-way dir synch is essentially the X.500 single-master, multiple slave relationship. 2-way dir synch is where you have the SAME data mastered on two servers and need to synchronize them. Floating single master is where there is only a single master server for a given set of data at any one point in time, but that server may change over time. Multi-master is directory synchronization between n servers, of which more than two can be writeable replicas of the same data. Open questions: Do we need to solve the schema synch problem to make progress on general dir synch? Do we need to solve the distributed knowledge synch problem? What about security and access control? Do we need to standardize the mechanisms for selecting which content to replicate? Do we need to standardize how the directory is initially populated (as well as reload of data)? Do we need to cover replica compare and replica diff? Additional items: Cross-realm replication Partial and fractional replication Consistency models will be covered in the applicability statement Items ruled out of scope were: Request forwarding (e.g. chaining) Index-only replication a la the Common Indexing Protocol Integration with TIP There was no consensus on which order to cover the work items. Thus this will be discussed on the list, with a draft charter to be produced by mid-January. From owner-ietf-ldup Mon Jan 26 15:32:45 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id PAA11195 for ietf-ldup-bks; Mon, 26 Jan 1998 15:32:45 -0800 (PST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.42]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id PAA11191 for ; Mon, 26 Jan 1998 15:32:41 -0800 (PST) Received: by INET-02-IMC with Internet Mail Service (5.5.1960.3) id ; Mon, 26 Jan 1998 15:37:39 -0800 Message-ID: From: Chris Weider To: "'ietf-ldup@imc.org'" Subject: LDUP charter discussion Date: Mon, 26 Jan 1998 15:37:36 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ietf-ldup@imc.org Precedence: bulk Hi folks: From the minutes: Potential work items: 1. 1-way dir synch 2. 2-way dir synch 3. Floating single master dir synch 4. Multi-master dir synch Open questions: 5: Do we need to solve the schema synch problem to make progress on general dir synch? 6: Do we need to solve the distributed knowledge synch problem? 7: What about security and access control? 8: Do we need to standardize the mechanisms for selecting which content to replicate? 9: Do we need to standardize how the directory is initially populated (as well as reload of data)? 10: Do we need to cover replica compare and replica diff? Additional items: Cross-realm replication Partial and fractional repliation Consistency models There was a discussion at the IETF about which of the potential work items should be done. Everyone was pretty happy with 1,2, and 4. There was less consensus on 3. There was no consensus on which order these items should be done in. In any case, the first work items for the group would need to be a requirements document and an applicability statement. On the open questions, my thinking goes 5: No, as these mechanisms should be flexible enough to synch with targets other than LDAP servers 6: Yes, if we want LDAP servers to have as consistent a view of the world as possible 7: Absolutely but we're blocked on the access control standard 8: Yes 9: Yes 10: No We need a definition of 'cross-realm replication'. I'd like to see if there's some sort of consensus by the middle of next week (Feb 5). Let the games begin :^) Chris From owner-ietf-ldup Mon Jan 26 18:01:19 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id SAA12004 for ietf-ldup-bks; Mon, 26 Jan 1998 18:01:19 -0800 (PST) Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.7.3) with SMTP id SAA12000 for ; Mon, 26 Jan 1998 18:01:14 -0800 (PST) Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Mon, 26 Jan 1998 19:05:42 -0700 Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Mon, 26 Jan 1998 19:03:34 -0700 From: "Ed Reed" To: ietf-ldup@imc.org, cweider@microsoft.com Subject: Re: LDUP charter discussion Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: owner-ietf-ldup@imc.org Precedence: bulk Let the games be engaged! I agree work should proceed on 1, 2, and 4. I've not seen requirements = for 3 in our work. 5 - YES - even if, as Chris points out below, mechanisms should be able to = synch with non-LDAP directories, I strongly believe that a formal = meta-schema needs to be agreed to, and means to express the schema of the = data being transmitted, as part of any rational synchronization scheme = (sorry for the pun!) 6 - Yes - the management of distributed knowledge, ie the various = addresses associated with superior and subordinate references in the = namespace, is the only way I know to inform LDAP servers about referrals = to be returned for non-local data. Synchronization of addresses, server = names, replica types, sparse replica and index inventories, etc. is really = needed to create a distributed LDAP service, which is what I (we?) really = want to see evolve. At the very least, let us agree on a base set of = attributes, their interpretation, access controls on whether they may be = replicated (it's not always desireable), and a way to extend the set of = attributes associated with subordinate references (for things like = inherited attribute values, access control policies, and other operational = information). 7 - Yes - Without security and access control standards, we'll only be = synchronizing public, valueless information...we're supposed to be working = towards interoperable solutions, even ones which will allow customers to = build distributed services from a mixed group of heterogeneous suppliers. = Now, that may be ambitious, and may even run counter to some technology = providers' objectives (my own company has been accused of such things in = the past, even!) - and it's a hard thing. But isn't that what the = industry is expecting? Does ANYONE want to explain to the press that LDAP = is only about address book synchronization, and not network management or = user management? Not ME! 8 - Not immediately. As long as the synchronization information is fully = self contained (see #6 above). 9 - No - only as a special case of synchronization (I got stuff and you = don't). However, SOMEONE should document and continue to develop LDIF as = a flat file representation of data to be loaded. That could as easily be = done here as other places, I guess. 10 - I mentioned these at the meeting in Washington. I suspect most folks = will have trouble debugging their directories and the interoperability = conformance of synchronization protocols with out it. "Ok, you've = completed the synch - are our two replicas really the same? Prove it!" Comments welcome! Ed ------------------- Ed Reed, Chief Architect Network Services Group Novell, Inc. +1 801 861 3320 >>> Chris Weider 01/26/98 04:37PM >>> Hi folks: From the minutes: Potential work items: 1. 1-way dir synch 2. 2-way dir synch 3. Floating single master dir synch 4. Multi-master dir synch Open questions: 5: Do we need to solve the schema synch problem to make progress on = general dir synch? 6: Do we need to solve the distributed knowledge synch problem? 7: What about security and access control? 8: Do we need to standardize the mechanisms for selecting which content to replicate? 9: Do we need to standardize how the directory is initially populated (as well as reload of data)? 10: Do we need to cover replica compare and replica diff? Additional items: Cross-realm replication Partial and fractional repliation Consistency models There was a discussion at the IETF about which of the potential work items should be done. Everyone was pretty happy with 1,2, and 4. There was less consensus on 3. There was no consensus on which order these items should = be done in. In any case, the first work items for the group would need to be = a requirements document and an applicability statement.=20 On the open questions, my thinking goes 5: No, as these mechanisms should be flexible enough to synch with targets other than LDAP servers 6: Yes, if we want LDAP servers to have as consistent a view of the world = as possible 7: Absolutely but we're blocked on the access control standard 8: Yes 9: Yes 10: No We need a definition of 'cross-realm replication'.=20 I'd like to see if there's some sort of consensus by the middle of next = week (Feb 5). Let the games begin :^) Chris From owner-ietf-ldup Sat Jan 31 14:25:03 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id OAA03591 for ietf-ldup-bks; Sat, 31 Jan 1998 14:25:03 -0800 (PST) Received: from cupcake.cisco.com (cupcake.cisco.com [171.69.1.242]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id OAA03584 for ; Sat, 31 Jan 1998 14:24:59 -0800 (PST) Received: from jstrassn-pc ([171.69.108.130]) by cupcake.cisco.com (8.8.5-Cisco.1/8.6.5) with SMTP id OAA19402; Sat, 31 Jan 1998 14:29:42 -0800 (PST) Message-Id: <3.0.2.32.19980131142934.00abee20@cupcake.cisco.com> X-Sender: jstrassn@cupcake.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Sat, 31 Jan 1998 14:29:34 -0800 To: "Ed Reed" , ietf-ldup@imc.org, cweider@microsoft.com From: "John C. Strassner" Subject: Re: LDUP charter discussion In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@imc.org Precedence: bulk I have seen requirements for 1-4. I think that the order should be as is (with the option that 3 be removed if there is a sufficient lack of interest), though i would like to go on record that in terms of need, 4 is, imho, highest. Having said that, I think that we need to at least do the work on 1 and 2 in order to be able to be in a position to do the work for 4. 5 - NO, agreeing on a formal meta-schema when we can't agree on something as simple as a person schema is hopeless. Besides, the general problem of schema synch is really hard and is fraught with many obtuse and very difficult end points. 6 - YES, I agree with both of you, who seem to be in violent agreement 7 - YES 8 - YES. We sorely need the formal definition of replication policies that give better control over what gets replicated when, why and how. Otherwise we will never match business needs. 9 - I think we need more discussion on this one. Reload especially will most probably be destructive, and I think that we need to carefully consider the implications of which content we want to nuke before we hit the enter button 10 - YES John Strassner Chief Architect, Network Service and Management Business Unit Cisco Systems At 07:03 PM 1/26/98 -0700, Ed Reed wrote: >Let the games be engaged! > >I agree work should proceed on 1, 2, and 4. I've not seen requirements for 3 in our work. > >5 - YES - even if, as Chris points out below, mechanisms should be able to synch with non-LDAP directories, I strongly believe that a formal meta-schema needs to be agreed to, and means to express the schema of the data being transmitted, as part of any rational synchronization scheme (sorry for the pun!) >6 - Yes - the management of distributed knowledge, ie the various addresses associated with superior and subordinate references in the namespace, is the only way I know to inform LDAP servers about referrals to be returned for non-local data. Synchronization of addresses, server names, replica types, sparse replica and index inventories, etc. is really needed to create a distributed LDAP service, which is what I (we?) really want to see evolve. At the very least, let us agree on a base set of attributes, their interpretation, access controls on whether they may be replicated (it's not always desireable), and a way to extend the set of attributes associated with subordinate references (for things like inherited attribute values, access control policies, and other operational information). >7 - Yes - Without security and access control standards, we'll only be synchronizing public, valueless information...we're supposed to be working towards interoperable solutions, even ones which will allow customers to build distributed services from a mixed group of heterogeneous suppliers. Now, that may be ambitious, and may even run counter to some technology providers' objectives (my own company has been accused of such things in the past, even!) - and it's a hard thing. But isn't that what the industry is expecting? Does ANYONE want to explain to the press that LDAP is only about address book synchronization, and not network management or user management? Not ME! >8 - Not immediately. As long as the synchronization information is fully self contained (see #6 above). >9 - No - only as a special case of synchronization (I got stuff and you don't). However, SOMEONE should document and continue to develop LDIF as a flat file representation of data to be loaded. That could as easily be done here as other places, I guess. >10 - I mentioned these at the meeting in Washington. I suspect most folks will have trouble debugging their directories and the interoperability conformance of synchronization protocols with out it. "Ok, you've completed the synch - are our two replicas really the same? Prove it!" > >Comments welcome! > >Ed > > >------------------- >Ed Reed, Chief Architect >Network Services Group >Novell, Inc. >+1 801 861 3320 > >>>> Chris Weider 01/26/98 04:37PM >>> >Hi folks: > From the minutes: >Potential work items: >1. 1-way dir synch >2. 2-way dir synch >3. Floating single master dir synch >4. Multi-master dir synch > >Open questions: >5: Do we need to solve the schema synch problem to make progress on general >dir synch? >6: Do we need to solve the distributed knowledge synch problem? >7: What about security and access control? >8: Do we need to standardize the mechanisms for selecting which content to >replicate? >9: Do we need to standardize how the directory is initially populated (as >well as reload of data)? >10: Do we need to cover replica compare and replica diff? > >Additional items: >Cross-realm replication >Partial and fractional repliation >Consistency models > >There was a discussion at the IETF about which of the potential work items >should be done. Everyone was pretty happy with 1,2, and 4. There was less >consensus on 3. There was no consensus on which order these items should be >done in. In any case, the first work items for the group would need to be a >requirements document and an applicability statement. > >On the open questions, my thinking goes >5: No, as these mechanisms should be flexible enough to synch with targets >other than LDAP servers >6: Yes, if we want LDAP servers to have as consistent a view of the world as >possible >7: Absolutely but we're blocked on the access control standard >8: Yes >9: Yes >10: No > >We need a definition of 'cross-realm replication'. > >I'd like to see if there's some sort of consensus by the middle of next week >(Feb 5). >Let the games begin :^) >Chris > > From owner-ietf-ldup Mon Feb 2 05:43:09 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id FAA17075 for ietf-ldup-bks; Mon, 2 Feb 1998 05:43:09 -0800 (PST) Received: from ausmail.austin.ibm.com (ausmail.austin.ibm.com [192.35.232.19]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id FAA17070 for ; Mon, 2 Feb 1998 05:43:04 -0800 (PST) Received: from netmail.austin.ibm.com (netmail.austin.ibm.com [9.53.250.98]) by ausmail.austin.ibm.com (8.8.5/8.8.5) with ESMTP id HAA29228; Mon, 2 Feb 1998 07:48:24 -0600 Received: from dceperf.austin.ibm.com (dceperf.austin.ibm.com [9.53.94.159]) by netmail.austin.ibm.com (8.8.5/8.8.5) with SMTP id HAA52374; Mon, 2 Feb 1998 07:47:39 -0600 Received: from portable.austin.ibm.com by dceperf.austin.ibm.com (AIX 4.1/UCB 5.64/4.03-client-2.6) for ietf-ldup@imc.org at austin.ibm.com; id AA63150; Mon, 2 Feb 1998 07:48:24 -0600 Message-Id: <3.0.1.32.19980202075023.007bf5f0@popmail2.austin.ibm.com> X-Sender: stokes@popmail2.austin.ibm.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 02 Feb 1998 07:50:23 -0600 To: Chris Weider From: Ellen Stokes Subject: Re: LDUP charter discussion Cc: "'ietf-ldup@imc.org'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@imc.org Precedence: bulk 1-4. On items 1-4, the target should be 4 - multi-master. I can see where work on 1 and 2 plus a bit more results in 4. But, we need to look at the end game (4) or we'll box ourselves in as we write the specs. Lots of vendors are already doing 1. because there is no replication standard and will continue to so. Besides, 4. is already available in products so let's build on what we know and not take steps backward. Let's remember that replication is something we'll all be deploying on an Internet scale and not just small workgroups so let's not sell ourselves short and define/implement various versions of replication over the next 5 years. We need to solve the single point of failure while providing an efficient (yet flexible)replication scheme and multi-master (4.) provides this. 5. NO 6. YES 7. YES. An updated ACL requirements documents will be available this week. First drafts of the ACL specs should be out by the end of Feb. 8. YES. Replication policies are needed. 9. NO. We've already agreed on an interchange format for this, i.e. LDIF. We need to continue to improve LDIF to handle internationalized and EBCDIC strings. How this initial/bulk load and reload are invoked are beyond the scope of IETF (I don't see commands being standardized) and enfringe on vendor value-add in the administration area. 10. YES Ellen Stokes Directory Services Architect IBM At 03:37 PM 1/26/98 -0800, Chris Weider wrote: >Hi folks: > From the minutes: >Potential work items: >1. 1-way dir synch >2. 2-way dir synch >3. Floating single master dir synch >4. Multi-master dir synch > >Open questions: >5: Do we need to solve the schema synch problem to make progress on general >dir synch? >6: Do we need to solve the distributed knowledge synch problem? >7: What about security and access control? >8: Do we need to standardize the mechanisms for selecting which content to >replicate? >9: Do we need to standardize how the directory is initially populated (as >well as reload of data)? >10: Do we need to cover replica compare and replica diff? > >Additional items: >Cross-realm replication >Partial and fractional repliation >Consistency models > >There was a discussion at the IETF about which of the potential work items >should be done. Everyone was pretty happy with 1,2, and 4. There was less >consensus on 3. There was no consensus on which order these items should be >done in. In any case, the first work items for the group would need to be a >requirements document and an applicability statement. > >On the open questions, my thinking goes >5: No, as these mechanisms should be flexible enough to synch with targets >other than LDAP servers >6: Yes, if we want LDAP servers to have as consistent a view of the world as >possible >7: Absolutely but we're blocked on the access control standard >8: Yes >9: Yes >10: No > >We need a definition of 'cross-realm replication'. > >I'd like to see if there's some sort of consensus by the middle of next week >(Feb 5). >Let the games begin :^) >Chris > From owner-ietf-ldup Thu Feb 5 14:36:44 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id OAA01567 for ietf-ldup-bks; Thu, 5 Feb 1998 14:36:44 -0800 (PST) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id OAA01563 for ; Thu, 5 Feb 1998 14:36:35 -0800 (PST) Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id OAA11159 for ; Thu, 5 Feb 1998 14:40:52 -0800 (PST) Received: from netscape.com ([208.12.63.187]) by tintin.mcom.com (Netscape Messaging Server 3.5) with ESMTP id AAA14B4; Thu, 5 Feb 1998 14:40:51 -0800 Message-ID: <34DA3FDE.56CDFA74@netscape.com> Date: Thu, 05 Feb 1998 14:40:30 -0800 From: merrells@netscape.com (John Merrells) Organization: Netscape Communications X-Mailer: Mozilla 4.04 [en]C-NSCP (WinNT; U) MIME-Version: 1.0 To: Chris Weider CC: "'ietf-ldup@imc.org'" Subject: Re: LDUP charter discussion References: Content-Type: multipart/mixed; boundary="------------12FB31559969A905BC9BB27A" Sender: owner-ietf-ldup@imc.org Precedence: bulk This is a multi-part message in MIME format. --------------12FB31559969A905BC9BB27A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Chris Weider wrote: > 1. 1-way dir synch > 2. 2-way dir synch > 4. Multi-master dir synch I think that we should tackle these three, in this order. I think there's value in having a staged approach for a couple of reasons. 1) It gives the working group some project milestones. This should ensure that the work stays on track. 2) I would expect that one-way replication could be defined quicker than full multi-master replication. This would provide our customers with a degree of ineteroperability sooner. Generally, I think that a full MM will be based on the one-way and two way replication solutions. > 3. Floating single master dir synch I feel that this is more of a 'fail-over' feature, than a replication feature.It might be nice to have an interoperable mechanism for this... but I don't think it belongs in LDUP. > 5: Do we need to solve the schema synch problem to make progress on general > dir synch? No, I don't think we should expend effort on solving the schema mergingproblems. But, I would be interested in us thinking about single mastered schema within a multi-master environment. An administrator would declare one of the masters as the one true schema master. One way replication could then be used to distribute schema changes... possibly on on an incremental basis, but more probably a reinitialisation. > 6: Do we need to solve the distributed knowledge synch problem? Yes, we should consider this. > 7: What about security and access control? Yes, but make it as independent of replication as possible. > 8: Do we need to standardize the mechanisms for selecting which content to > replicate? Yes. > 9: Do we need to standardize how the directory is initially populated (as > well as reload of data)? Maybe. > 10: Do we need to cover replica compare and replica diff? Although tools to perform this would be very useful, I don't thinkthey should become part of the charter. > Cross-realm replication This doesn't mean anything to me... ??? > Partial and fractional repliation Yes, as part of content selection. > Consistency models I think this will be a foundation of the whole replication architecture, anda conflict resolution document should define how consistency is maintained. John --------------12FB31559969A905BC9BB27A Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for John Merrells Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: John Merrells n: Merrells;John org: Netscape Communications adr;dom: 501 E. Middlefield Rd;;;Mountain View;;; email;internet: merrells@netscape.com title: Software Engineer note: http://people.netscape.com/merrells x-mozilla-cpt: ;0 x-mozilla-html: TRUE version: 2.1 end: vcard --------------12FB31559969A905BC9BB27A-- From owner-ietf-ldup Sun Feb 8 02:21:25 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id CAA24123 for ietf-ldup-bks; Sun, 8 Feb 1998 02:21:25 -0800 (PST) Received: from att.com (cagw2.att.com [192.128.52.90]) by mail.proper.com (8.8.8/8.7.3) with SMTP id CAA24119 for ; Sun, 8 Feb 1998 02:21:20 -0800 (PST) Received: by cagw2.att.com; Sun Feb 8 04:59 EST 1998 Received: from qsun.ho.att.com (qsun.ho.att.com [135.16.12.1]) by caig2.att.att.com (AT&T/GW-1.0) with SMTP id SAA24647 for ; Fri, 6 Feb 1998 18:17:53 -0500 (EST) Received: by qsun.ho.att.com (5.x/EMS-1.2 sol2) id AA01309; Fri, 6 Feb 1998 18:02:44 -0500 Date: Fri, 6 Feb 1998 18:02:44 -0500 Message-Id: <9802062302.AA01309@qsun.ho.att.com> From: rvh@qsun.ho.att.com (Richard V Huber) To: Chris Weider Cc: "'ietf-ldup@imc.org'" Subject: Re: LDUP charter discussion Content-Type: text Sender: owner-ietf-ldup@imc.org Precedence: bulk At 03:37 PM 1/26/98 -0800, Chris Weider wrote: >Hi folks: > From the minutes: >Potential work items: >1. 1-way dir synch >2. 2-way dir synch >3. Floating single master dir synch >4. Multi-master dir synch I think the highest priority should go to 4. There are potential uses for LDAP that need high reliability. Multi-master will let us build distributed systems with no single points of failure. The others have potential availabilty gaps for writes if the master system fails. Also, I think it will be easier to do an initial design for multi-master which includes the features needed for conflict resolution than to start with a one-way protocol and then have to add lots of features for multi-master to an existing design. You might well find that the existing design has to be redone from scratch. >Open questions: >5: Do we need to solve the schema synch problem to make progress on general >dir synch? I think this would be useful, but a lower priority than 6. >6: Do we need to solve the distributed knowledge synch problem? See 5. >7: What about security and access control? Replication that preserves access control information will be MUCH more useful than replication that does does not. Without some agreement on access control, replication will be limited mainly to publically available information and to completely private systems. >8: Do we need to standardize the mechanisms for selecting which content to >replicate? We need policies, but it doesn't seem to me that a standard way of specifying them is a high priority. I may not be reading this item the same way others are. >9: Do we need to standardize how the directory is initially populated (as >well as reload of data)? LDIF goes a long way towards addressing this. I'm not sure it is critical to go farther right now. Any work done in this area should be LDIF-based. >10: Do we need to cover replica compare and replica diff? They would be useful tools, but I think 6 and 7 are higher priority. From owner-ietf-ldup Sun Feb 8 20:37:43 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id UAA02228 for ietf-ldup-bks; Sun, 8 Feb 1998 20:37:43 -0800 (PST) Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.7.3) with SMTP id UAA02224 for ; Sun, 8 Feb 1998 20:37:39 -0800 (PST) Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Sun, 08 Feb 1998 21:42:56 -0700 Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Sun, 08 Feb 1998 21:40:00 -0700 From: "Ed Reed" To: cweider@microsoft.com, rvh@qsun.ho.att.com Cc: ietf-ldup@imc.org Subject: Re: LDUP charter discussion Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: owner-ietf-ldup@imc.org Precedence: bulk Rick - In watching the discussion about priorities, it seems clear to me that = there are two "camps" developing in the LDAP community... 1) The "LDAP isn't a distributed service" camp, who want to concentrate on = getting stand-alone database servers supporting LDAPv3 access protocols = from clients working with a rich set of indexed retrieval mechanisms, = extensions, etc., but who see little or no immediate need for a distributed= service; and 2) The "LDAP HAS to be a distributed service" camp, who want to concentrate= on server-to-server interoperability between LDAP servers from different = vendors, and support for a group of several (perhaps many) LDAP servers, = each with its own portion of the partitioned namespace, but cooperating = with the other servers to create a single, logical, connected directory = service which spans all the cooperating servers (ie, the classical X.500 = distributed model among separate directory management domains). I fall into the later camp, believing that without distributed knowledge = in the directory, clients will be stuck talking to individual servers - = which is fine for address books but not a good model of the delegated, = organizationally and geograpically disperse environments encountered by = businesses and organizations with more than about 100 employees. It seems to me that centralized, single-server databases, whether they be = SQL or LDAP in nature, are the right places for ad hoc queries and index = generation functions when ordered retrieval is required. But the DATA in = them should (normally, in most Fortune 5000 companies) be mastered in a = distributed service, and fed via synchronization and replication operations= into such central monolyths, err data warehouses. So - as with every other database design discussion I've ever been in, you = have to start your priorities by describing what application you are = building, understanding its data access characteristics, sensitivity to = data inconsistency and cost factors, and required availability. For address books use a centralized database as your warehouse. For user profile administration with cheap, reliable, non-stop availability= network connections from all administrative sites, use a centralized = database - relying on the network to provide guaranteed access by all = users and administrators. For user profile administration with normal, commercial grade (usually = works, but not paying for redundant network connections from/to all = sites), use a distributed directory service with multiple updateable = replicas to provide for automated delivery of change information among = major support and end-user sites. For network administration, where the OBJECTIVE of the application is to = repair network outages with help from both sides of the outage, each = needing information about the intended configuration of the network, = again, use the distributed directory service to allow each local site to = manage their own local inventory themselves, and automatically share that = information with other network operations centers. LDAP has the opportunity to acquire the needed extensions to support a = server-to-server distributed operations protocol, and I'm anxious to = proceed with that work. It is vital, though, that clients know how to = deal with information in the directory that describes where other = non-local data are found, and how to reach them...That's the notion of = item 6, which you place at a high priority. I agree. I also agree that = item 4 is the area of work I'd like to work on. Is there another group of folks who want to concentrate, instead, on the = stand-alone LDAP service definition? Ed ------------------- Ed Reed, Chief Architect Network Services Group Novell, Inc. +1 801 861 3320 >>> Richard V Huber 02/06/98 04:02PM >>> At 03:37 PM 1/26/98 -0800, Chris Weider wrote: >Hi folks: > From the minutes: >Potential work items: >1. 1-way dir synch >2. 2-way dir synch >3. Floating single master dir synch >4. Multi-master dir synch I think the highest priority should go to 4. There are potential uses for LDAP that need high reliability. Multi-master will let us build distributed systems with no single points of failure. The others have potential availabilty gaps for writes if the master system fails. Also, I think it will be easier to do an initial design for multi-master which includes the features needed for conflict resolution than to start with a one-way protocol and then have to add lots of features for multi-master to an existing design. You might well find that the existing design has to be redone from scratch. >Open questions: >5: Do we need to solve the schema synch problem to make progress on = general >dir synch? I think this would be useful, but a lower priority than 6. >6: Do we need to solve the distributed knowledge synch problem? See 5. >7: What about security and access control? Replication that preserves access control information will be MUCH more useful than replication that does does not. Without some agreement on access control, replication will be limited mainly to publically available information and to completely private systems. >8: Do we need to standardize the mechanisms for selecting which content = to >replicate? We need policies, but it doesn't seem to me that a standard way of = specifying them is a high priority. I may not be reading this item the same way others are. >9: Do we need to standardize how the directory is initially populated (as >well as reload of data)? LDIF goes a long way towards addressing this. I'm not sure it is critical = to go farther right now. Any work done in this area should be LDIF-based. >10: Do we need to cover replica compare and replica diff? They would be useful tools, but I think 6 and 7 are higher priority. From owner-ietf-ldup Mon Feb 9 19:37:24 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.8.5) id TAA01588 for ietf-ldup-bks; Mon, 9 Feb 1998 19:37:24 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ldup@imc.imc.org using -f Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.5/8.8.5) with ESMTP id TAA01584 for ; Mon, 9 Feb 1998 19:37:16 -0800 (PST) Received: by mail.opendirectory.com.au with Internet Mail Service (5.0.1458.49) id <141HXARF>; Tue, 10 Feb 1998 14:38:30 +1100 Message-ID: From: Alan Lloyd To: rvh@qsun.ho.att.com, Chris Weider Cc: "'ietf-ldup@imc.org'" Subject: RE: LDUP charter discussion Date: Tue, 10 Feb 1998 14:38:28 +1100 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldup@imc.org Precedence: bulk > -----Original Message----- > From: rvh@qsun.ho.att.com [SMTP:rvh@qsun.ho.att.com] > Sent: Saturday, February 07, 1998 10:03 AM > To: Chris Weider > Cc: 'ietf-ldup@imc.org' > Subject: Re: LDUP charter discussion > > At 03:37 PM 1/26/98 -0800, Chris Weider wrote: > >Hi folks: > > From the minutes: > >Potential work items: > >1. 1-way dir synch > >2. 2-way dir synch > >3. Floating single master dir synch > >4. Multi-master dir synch > > I think the highest priority should go to 4. There are potential uses > for LDAP that need high reliability. Multi-master will let us build > distributed systems with no single points of failure. The others have > potential availabilty gaps for writes if the master system fails. > Also, I think it will be easier to do an initial design for > multi-master which includes the features needed for conflict > resolution > than to start with a one-way protocol and then have to add lots of > features for multi-master to an existing design. You might well find > that the existing design has to be redone from scratch. > > Agree - I dont believe in taking a minimal/simple approach to this topic in the belief that a new simple protocol will solve all the replication/synchronisation problems - and because the topic is not new. ie. Its well researched, implementations are out there and the system issues have been well documented. Note that this work will require in its finality - HOB/replication management. eg. as defined by X.500 DOP, consistent knowledge management, multi - homed superior directory root systems which support split subordinate directories. ie. one will need a system design that embraces an architecture, a process model, an information model (and schema) and managed protocols - and an error management capability. Also see knowledge stuff below. > >Open questions: > >5: Do we need to solve the schema synch problem to make progress on > general > >dir synch? > > I think this would be useful, but a lower priority than 6. > > >6: Do we need to solve the distributed knowledge synch problem? > > See 5. > If this means how knowledge is maintained throughout the system for directory servers that are online/offline, are masters, are root/FLDSAs, are shadow suppliers or consumers, etc and/or are in DIB recovery mode - that is all part of the action and should be dealt with. See my notes above. > >7: What about security and access control? > > Replication that preserves access control information will be MUCH > more > useful than replication that does does not. Without some agreement on > access control, replication will be limited mainly to publically > available information and to completely private systems. > Got my vote also. Not only that - my post re access controls and the use of X.500 definitions means that this task could be simply achieved by using what already works. If one is propagating information around the place - through replication, one either needs to propagate the protection with it or accept that it can be modified and there may be subsequent issues. ie someone getting at a company's replicated telephone number entries and changing them all to 911, their competitors or an expensive chat line wont be acceptable. > >8: Do we need to standardize the mechanisms for selecting which > content to > >replicate? > > We need policies, but it doesn't seem to me that a standard way of > specifying > them is a high priority. I may not be reading this item the same way > others are. > I assume this would end up like an X.500 replication agreement definitions which are supported by DISP type functionality. > >9: Do we need to standardize how the directory is initially populated > (as > >well as reload of data)? > > LDIF goes a long way towards addressing this. I'm not sure it is > critical to > go farther right now. Any work done in this area should be > LDIF-based. > > >10: Do we need to cover replica compare and replica diff? > > They would be useful tools, but I think 6 and 7 are higher priority. > regards alan From owner-ietf-ldup Tue Feb 17 15:39:09 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA06802 for ietf-ldup-bks; Tue, 17 Feb 1998 15:39:09 -0800 (PST) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id PAA06798 for ; Tue, 17 Feb 1998 15:38:54 -0800 (PST) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id ; Wed, 18 Feb 1998 10:31:45 +1100 Message-ID: From: Alan Lloyd To: "'ietf-ldup@imc.org'" Subject: FREE (Directory) X.500 DAP/LDAPV3 Application Client Stack Sou rce Code Date: Wed, 18 Feb 1998 10:31:43 +1100 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ietf-ldup@imc.org Precedence: bulk > Dear All, the intent of this release note is to provide advanced > information to the IT/EC industry of a major step in the consolidation > of global directory standards as used by Electronic Commerce > applications. > > OpenDirectory is a leading vendor of Lightweight > Directory Access Protocol (LDAP) and X.500 directory products and wish > to assist the Electronic Commerce, directory application and system > vendors who require directory access technology to be incorporated > into their own products. To this end, OpenDirectory is making its > DXapi - X.500 Directory Access Protocol (DAP) client software stack > source code (which operates over TCP/IP and the Internet) available > without any license fees to qualified developers. > > DAP functionality is considered as having > similar functionality to that of LDAP V3. However, DAP provides > additional directory services such as List and Read operations and > other parameters for distributed directory service controls. The DXapi > release supports LDAP V3 filters, LDAPV3 distinguished name forms and > some LDAP V3 schema. The DXapi is also provided with application > example code, documentation and an LDAP style API, which enables the > rapid integration of LDAP type applications. > > OpenDirectory will initially provide the DXapi > source code to selected development organizations who wish to develop > EC type LDAP/DAP applications that can leverage off the power of full > X.500 Directory System Agents (DSA) systems and interconnected LDAP > servers. OpenDirectory may release the DXapi to the wider market at a > later date, but this may be subject to pricing and demand. > > The release of this API should enable the rapid > development of client based directory access modules for services such > as EC, DEN, mobile telephone systems, white page/yellow pages, DNS, > Radius, X.509 certificate management and ILS, etc. In addition, the > release will also provide another major step in the global > harmonisation of LDAP and X.500 directory technologies. > > Any interested organizations can seek further > details of OpenDirectory's directory products through our web site > www.opendirectory.com or for source code release details, email > dxapi@opendirectory.com.au. > > From owner-ietf-ldup Wed Mar 4 08:51:19 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id IAA22253 for ietf-ldup-bks; Wed, 4 Mar 1998 08:51:19 -0800 (PST) Received: from epic.iris.com (epic.iris.com [198.112.211.21]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id IAA22249 for ; Wed, 4 Mar 1998 08:51:17 -0800 (PST) From: Mike_O'Brien@iris.com Received: from arista.iris.com ([9.95.65.15]) by epic.iris.com (Lotus Domino 156) ; Wed, 4 Mar 1998 11:46:15 -0500 Received: by arista.iris.com(Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) id 852565BD.005CA78D ; Wed, 4 Mar 1998 11:52:02 -0500 X-Lotus-FromDomain: IRIS To: ietf-ldup@imc.org Message-ID: <852565BD.005B803D.00@arista.iris.com> Date: Wed, 4 Mar 1998 11:44:24 -0500 Subject: LDUP charter discussion Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-ldup@imc.org Precedence: bulk I would say that we are clearly interested in number 4 (Multi-Master). I would also answer YES to all of the points except the meta schema. I agree with Ed that it would take us down a dead end road. Schemas are still evolving and a meta-schema is just not practical in the real world. One issue that I don't see here is how to handle conflicts. What would the standard policy be on attribute conflicts for example. Mike O'Brien ( Iris Associates ) X-Sender: jstrassn@cupcake.cisco.com >Date: Sat, 31 Jan 1998 14:29:34 -0800 >To: "Ed Reed" , ietf-ldup@imc.org, cweider@microsoft.com >From: "John C. Strassner" >Subject: Re: LDUP charter discussion >Sender: owner-ietf-ldup@imc.org > >I have seen requirements for 1-4. I think that the order should be as is >(with the option that 3 be removed if there is a sufficient lack of >interest), though i would like to go on record that in terms of need, 4 is, >imho, highest. Having said that, I think that we need to at least do the >work on 1 and 2 in order to be able to be in a position to do the work for 4. > >5 - NO, agreeing on a formal meta-schema when we can't agree on something >as simple as a person schema is hopeless. Besides, the general problem of >schema synch is really hard and is fraught with many obtuse and very >difficult end points. > >6 - YES, I agree with both of you, who seem to be in violent agreement > >7 - YES > >8 - YES. We sorely need the formal definition of replication policies that >give better control over what gets replicated when, why and how. Otherwise >we will never match business needs. > >9 - I think we need more discussion on this one. Reload especially will >most probably be destructive, and I think that we need to carefully >consider the implications of which content we want to nuke before we hit >the enter button > >10 - YES > >John Strassner >Chief Architect, Network Service and Management Business Unit >Cisco Systems > >At 07:03 PM 1/26/98 -0700, Ed Reed wrote: >>Let the games be engaged! >> >>I agree work should proceed on 1, 2, and 4. I've not seen requirements >for 3 in our work. >> >>5 - YES - even if, as Chris points out below, mechanisms should be able to >synch with non-LDAP directories, I strongly believe that a formal >meta-schema needs to be agreed to, and means to express the schema of the >data being transmitted, as part of any rational synchronization scheme >(sorry for the pun!) >>6 - Yes - the management of distributed knowledge, ie the various >addresses associated with superior and subordinate references in the >namespace, is the only way I know to inform LDAP servers about referrals to >be returned for non-local data. Synchronization of addresses, server >names, replica types, sparse replica and index inventories, etc. is really >needed to create a distributed LDAP service, which is what I (we?) really >want to see evolve. At the very least, let us agree on a base set of >attributes, their interpretation, access controls on whether they may be >replicated (it's not always desireable), and a way to extend the set of >attributes associated with subordinate references (for things like >inherited attribute values, access control policies, and other operational >information). >>7 - Yes - Without security and access control standards, we'll only be >synchronizing public, valueless information...we're supposed to be working >towards interoperable solutions, even ones which will allow customers to >build distributed services from a mixed group of heterogeneous suppliers. >Now, that may be ambitious, and may even run counter to some technology >providers' objectives (my own company has been accused of such things in >the past, even!) - and it's a hard thing. But isn't that what the industry >is expecting? Does ANYONE want to explain to the press that LDAP is only >about address book synchronization, and not network management or user >management? Not ME! >>8 - Not immediately. As long as the synchronization information is fully >self contained (see #6 above). >>9 - No - only as a special case of synchronization (I got stuff and you >don't). However, SOMEONE should document and continue to develop LDIF as a >flat file representation of data to be loaded. That could as easily be >done here as other places, I guess. >>10 - I mentioned these at the meeting in Washington. I suspect most folks >will have trouble debugging their directories and the interoperability >conformance of synchronization protocols with out it. "Ok, you've >completed the synch - are our two replicas really the same? Prove it!" >> >>Comments welcome! >> >>Ed >> >> >>------------------- >>Ed Reed, Chief Architect >>Network Services Group >>Novell, Inc. >>+1 801 861 3320 >> >>>>> Chris Weider 01/26/98 04:37PM >>> >>Hi folks: >> From the minutes: >>Potential work items: >>1. 1-way dir synch >>2. 2-way dir synch >>3. Floating single master dir synch >>4. Multi-master dir synch >> >>Open questions: >>5: Do we need to solve the schema synch problem to make progress on general >>dir synch? >>6: Do we need to solve the distributed knowledge synch problem? >>7: What about security and access control? >>8: Do we need to standardize the mechanisms for selecting which content to >>replicate? >>9: Do we need to standardize how the directory is initially populated (as >>well as reload of data)? >>10: Do we need to cover replica compare and replica diff? >> >>Additional items: >>Cross-realm replication >>Partial and fractional repliation >>Consistency models >> >>There was a discussion at the IETF about which of the potential work items >>should be done. Everyone was pretty happy with 1,2, and 4. There was less >>consensus on 3. There was no consensus on which order these items should be >>done in. In any case, the first work items for the group would need to be a >>requirements document and an applicability statement. >> >>On the open questions, my thinking goes >>5: No, as these mechanisms should be flexible enough to synch with targets >>other than LDAP servers >>6: Yes, if we want LDAP servers to have as consistent a view of the world as >>possible >>7: Absolutely but we're blocked on the access control standard >>8: Yes >>9: Yes >>10: No >> >>We need a definition of 'cross-realm replication'. >> >>I'd like to see if there's some sort of consensus by the middle of next week >>(Feb 5). >>Let the games begin :^) >>Chris >> >> > From owner-ietf-ldup Tue Mar 10 08:39:18 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id IAA20472 for ietf-ldup-bks; Tue, 10 Mar 1998 08:39:18 -0800 (PST) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id IAA20467 for ; Tue, 10 Mar 1998 08:39:17 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id IAA27352 for ; Tue, 10 Mar 1998 08:37:39 -0800 (PST) Received: from netscape.com ([208.12.63.54]) by dredd.mcom.com (Netscape Messaging Server 3.5) with ESMTP id AAA2997 for ; Tue, 10 Mar 1998 08:37:39 -0800 Message-ID: <35056C52.9015AC79@netscape.com> Date: Tue, 10 Mar 1998 08:37:38 -0800 From: ggood@netscape.com (Gordon Good) X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: ietf-ldup@imc.org Subject: LA meeting times Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk Are the ldup (or the ldapext) meeting times set for the Los Angeles IETF meeting? I didn't see them on the agenda at http://www.ietf.org/meetings/agenda_la.html. From owner-ietf-ldup Tue Mar 10 10:20:29 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id KAA21436 for ietf-ldup-bks; Tue, 10 Mar 1998 10:20:29 -0800 (PST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.41]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id KAA21432 for ; Tue, 10 Mar 1998 10:20:28 -0800 (PST) Received: by mail1.microsoft.com with Internet Mail Service (5.5.1960.3) id ; Tue, 10 Mar 1998 10:19:02 -0800 Message-ID: From: Chris Weider To: "'ggood@netscape.com'" , ietf-ldup@imc.org Subject: RE: LA meeting times Date: Tue, 10 Mar 1998 10:18:51 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ietf-ldup@imc.org Precedence: bulk I don't know about LDAPext. I've requested a slot for LDUP but have not heard anything back. Chris > -----Original Message----- > From: ggood@netscape.com [SMTP:ggood@netscape.com] > Sent: Tuesday, March 10, 1998 8:38 AM > To: ietf-ldup@imc.org > Subject: LA meeting times > > Are the ldup (or the ldapext) meeting times set for the Los Angeles IETF > meeting? I didn't see them on the agenda at > http://www.ietf.org/meetings/agenda_la.html. From owner-ietf-ldup Tue Mar 10 10:38:49 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id KAA21686 for ietf-ldup-bks; Tue, 10 Mar 1998 10:38:49 -0800 (PST) Received: from inet16.us.oracle.com (inet16.us.oracle.com [192.86.155.100]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id KAA21682 for ; Tue, 10 Mar 1998 10:38:48 -0800 (PST) Received: from mailsun2.us.oracle.com (mailsun2.us.oracle.com [144.25.88.74]) by inet16.us.oracle.com (8.8.5/8.8.5) with SMTP id KAA09998; Tue, 10 Mar 1998 10:37:36 -0800 (PST) Received: by mailsun2.us.oracle.com (SMI-8.6/37.8) id KAA00878; Tue, 10 Mar 1998 10:47:12 -0800 Message-Id: <199803101847.KAA00878@mailsun2.us.oracle.com> Date: 10 Mar 98 10:15:42 -0800 From: "Uppili Srinivasan" To: ietf-ldapext@netscape.com, ietf-asid@umich.edu, ietf-ldup@imc.org Subject: Request for The LDAP WG meeting times X-Orcl-Application: InterOffice Version4.2.0.0.00 MIME-Version: 1.0 X-Mailer: Oracle InterOffice (version 4.1.1.3.40) content-type: multipart/alternative; boundary="=_ORCL_18650210_0r0" Sender: owner-ietf-ldup@imc.org Precedence: bulk --=_ORCL_18650210_0r0 Content-Type:text/plain; charset="us-ascii" Content-Transfer-Encoding:7bit To the respective chairs of the LDAP related working groups: Please try to get your slots on the same day. Please confirm it ASAP. Thanks! -Uppili Srinivasan ____________________________________________________________________________ Oracle Corporation | Box 659210 |Phone: (650)506-3039 Internet: usriniva@us.oracle.com 200 Oracle Pkwy |Fax: (650)506-7430 Redwood Shores |X.400: c=us; a=telemail; p=oracle; o=oragate; s=usriniva CA 94065 | ___________________|________________________________________________________ --=_ORCL_18650210_0r0 Content-Type:application/x-compressed-rtf Content-Transfer-Encoding:base64 JQIAANIDAABMWkZ1QCH+y/8ACgEPAhUCpAPkBesCgwBQEwNUAgBjaArAc2V07jIGAAbDAoMy BEcIVQeybQKDMxMPFBY0BEYCAHDocnExFSx9CoAIzwnZ4jsY0jI1NRksGAENosELYG5nMTAz FJALA/BsaTE4DfAFEBzCC1UBEvFzMTcgVG8gkHRoZSAY4HNwBZBYdGl2HpARsWkR4CCEb2Ye Y0xEQVAeoaULYHQJgCB3BbBrC4AMZyAJwAhgcHM6IGAgUGxlYRHwHmBylnkeYB5QZxIAIHkI YXQgcxhwdB+xA6AecnOCYQeAIGRheS4iB4kFoG5mH5BtIGkFQLRBUyBgLgqFCoVUEcDwbmtz IQqHC2QWMQvygmMN4CAtVXBwAxDuaQYABRADAHYiUAORCoV+XysfLC8tPy5PLsUm5k/OcgDQ IjAVIXJwBbAgwBppI/F8IgAKhUJveOAgNjU5MhwAIgAyxah8UGgCIGUh8CgyYEQwKTPwNi0z HBA5PTLBSQIwBJESACHxdXO1KgRANYAuMQEwgS4FoB8l4CbmAdApUDBVUGt3YyKwMyJGYXgh 8TPIN/Y0NGAxl1IJgCEQBHAGAMczcB6xMwRYLjQ3gCHwhGM9NYA7IGE9INDPIjAAwAMQPHBw PTZEPHDabz1iZyDBPHBzPEEqBOExl0NBIDk74DJgMsfvMzExly7PQcB8Qc9D70T/fy+EJuZG aCaMHV0KhRgBAAFKEA== --=_ORCL_18650210_0r0-- From owner-ietf-ldup Tue Mar 10 11:01:11 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA21965 for ietf-ldup-bks; Tue, 10 Mar 1998 11:01:11 -0800 (PST) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id LAA21961 for ; Tue, 10 Mar 1998 11:01:10 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id KAA05990 for ; Tue, 10 Mar 1998 10:59:33 -0800 (PST) Received: from netscape.com ([208.12.63.97]) by dredd.mcom.com (Netscape Messaging Server 3.5) with ESMTP id AAA4380; Tue, 10 Mar 1998 10:59:32 -0800 Message-ID: <35058B0E.E8B15E80@netscape.com> Date: Tue, 10 Mar 1998 10:48:47 -0800 From: Tim Howes Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.04 [en] (X11; I; IRIX 6.2 IP22) MIME-Version: 1.0 To: Chris Weider CC: "'ggood@netscape.com'" , ietf-ldup@imc.org Subject: Re: LA meeting times References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk LDAPEXT is meeting Wednesday, April 1, 9:00-11:30am. -- Tim Chris Weider wrote: > I don't know about LDAPext. I've requested a slot for LDUP but have not > heard anything back. > Chris > > > -----Original Message----- > > From: ggood@netscape.com [SMTP:ggood@netscape.com] > > Sent: Tuesday, March 10, 1998 8:38 AM > > To: ietf-ldup@imc.org > > Subject: LA meeting times > > > > Are the ldup (or the ldapext) meeting times set for the Los Angeles IETF > > meeting? I didn't see them on the agenda at > > http://www.ietf.org/meetings/agenda_la.html. From owner-ietf-ldup Sun Mar 15 13:29:54 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id NAA22149 for ietf-ldup-bks; Sun, 15 Mar 1998 13:29:54 -0800 (PST) Received: from ip78.129.isdn.hogia.net (ip78.129.isdn.hogia.net [195.78.129.78]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id NAA22145 for ; Sun, 15 Mar 1998 13:29:52 -0800 (PST) Message-Id: <199803152129.NAA22145@mail.proper.com> Received: from 195.78.129.68 by ip78.129.isdn.hogia.net with SMTP (QuickMail Pro Server for MacOS 1.1d1); 15 MAR 98 22:26:06 UT X-Mailer: Microsoft Outlook Express for Macintosh - 4.0a (190) Date: Sun, 15 Mar 1998 22:28:16 +0100 Subject: LDIF Q and comment From: "Paul Panotzki" To: ietf-ldup@imc.org, ietf-asid@umich.edu Mime-version: 1.0 X-Priority: 3 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk Hi all! Question: In the draft-ietf-asid-ldif-02.txt I can't see that records are necessarily separated by an extra SEP (CRLF | LF). Am I reading the BNF incorrectly? Or is this legal: dn:cn=Paul Panotzki,o=Object Zone,c=SE mail:paul@objectzone.se dn:cn=Per Weinberger,0=Object Zone,c=SE mail:pelle@objectzone.se Comment: I've been implementing the LDIF format in our server and found that the attribute specification forces the implementor to do a lot of optimizations in order for the imports to be quick. Attributes can potentially be quite long (for example "facsimileTelephoneNumber"), and they don't come in any particular order. So there might be a lot of internal schema lookups and string compares when inserting the data in the correct places. I was fiddling with a workaround which seemed to sped things up a bit and shrunk the file a bit (at least in our implementation). When generating an LDIF file, an attribute meta header is first inserted in the file. This header contains a list of pairs of attribute name and a numeric hash of the attribute name. In the rest of the file, instead of using the attribute names the hash is used. Example: version:1 attr-meta:objectClass 1 $ cn 2 $ mail 3 dn:o=Acme,c=US 1:top 1:person 2:Joe Smith 2:joe@acme.com Could this be a useful addition to the format? Best regards, Paul ----------------------------------------------------------------------- Paul Panotzki Phone: +46 8 730 30 98 Object Zone AB Fax: +46 8 444 61 28 ----------------------------------------------------------------------- From owner-ietf-ldup Mon Mar 16 08:44:51 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id IAA14862 for ietf-ldup-bks; Mon, 16 Mar 1998 08:44:51 -0800 (PST) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id IAA14858 for ; Mon, 16 Mar 1998 08:44:39 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id IAA14174 for ; Mon, 16 Mar 1998 08:43:31 -0800 (PST) Received: from netscape.com ([208.12.63.54]) by dredd.mcom.com (Netscape Messaging Server 3.5) with ESMTP id AAA157; Mon, 16 Mar 1998 08:43:30 -0800 Message-ID: <350D56AF.C7E3414E@netscape.com> Date: Mon, 16 Mar 1998 08:43:27 -0800 From: ggood@netscape.com (Gordon Good) X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Paul Panotzki CC: ietf-ldup@imc.org, ietf-asid@umich.edu Subject: Re: LDIF Q and comment References: <199803152129.NAA22145@mail.proper.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msCE7A1EBA516B001030E27CE6" Sender: owner-ietf-ldup@imc.org Precedence: bulk This is a cryptographically signed message in MIME format. --------------msCE7A1EBA516B001030E27CE6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Paul Panotzki wrote: > Hi all! > > Question: > In the draft-ietf-asid-ldif-02.txt I can't see that records are necessarily > separated by an extra SEP (CRLF | LF). Am I reading the BNF incorrectly? Or > is this legal: > > dn:cn=Paul Panotzki,o=Object Zone,c=SE > mail:paul@objectzone.se > dn:cn=Per Weinberger,0=Object Zone,c=SE > mail:pelle@objectzone.se > No, this is not legal. Note that attrval-spec must be terminated with a SEP, and a SEP must also follow the last attrval-spec in an ldif-attrval-record. Your example is missing one of those SEPs. > Comment: > I've been implementing the LDIF format in our server and found that the > attribute specification forces the implementor to do a lot of optimizations > in order for the imports to be quick. Attributes can potentially be quite > long (for example "facsimileTelephoneNumber"), and they don't come in any > particular order. So there might be a lot of internal schema lookups and > string compares when inserting the data in the correct places. > > I was fiddling with a workaround which seemed to sped things up a bit and > shrunk the file a bit (at least in our implementation). When generating an > LDIF file, an attribute meta header is first inserted in the file. This > header contains a list of pairs of attribute name and a numeric hash of the > attribute name. In the rest of the file, instead of using the attribute > names the hash is used. Example: > > version:1 > attr-meta:objectClass 1 $ cn 2 $ mail 3 > > dn:o=Acme,c=US > 1:top > 1:person > 2:Joe Smith > 2:joe@acme.com > > Could this be a useful addition to the format? While this would certainly speed things up "a bit" and make the LDIF file smaller, I think we'd want to quantify what "a bit" means, for typical LDIF files, so that we can decide if it's worth introducing additional complexity into the LDIF spec. My gut feeling is that it's not worth it. Also, I just submitted an updated LDIF draft. It's at ftp://ietf.org/internet-drafts/draft-good-ldap-ldif-00.txt. It's now an individual submission, in anticipation of asid closing down. There is a change summary at the end of the document. --------------msCE7A1EBA516B001030E27CE6 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIGwgYJKoZIhvcNAQcCoIIGszCCBq8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BSkwggJoMIIB0aADAgECAgIKbzANBgkqhkiG9w0BAQQFADB3MQswCQYDVQQGEwJVUzEsMCoG A1UEChMjTmV0c2NhcGUgQ29tbXVuaWNhdGlvbnMgQ29ycG9yYXRpb24xHDAaBgNVBAsTE0lu Zm9ybWF0aW9uIFN5c3RlbXMxHDAaBgNVBAMTE3Jvb3RjYS5uZXRzY2FwZS5jb20wHhcNOTgw MzEyMTk0MDEzWhcNOTgwOTA4MTk0MDEzWjCBhzELMAkGA1UEBhMCVVMxJjAkBgNVBAoTHU5l dHNjYXBlIENvbW11bmljYXRpb25zIENvcnAuMRYwFAYDVQQDEw1Hb3Jkb24gUyBHb29kMSEw HwYJKoZIhvcNAQkBFhJnZ29vZEBuZXRzY2FwZS5jb20xFTATBgoJkiaJk/IsZAEBEwVnZ29v ZDBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDiq/4MD9jix6GMhWto/QMNLmSHoqFqLbHZLEiK 2iyvIO7ewVL1TEInb9Be/gGiytnTJgRBhVPX7RsgZojnwJ4RAgMBAAGjNjA0MBEGCWCGSAGG +EIBAQQEAwIAoDAfBgNVHSMEGDAWgBT84FToB/GV3jr3mcau+hUMbsQukjANBgkqhkiG9w0B AQQFAAOBgQAOI4HppvITt9kHdJJYsBhXwOjP6nZPQVi9qjZY/TXfHb8hF7Lbiu4tublZNYUS 1YAyYQdqSX9ZHq6Mxg/lTnP4lsfsL3LY7hY2sYWnhamhPX6sYOK1VygkzfLgTueuCOot+4mZ QIxJU+rD1/bAGpSAl9grCuYVAGyYGx2Pk7I3wDCCArkwggIioAMCAQICAQEwDQYJKoZIhvcN AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25z IENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0ZW1zMRwwGgYDVQQDExNy b290Y2EubmV0c2NhcGUuY29tMB4XDTk3MDMyNjAxNDQzOFoXDTk5MDMyNjAxNDQzOFowdzEL MAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIENvcnBvcmF0 aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0ZW1zMRwwGgYDVQQDExNyb290Y2EubmV0 c2NhcGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDBqj7+LT+lh8NH3/vabdgY oEU9+cebQ84ntFoTnBF9v9LyiF7Hv7KLebqn5SgLQKaOmTFVxfjOlgZeIoR2vwEiYsOpmSe7 CGgRFMcKftyyh/jH4CQwAbwtloXnGcMuoZN3LDQYL/vfokiz56CvegPki4x1pC2TIIwgOVSn RbpAZQIDAQABo1UwUzARBglghkgBhvhCAQEEBAMCAAQwHQYDVR0OBBYEFPzgVOgH8ZXeOveZ xq76FQxuxC6SMB8GA1UdIwQYMBaAFPzgVOgH8ZXeOveZxq76FQxuxC6SMA0GCSqGSIb3DQEB BAUAA4GBAFn32xtcegbE5sWYYYQYzvoGSyCxJMr8WX4/GPHkvqwQ2UrSaY9u/JHK9QQcCq65 +so57E0AGaZnlMzlQFtZhCSS8AEsGeQLLzsc9g8bhUXsw5fx4LpAy91XcYngi0lwSR/dtss0 b2/PLyHkU9EZZo9nYvDd7h1IKvBHe4N0h3nIMYIBYTCCAV0CAQEwfTB3MQswCQYDVQQGEwJV UzEsMCoGA1UEChMjTmV0c2NhcGUgQ29tbXVuaWNhdGlvbnMgQ29ycG9yYXRpb24xHDAaBgNV BAsTE0luZm9ybWF0aW9uIFN5c3RlbXMxHDAaBgNVBAMTE3Jvb3RjYS5uZXRzY2FwZS5jb20C AgpvMAkGBSsOAwIaBQCgfTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw05ODAzMTYxNjQzMjdaMB4GCSqGSIb3DQEJDzERMA8wDQYIKoZIhvcNAwICASgwIwYJ KoZIhvcNAQkEMRYEFDYVlPHaOxBUGKlQcO8e7w6V1DYmMA0GCSqGSIb3DQEBAQUABECVP8Bw YY5pvVfc1cyehw0QY/bVEYnvTn8zMrzccTClDddOil2dwYrWZpyhuuUPLFIW+r3M9VJcPRaP +l/I3yMG --------------msCE7A1EBA516B001030E27CE6-- From owner-ietf-ldup Mon Mar 16 12:05:57 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id MAA21609 for ietf-ldup-bks; Mon, 16 Mar 1998 12:05:57 -0800 (PST) Received: from ip78.129.isdn.hogia.net (ip78.129.isdn.hogia.net [195.78.129.78]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id MAA21605 for ; Mon, 16 Mar 1998 12:05:54 -0800 (PST) Message-Id: <199803162005.MAA21605@mail.proper.com> Received: from 195.78.129.68 by ip78.129.isdn.hogia.net with SMTP (QuickMail Pro Server for MacOS 1.1d1); 16 MAR 98 21:02:31 UT X-Mailer: Microsoft Outlook Express for Macintosh - 4.0a (190) Date: Mon, 16 Mar 1998 20:57:32 +0100 Subject: Re: LDIF Q and comment From: "Paul Panotzki" To: ggood@netscape.com (gordon good) CC: ietf-ldup@imc.org, ietf-asid@umich.edu Mime-version: 1.0 X-Priority: 3 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk >Paul Panotzki wrote: >> In the draft-ietf-asid-ldif-02.txt I can't see that records are necessarily >> separated by an extra SEP (CRLF | LF). Am I reading the BNF incorrectly? Or >> is this legal: >No, this is not legal. Note that attrval-spec must be terminated with a SEP, >and a SEP must also follow the last attrval-spec in an ldif-attrval-record. >Your example is missing one of those SEPs. Ah, I see that in the new draft. It was missing in the old one. Thank you! >> Comment: >> I've been implementing the LDIF format in our server and found that the >> attribute specification forces the implementor to do a lot of optimizations >> in order for the imports to be quick. Attributes can potentially be quite >> long (for example "facsimileTelephoneNumber"), and they don't come in any >> particular order. So there might be a lot of internal schema lookups and >> string compares when inserting the data in the correct places. >> >> I was fiddling with a workaround which seemed to sped things up a bit and >> shrunk the file a bit (at least in our implementation). When generating an >> LDIF file, an attribute meta header is first inserted in the file. This >> header contains a list of pairs of attribute name and a numeric hash of the >> attribute name. In the rest of the file, instead of using the attribute >> names the hash is used. Example: >> >> version:1 >> attr-meta:objectClass 1 $ cn 2 $ mail 3 >> >> dn:o=Acme,c=US >> 1:top >> 1:person >> 2:Joe Smith >> 2:joe@acme.com >> >> Could this be a useful addition to the format? > >While this would certainly speed things up "a bit" and make the LDIF file >smaller, I think we'd want to quantify what "a bit" means, for typical LDIF >files, so that we can decide if it's worth introducing additional complexity >into the LDIF spec. My gut feeling is that it's not worth it. I think you're right about not making LDIF too complex. It is not a big problem to optimize parsers so that attribute field lookups are made more quickly. The "a bit" part depends a lot on the parser implementation and database backend. In my case the import time was cut in half, but I found ways of improving import times without vandalizing the current LDIF spec. I'm not willing to do a comprehensive complexity analysis of how much time and space is saved, so I'll follow your gut feeling and leave it alone. I like LDIF, but it is just a tad wordy. A binary equivalent would be a nice complement... Best regards, Paul ----------------------------------------------------------------------- Paul Panotzki Phone: +46 8 730 30 98 Object Zone AB Fax: +46 8 444 61 28 ----------------------------------------------------------------------- From owner-ietf-ldup Tue Mar 17 07:20:18 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id HAA13495 for ietf-ldup-bks; Tue, 17 Mar 1998 07:20:18 -0800 (PST) Received: from mons (6089@mons.uio.no [129.240.130.14]) by mail.proper.com (8.8.8/8.7.3) with SMTP id HAA13491 for ; Tue, 17 Mar 1998 07:20:17 -0800 (PST) Received: from bombur2.uio.no (actually bombur2.uio.no [129.240.200.72]) by mons with SMTP (PP); Tue, 17 Mar 1998 16:19:27 +0100 Received: by bombur2.uio.no ; Tue, 17 Mar 1998 16:19:26 +0100 (MET) Date: Tue, 17 Mar 1998 16:19:26 +0100 (MET) From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Paul Panotzki Cc: ggood@netscape.com (gordon good), ietf-ldup@imc.org, ietf-asid@umich.edu Subject: Re: LDIF Q and comment In-Reply-To: <199803162005.PAA18472@stayhungry.rs.itd.umich.edu> References: <199803162005.PAA18472@stayhungry.rs.itd.umich.edu> X-Mailer: VM 6.37 under Emacs 19.34.1 Sender: owner-ietf-ldup@imc.org Precedence: bulk Paul Panotzki writes: > I like LDIF, but it is just a tad wordy. A binary equivalent would be a nice > complement... I quite agree, but that would not be LDIF: fully portable, easy to parse, human-readable (except the base64 part), even human-writeable. I suggest you instead define your own format or extension to LDIF. If that's easy to translate to/from LDIF, you'll retain most of LDIF's advantages as well. Maybe you can even design its rules so that an existing preproessor like m4 can translate your format into LDIF. (You might look over LDIF to see if there are convenient currently- illegal constructs or characters or something that you can use to hook in extensions. If there is not, you maybe you should suggest a change to LDIF to make this easier.) -- Hallvard From owner-ietf-ldup Tue Mar 17 14:13:37 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id OAA17068 for ietf-ldup-bks; Tue, 17 Mar 1998 14:13:37 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.29]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id OAA17063 for ; Tue, 17 Mar 1998 14:13:36 -0800 (PST) Received: by INET-04-IMC with Internet Mail Service (5.5.1960.3) id ; Tue, 17 Mar 1998 14:12:57 -0800 Message-ID: From: Chris Weider To: "'ietf-ldup@imc.org'" Cc: "'agenda@ietf.org'" Subject: LDUP BOF Agenda Date: Tue, 17 Mar 1998 14:05:18 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ietf-ldup@imc.org Precedence: bulk What: LDUP BOF (LDAP Directory Synchronization) When: Wednesday, April 1, 15:30 -17:30 Agenda: 1 hour: Charter discussion and closure (A draft charter will be sent out tomorrow) 40 minutes: Discussion of requirements document 20 minutes: Discussion of applicability statement Documents to read: draft-ietf-asid-replica-req-01.txt See you there! Chris From owner-ietf-ldup Tue Mar 17 14:27:47 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id OAA17163 for ietf-ldup-bks; Tue, 17 Mar 1998 14:27:47 -0800 (PST) Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.7.3) with SMTP id OAA17159 for ; Tue, 17 Mar 1998 14:27:43 -0800 (PST) Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Tue, 17 Mar 1998 15:26:34 -0700 Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Tue, 17 Mar 1998 15:25:52 -0700 From: "Ed Reed" To: ietf-ldup@imc.org, cweider@microsoft.com Subject: Re: LDUP BOF Agenda Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: owner-ietf-ldup@imc.org Precedence: bulk Amazing - this arrived just as i sent out my last note...sorry, I guess = great minds think alike... ------------------- Ed Reed, Technologist Group Technology Office Novell, Inc. +1 801 861 3320 >>> Chris Weider 03/17/1998 15:05:18 >>> What: LDUP BOF (LDAP Directory Synchronization) When: Wednesday, April 1, 15:30 -17:30 Agenda:=20 1 hour: Charter discussion and closure (A draft charter will be sent out tomorrow) 40 minutes: Discussion of requirements document 20 minutes: Discussion of applicability statement Documents to read: draft-ietf-asid-replica-req-01.txt=20 See you there! Chris From owner-ietf-ldup Tue Mar 17 14:26:52 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id OAA17152 for ietf-ldup-bks; Tue, 17 Mar 1998 14:26:52 -0800 (PST) Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.7.3) with SMTP id OAA17148 for ; Tue, 17 Mar 1998 14:26:51 -0800 (PST) Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Tue, 17 Mar 1998 15:25:18 -0700 Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Tue, 17 Mar 1998 15:24:39 -0700 From: "Ed Reed" To: ietf-ldup@imc.org, Mike_O'Brien@iris.com Subject: LDUP Meeting in LA? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: owner-ietf-ldup@imc.org Precedence: bulk This group sure has been quite, lately. Are we meeting in LA? On = Wednesday? Can I safely schedule some other off-site meetings on Tuesday, or are we = likely to want to get together then? Ed ------------------- Ed Reed, Technologist Group Technology Office Novell, Inc. +1 801 861 3320 >>> 03/04/1998 09:44:24 >>> I would say that we are clearly interested in number 4 (Multi-Master).= I would also answer YES to all of the points except the meta schema. I agree with Ed that it would take us down a dead end road. Schemas are still evolving and a meta-schema is just not practical in the real world. One issue that I don't see here is how to handle conflicts. What would = the standard policy be on attribute conflicts for example. Mike O'Brien ( Iris Associates ) X-Sender: jstrassn@cupcake.cisco.com=20 >Date: Sat, 31 Jan 1998 14:29:34 -0800 >To: "Ed Reed" , ietf-ldup@imc.org, cweider@microsoft.com=20 >From: "John C. Strassner" >Subject: Re: LDUP charter discussion >Sender: owner-ietf-ldup@imc.org=20 > >I have seen requirements for 1-4. I think that the order should be as is >(with the option that 3 be removed if there is a sufficient lack of >interest), though i would like to go on record that in terms of need, 4 is, >imho, highest. Having said that, I think that we need to at least do the >work on 1 and 2 in order to be able to be in a position to do the work = for 4. > >5 - NO, agreeing on a formal meta-schema when we can't agree on something >as simple as a person schema is hopeless. Besides, the general problem of >schema synch is really hard and is fraught with many obtuse and very >difficult end points. > >6 - YES, I agree with both of you, who seem to be in violent agreement > >7 - YES > >8 - YES. We sorely need the formal definition of replication policies = that >give better control over what gets replicated when, why and how. = Otherwise >we will never match business needs. > >9 - I think we need more discussion on this one. Reload especially will >most probably be destructive, and I think that we need to carefully >consider the implications of which content we want to nuke before we hit >the enter button > >10 - YES > >John Strassner >Chief Architect, Network Service and Management Business Unit >Cisco Systems > >At 07:03 PM 1/26/98 -0700, Ed Reed wrote: >>Let the games be engaged! >> >>I agree work should proceed on 1, 2, and 4. I've not seen requirements >for 3 in our work. >> >>5 - YES - even if, as Chris points out below, mechanisms should be able to >synch with non-LDAP directories, I strongly believe that a formal >meta-schema needs to be agreed to, and means to express the schema of the >data being transmitted, as part of any rational synchronization scheme >(sorry for the pun!) >>6 - Yes - the management of distributed knowledge, ie the various >addresses associated with superior and subordinate references in the >namespace, is the only way I know to inform LDAP servers about referrals to >be returned for non-local data. Synchronization of addresses, server >names, replica types, sparse replica and index inventories, etc. is = really >needed to create a distributed LDAP service, which is what I (we?) really >want to see evolve. At the very least, let us agree on a base set of >attributes, their interpretation, access controls on whether they may be >replicated (it's not always desireable), and a way to extend the set of >attributes associated with subordinate references (for things like >inherited attribute values, access control policies, and other operational= >information). >>7 - Yes - Without security and access control standards, we'll only be >synchronizing public, valueless information...we're supposed to be = working >towards interoperable solutions, even ones which will allow customers to >build distributed services from a mixed group of heterogeneous suppliers. >Now, that may be ambitious, and may even run counter to some technology >providers' objectives (my own company has been accused of such things in >the past, even!) - and it's a hard thing. But isn't that what the industry >is expecting? Does ANYONE want to explain to the press that LDAP is only >about address book synchronization, and not network management or user >management? Not ME! >>8 - Not immediately. As long as the synchronization information is = fully >self contained (see #6 above). >>9 - No - only as a special case of synchronization (I got stuff and you >don't). However, SOMEONE should document and continue to develop LDIF as a >flat file representation of data to be loaded. That could as easily be >done here as other places, I guess. >>10 - I mentioned these at the meeting in Washington. I suspect most folks >will have trouble debugging their directories and the interoperability >conformance of synchronization protocols with out it. "Ok, you've >completed the synch - are our two replicas really the same? Prove it!" >> >>Comments welcome! >> >>Ed >> >> >>------------------- >>Ed Reed, Chief Architect >>Network Services Group >>Novell, Inc. >>+1 801 861 3320 >> >>>>> Chris Weider 01/26/98 04:37PM >>> >>Hi folks: >> From the minutes: >>Potential work items: >>1. 1-way dir synch >>2. 2-way dir synch >>3. Floating single master dir synch >>4. Multi-master dir synch >> >>Open questions: >>5: Do we need to solve the schema synch problem to make progress on general >>dir synch? >>6: Do we need to solve the distributed knowledge synch problem? >>7: What about security and access control? >>8: Do we need to standardize the mechanisms for selecting which content to >>replicate? >>9: Do we need to standardize how the directory is initially populated = (as >>well as reload of data)? >>10: Do we need to cover replica compare and replica diff? >> >>Additional items: >>Cross-realm replication >>Partial and fractional repliation >>Consistency models >> >>There was a discussion at the IETF about which of the potential work items >>should be done. Everyone was pretty happy with 1,2, and 4. There was = less >>consensus on 3. There was no consensus on which order these items should be >>done in. In any case, the first work items for the group would need to = be a >>requirements document and an applicability statement. >> >>On the open questions, my thinking goes >>5: No, as these mechanisms should be flexible enough to synch with targets >>other than LDAP servers >>6: Yes, if we want LDAP servers to have as consistent a view of the = worlds as >>possible >>7: Absolutely but we're blocked on the access control standard >>8: Yes >>9: Yes >>10: No >> >>We need a definition of 'cross-realm replication'. >> >>I'd like to see if there's some sort of consensus by the middle of next week >>(Feb 5). >>Let the games begin :^) >>Chris >> >> > From owner-ietf-ldup Tue Mar 17 14:41:47 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id OAA17253 for ietf-ldup-bks; Tue, 17 Mar 1998 14:41:47 -0800 (PST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.42]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id OAA17249 for ; Tue, 17 Mar 1998 14:41:46 -0800 (PST) Received: by mail2.microsoft.com with Internet Mail Service (5.5.1960.3) id ; Tue, 17 Mar 1998 14:35:58 -0800 Message-ID: From: Chris Weider To: "'Ed Reed'" , ietf-ldup@imc.org, Mike_O'Brien@iris.com Subject: RE: LDUP Meeting in LA? Date: Tue, 17 Mar 1998 14:27:21 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ietf-ldup@imc.org Precedence: bulk Wednesday it is... I just sent out an agenda and meeting time. Chris > -----Original Message----- > From: Ed Reed [SMTP:ED_REED@novell.com] > Sent: Tuesday, March 17, 1998 2:25 PM > To: ietf-ldup@imc.org; Mike_O'Brien@iris.com > Subject: LDUP Meeting in LA? > > This group sure has been quite, lately. Are we meeting in LA? On > Wednesday? > Can I safely schedule some other off-site meetings on Tuesday, or are we > likely > to want to get together then? > > Ed > > ------------------- > Ed Reed, Technologist > Group Technology Office > Novell, Inc. > +1 801 861 3320 > > >>> 03/04/1998 09:44:24 >>> > > > I would say that we are clearly interested in number 4 > (Multi-Master). > I would also answer YES to all of the points except the meta schema. I > agree with Ed that it would take us down a dead end road. Schemas are > still evolving and a meta-schema is just not practical in the real world. > One issue that I don't see here is how to handle conflicts. What would > the > standard policy be on attribute conflicts for example. > > Mike O'Brien ( Iris Associates ) > > > > X-Sender: jstrassn@cupcake.cisco.com > >Date: Sat, 31 Jan 1998 14:29:34 -0800 > >To: "Ed Reed" , ietf-ldup@imc.org, > cweider@microsoft.com > >From: "John C. Strassner" > >Subject: Re: LDUP charter discussion > >Sender: owner-ietf-ldup@imc.org > > > >I have seen requirements for 1-4. I think that the order should be as is > >(with the option that 3 be removed if there is a sufficient lack of > >interest), though i would like to go on record that in terms of need, 4 > is, > >imho, highest. Having said that, I think that we need to at least do the > >work on 1 and 2 in order to be able to be in a position to do the work > for > 4. > > > >5 - NO, agreeing on a formal meta-schema when we can't agree on something > >as simple as a person schema is hopeless. Besides, the general problem of > >schema synch is really hard and is fraught with many obtuse and very > >difficult end points. > > > >6 - YES, I agree with both of you, who seem to be in violent agreement > > > >7 - YES > > > >8 - YES. We sorely need the formal definition of replication policies > that > >give better control over what gets replicated when, why and how. > Otherwise > >we will never match business needs. > > > >9 - I think we need more discussion on this one. Reload especially will > >most probably be destructive, and I think that we need to carefully > >consider the implications of which content we want to nuke before we hit > >the enter button > > > >10 - YES > > > >John Strassner > >Chief Architect, Network Service and Management Business Unit > >Cisco Systems > > > >At 07:03 PM 1/26/98 -0700, Ed Reed wrote: > >>Let the games be engaged! > >> > >>I agree work should proceed on 1, 2, and 4. I've not seen requirements > >for 3 in our work. > >> > >>5 - YES - even if, as Chris points out below, mechanisms should be able > to > >synch with non-LDAP directories, I strongly believe that a formal > >meta-schema needs to be agreed to, and means to express the schema of the > >data being transmitted, as part of any rational synchronization scheme > >(sorry for the pun!) > >>6 - Yes - the management of distributed knowledge, ie the various > >addresses associated with superior and subordinate references in the > >namespace, is the only way I know to inform LDAP servers about referrals > to > >be returned for non-local data. Synchronization of addresses, server > >names, replica types, sparse replica and index inventories, etc. is > really > >needed to create a distributed LDAP service, which is what I (we?) really > >want to see evolve. At the very least, let us agree on a base set of > >attributes, their interpretation, access controls on whether they may be > >replicated (it's not always desireable), and a way to extend the set of > >attributes associated with subordinate references (for things like > >inherited attribute values, access control policies, and other > operational > >information). > >>7 - Yes - Without security and access control standards, we'll only be > >synchronizing public, valueless information...we're supposed to be > working > >towards interoperable solutions, even ones which will allow customers to > >build distributed services from a mixed group of heterogeneous suppliers. > >Now, that may be ambitious, and may even run counter to some technology > >providers' objectives (my own company has been accused of such things in > >the past, even!) - and it's a hard thing. But isn't that what the > industry > >is expecting? Does ANYONE want to explain to the press that LDAP is only > >about address book synchronization, and not network management or user > >management? Not ME! > >>8 - Not immediately. As long as the synchronization information is > fully > >self contained (see #6 above). > >>9 - No - only as a special case of synchronization (I got stuff and you > >don't). However, SOMEONE should document and continue to develop LDIF as > a > >flat file representation of data to be loaded. That could as easily be > >done here as other places, I guess. > >>10 - I mentioned these at the meeting in Washington. I suspect most > folks > >will have trouble debugging their directories and the interoperability > >conformance of synchronization protocols with out it. "Ok, you've > >completed the synch - are our two replicas really the same? Prove it!" > >> > >>Comments welcome! > >> > >>Ed > >> > >> > >>------------------- > >>Ed Reed, Chief Architect > >>Network Services Group > >>Novell, Inc. > >>+1 801 861 3320 > >> > >>>>> Chris Weider 01/26/98 04:37PM >>> > >>Hi folks: > >> From the minutes: > >>Potential work items: > >>1. 1-way dir synch > >>2. 2-way dir synch > >>3. Floating single master dir synch > >>4. Multi-master dir synch > >> > >>Open questions: > >>5: Do we need to solve the schema synch problem to make progress on > general > >>dir synch? > >>6: Do we need to solve the distributed knowledge synch problem? > >>7: What about security and access control? > >>8: Do we need to standardize the mechanisms for selecting which content > to > >>replicate? > >>9: Do we need to standardize how the directory is initially populated > (as > >>well as reload of data)? > >>10: Do we need to cover replica compare and replica diff? > >> > >>Additional items: > >>Cross-realm replication > >>Partial and fractional repliation > >>Consistency models > >> > >>There was a discussion at the IETF about which of the potential work > items > >>should be done. Everyone was pretty happy with 1,2, and 4. There was > less > >>consensus on 3. There was no consensus on which order these items should > be > >>done in. In any case, the first work items for the group would need to > be > a > >>requirements document and an applicability statement. > >> > >>On the open questions, my thinking goes > >>5: No, as these mechanisms should be flexible enough to synch with > targets > >>other than LDAP servers > >>6: Yes, if we want LDAP servers to have as consistent a view of the > worlds > as > >>possible > >>7: Absolutely but we're blocked on the access control standard > >>8: Yes > >>9: Yes > >>10: No > >> > >>We need a definition of 'cross-realm replication'. > >> > >>I'd like to see if there's some sort of consensus by the middle of next > week > >>(Feb 5). > >>Let the games begin :^) > >>Chris > >> > >> > > > > > From owner-ietf-ldup Wed Mar 25 18:44:41 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id SAA05345 for ietf-ldup-bks; Wed, 25 Mar 1998 18:44:41 -0800 (PST) Received: from mail1-b.microsoft.com (mail1-b.microsoft.com [131.107.3.125]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id SAA05341 for ; Wed, 25 Mar 1998 18:44:40 -0800 (PST) Received: by INET-IMC-01 with Internet Mail Service (5.5.2166.0) id ; Wed, 25 Mar 1998 17:57:57 -0800 Message-ID: From: Chris Weider To: "'ietf-ldup@imc.org'" Subject: Proposed charter for LDUP Date: Wed, 25 Mar 1998 17:51:38 -0800 X-Mailer: Internet Mail Service (5.5.2166.0) Sender: owner-ietf-ldup@imc.org Precedence: bulk Hi gang: Here is my proposed charter for LDUP. We'll be discussing it on Wednesday. Chris LDAP Directory Synchronization (LDUP) Chair: John Strassner, Cisco Systems (johns@cisco.com) Document Editor: Ellen Stokes, IBM (stokes@austin.ibm.com) Mailing List: ietf-ldup@imc.org To Subscribe: ietf-ldup-request@imc.org Archive: http://www.imc.org/ietf-ldup/ As LDAP becomes more widely deployed, synchronization of data between directory servers running different implementations of LDAP becomes an important part of providing a distributed and reliable directory service. However, to this point, LDAP servers have standardized only on the client-server access protocol. Therefore, this group will tackle standardization of synchronization. The approach is to first develop a set of requirements for LDAP directory synchronization, and write an applicability statement that defines for which applications the synchronization protocols will suffice. Once this is done, the working group will address three work items, in this order: one-way directory synchronization, allowing an LDAP directory to act as a source to other services; two-way synchronization, to allow to servers to converge their data; and then multi-master synchronization, to allow widely distributed update and management. Milestones: Jun 98 Publish Applicability Statement as Internet-Draft Aug 98 Publish Directory Synchronization Requirements document as Informational RFC Aug 98 Publish Applicability Statement as Informational RFC Oct 98 Publish specification for One-Way Directory Sync as Internet-Draft Dec 98 Publish spec for Two-way Directory Sync as Internet-Draft Feb 99 Publish One-Way Dir Sync as Proposed Standard Apr 99 Publish Two-way Dir Sync as Proposed Standard Aug 99 Publish Multi-Master Dir Sync as Internet Draft Dec 99 Publish Multi-Master Dir Sync as Proposed Standard From owner-ietf-ldup Thu Mar 26 12:03:38 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id MAA25642 for ietf-ldup-bks; Thu, 26 Mar 1998 12:03:38 -0800 (PST) Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.7.3) with SMTP id MAA25638 for ; Thu, 26 Mar 1998 12:03:37 -0800 (PST) Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Thu, 26 Mar 1998 13:03:17 -0700 Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Thu, 26 Mar 1998 13:02:19 -0700 From: "Ed Reed" To: stokes@austin.ibm.com, jstrassn@cisco.com, ietf-ldup@imc.org, cweider@microsoft.com Cc: Harald.Alvestrand@maxware.no Subject: Re: Proposed charter for LDUP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: owner-ietf-ldup@imc.org Precedence: bulk I don't concur, and don't believe the discussion on the work group = supports,=20 the ordering of work items proposed in the charter...specifically that = after a requirements document is published, that work will proceed with = one-way synch, then two way synch, and then three way synch. There were 7 responses to the request for discussion on charter. O'Brien - "I'd say we are clearly interested in number 4 (Multi-Master)" Huber - "I think the highest priority should go to 4." Lloyd - [to Huber] "Agree" Merrells - 1-way, 2-way, multi-master - "I think that we should tackle = these three, in this order." Stokes - "On items 1-4, the target should be 4 - multi-master." Strassner - "I think that the order should be as is...though i would like = to go on record that in terms of need, 4 is, imho, highest." Reed - "I agree work should proceed on 1, 2, and 4." I'm amending mine to be "work on 4, with 1 and 2 falling out of that", = which is consistent with that I've been saying. That said, there are 5 votes for 4, with 1 noting the need for 4 is = highest. There was 1 vote to work on 1, 2, and then 4. The notion that working first on one way synchronization, and then two-way = synchronization, and then multi master replication will "let us learn as = we go" is wishfull, but mis-leading. There's nothing new to be learned in = the master-slave synchronization world - it's old hat, with NIS, DNS, DISP = and other widely deployed technologies already doing that - and there is = very little to be gained by coming up with yet-another master-slave = protocol that doesn't explicitly include the bits necessary to _also_ = support multi-master replication. I oppose the charter as written, and would replace the second paragraph = and milestones as follows... =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The approach is to first publish the requirements for, and then an = architecture for LDAP directory synchronization. The ITU X.500 DISP will = serve as a basis of comparison for the analysis and design. We will = publish a directory synchronization architecture that will identify the = necessary data elements, security implications, and service responsibilitie= s appropriate to each of several replication scenarios, including one-way = synchronization of information from a master to shadow (slave, read-only) = replicas, and multi-master synchronization of information among two or = more update-able replicas. Finally, a protocol specification for = multi-master synchronization, along with one-way and two-way synchronizatio= n limited subset profiles, will be published. Milestones: Jun 98 Working Group Last Call on Dir Sync Requirements I-D Aug 98 Publish Dir Sync Requirements Document as Informational RFC Aug 98 Publish Directory Synchronization Architecture as I-D (for = discussion at Aug IETF) Dec 98 Publish Dir Sync Architecture to Proposed Standard RFC Feb 99 Publish Multi-Master Dir Sync Spec as I-D Feb 99 Publish One-Way Dir Sync Usage Profile as I-D Sep 99 Publish Multi-Master Dir Sync Spec as Proposed Standard Sep 99 Publish One-Way Dir Sync Usage Profile as Proposed Standard =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Best regards, and see you in LA! Ed ------------------- Ed Reed, Technologist Group Technology Office Novell, Inc. +1 801 861 3320 >>> Chris Weider 03/25/1998 18:51:38 >>> Hi gang: Here is my proposed charter for LDUP. We'll be discussing it on = Wednesday. Chris LDAP Directory Synchronization (LDUP) Chair: John Strassner, Cisco Systems (johns@cisco.com) Document Editor: Ellen Stokes, IBM (stokes@austin.ibm.com) Mailing List: ietf-ldup@imc.org=20 To Subscribe: ietf-ldup-request@imc.org=20 Archive: http://www.imc.org/ietf-ldup/=20 As LDAP becomes more widely deployed, synchronization of data between directory servers running different implementations of LDAP becomes an important part of providing a distributed and reliable directory service. However, to this point, LDAP servers have standardized only on the client-server access protocol. Therefore, this group will tackle standardization of synchronization. The approach is to first develop a set of requirements for LDAP directory synchronization, and write an applicability statement that defines for = which applications the synchronization protocols will suffice. Once this is = done, the working group will address three work items, in this order: one-way directory synchronization, allowing an LDAP directory to act as a source = to other services; two-way synchronization, to allow to servers to converge their data; and then multi-master synchronization, to allow widely distributed update and management.=20 Milestones: Jun 98 Publish Applicability Statement as Internet-Draft Aug 98 Publish Directory Synchronization Requirements document as Informational RFC Aug 98 Publish Applicability Statement as Informational RFC Oct 98 Publish specification for One-Way Directory Sync as Internet-Draft Dec 98 Publish spec for Two-way Directory Sync as Internet-Draft Feb 99 Publish One-Way Dir Sync as Proposed Standard Apr 99 Publish Two-way Dir Sync as Proposed Standard Aug 99 Publish Multi-Master Dir Sync as Internet Draft Dec 99 Publish Multi-Master Dir Sync as Proposed Standard From owner-ietf-ldup Fri Mar 27 08:38:19 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id IAA21273 for ietf-ldup-bks; Fri, 27 Mar 1998 08:38:19 -0800 (PST) Received: from cupcake.cisco.com (cupcake.cisco.com [171.69.1.242]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id IAA21268 for ; Fri, 27 Mar 1998 08:38:15 -0800 (PST) Received: from jstrassn-pc (sj-dial-3-14.cisco.com [171.68.179.15]) by cupcake.cisco.com (8.8.5-Cisco.1/8.6.5) with SMTP id IAA29167; Fri, 27 Mar 1998 08:37:20 -0800 (PST) Message-Id: <3.0.2.32.19980327083719.00a78c30@cupcake.cisco.com> X-Sender: jstrassn@cupcake.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) X-Priority: 2 (High) Date: Fri, 27 Mar 1998 08:37:19 -0800 To: "Ed Reed" , stokes@austin.ibm.com, jstrassn@cisco.com, ietf-ldup@imc.org, cweider@microsoft.com From: "John C. Strassner" Subject: Re: Proposed charter for LDUP Cc: Harald.Alvestrand@maxware.no In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@imc.org Precedence: bulk Ed, thanks for the comments. The problem is that only 7 people responded to the email-call for charter acceptance. At the last LDUP meeting, the majority of people indicated that they were uncomfortable with leaping directly into multi-master. I would suggest that this be our first order of business on Wednesday - one last vote to ensure that this ordering of work is indeed what the group wants to work on. regards, John At 01:02 PM 3/26/98 -0700, Ed Reed wrote: >I don't concur, and don't believe the discussion on the work group supports, >the ordering of work items proposed in the charter...specifically that after a requirements document is published, that work will proceed with one-way synch, then two way synch, and then three way synch. > >There were 7 responses to the request for discussion on charter. > >O'Brien - "I'd say we are clearly interested in number 4 (Multi-Master)" >Huber - "I think the highest priority should go to 4." >Lloyd - [to Huber] "Agree" >Merrells - 1-way, 2-way, multi-master - "I think that we should tackle these three, in this order." >Stokes - "On items 1-4, the target should be 4 - multi-master." >Strassner - "I think that the order should be as is...though i would like to go on record that in terms of need, 4 is, imho, highest." >Reed - "I agree work should proceed on 1, 2, and 4." > >I'm amending mine to be "work on 4, with 1 and 2 falling out of that", which is consistent with that I've been saying. > >That said, there are 5 votes for 4, with 1 noting the need for 4 is highest. >There was 1 vote to work on 1, 2, and then 4. > >The notion that working first on one way synchronization, and then two-way synchronization, and then multi master replication will "let us learn as we go" is wishfull, but mis-leading. There's nothing new to be learned in the master-slave synchronization world - it's old hat, with NIS, DNS, DISP and other widely deployed technologies already doing that - and there is very little to be gained by coming up with yet-another master-slave protocol that doesn't explicitly include the bits necessary to _also_ support multi-master replication. > >I oppose the charter as written, and would replace the second paragraph and milestones as follows... >=============================================== >The approach is to first publish the requirements for, and then an architecture for LDAP directory synchronization. The ITU X.500 DISP will serve as a basis of comparison for the analysis and design. We will publish a directory synchronization architecture that will identify the necessary data elements, security implications, and service responsibilities appropriate to each of several replication scenarios, including one-way synchronization of information from a master to shadow (slave, read-only) replicas, and multi-master synchronization of information among two or more update-able replicas. Finally, a protocol specification for multi-master synchronization, along with one-way and two-way synchronization limited subset profiles, will be published. > > >Milestones: > >Jun 98 Working Group Last Call on Dir Sync Requirements I-D >Aug 98 Publish Dir Sync Requirements Document as Informational RFC >Aug 98 Publish Directory Synchronization Architecture as I-D (for discussion at Aug IETF) >Dec 98 Publish Dir Sync Architecture to Proposed Standard RFC >Feb 99 Publish Multi-Master Dir Sync Spec as I-D >Feb 99 Publish One-Way Dir Sync Usage Profile as I-D >Sep 99 Publish Multi-Master Dir Sync Spec as Proposed Standard >Sep 99 Publish One-Way Dir Sync Usage Profile as Proposed Standard >===================================================== > >Best regards, and see you in LA! >Ed > >------------------- >Ed Reed, Technologist >Group Technology Office >Novell, Inc. >+1 801 861 3320 > >>>> Chris Weider 03/25/1998 18:51:38 >>> >Hi gang: > Here is my proposed charter for LDUP. We'll be discussing it on Wednesday. >Chris > >LDAP Directory Synchronization (LDUP) > >Chair: John Strassner, Cisco Systems (johns@cisco.com) >Document Editor: Ellen Stokes, IBM (stokes@austin.ibm.com) > >Mailing List: ietf-ldup@imc.org >To Subscribe: ietf-ldup-request@imc.org >Archive: http://www.imc.org/ietf-ldup/ > >As LDAP becomes more widely deployed, synchronization of data between >directory servers running different implementations of LDAP becomes an >important part of providing a distributed and reliable directory service. >However, to this point, LDAP servers have standardized only on the >client-server access protocol. Therefore, this group will tackle >standardization of synchronization. > >The approach is to first develop a set of requirements for LDAP directory >synchronization, and write an applicability statement that defines for which >applications the synchronization protocols will suffice. Once this is done, >the working group will address three work items, in this order: one-way >directory synchronization, allowing an LDAP directory to act as a source to >other services; two-way synchronization, to allow to servers to converge >their data; and then multi-master synchronization, to allow widely >distributed update and management. > >Milestones: > >Jun 98 Publish Applicability Statement as Internet-Draft >Aug 98 Publish Directory Synchronization Requirements document as >Informational RFC >Aug 98 Publish Applicability Statement as Informational RFC >Oct 98 Publish specification for One-Way Directory Sync as Internet-Draft >Dec 98 Publish spec for Two-way Directory Sync as Internet-Draft >Feb 99 Publish One-Way Dir Sync as Proposed Standard >Apr 99 Publish Two-way Dir Sync as Proposed Standard >Aug 99 Publish Multi-Master Dir Sync as Internet Draft >Dec 99 Publish Multi-Master Dir Sync as Proposed Standard > > > > From owner-ietf-ldup Fri Mar 27 14:50:09 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id OAA23925 for ietf-ldup-bks; Fri, 27 Mar 1998 14:50:09 -0800 (PST) Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.7.3) with SMTP id OAA23921 for ; Fri, 27 Mar 1998 14:50:08 -0800 (PST) Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Fri, 27 Mar 1998 15:49:51 -0700 Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Fri, 27 Mar 1998 15:49:09 -0700 From: "Ed Reed" To: johns@cisco.com, jstrassn@cisco.com, ietf-ldup@imc.org, cweider@microsoft.com Cc: stokes@austin.ibm.com, Harald.Alvestrand@maxware.no Subject: Re: Proposed charter for LDUP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: owner-ietf-ldup@imc.org Precedence: bulk Granted there may have been a staw poll at the meeting in Washington, but = I seem to recall that authoritative polls are supposed to be taken from = the mail distribution list, so that non-attendees can be heard. No? Ed ------------------- Ed Reed, Technologist Group Technology Office Novell, Inc. +1 801 861 3320 >>> "John C. Strassner" 03/27/1998 09:37:19 >>> Ed, thanks for the comments. The problem is that only 7 people responded to = the email-call for charter acceptance. At the last LDUP meeting, the majority of people indicated that they were uncomfortable with leaping directly = into multi-master. I would suggest that this be our first order of business on Wednesday - one last vote to ensure that this ordering of work is indeed what the group wants to work on. regards, John At 01:02 PM 3/26/98 -0700, Ed Reed wrote: >I don't concur, and don't believe the discussion on the work group = supports,=20 >the ordering of work items proposed in the charter...specifically that after a requirements document is published, that work will proceed with one-way synch, then two way synch, and then three way synch. > >There were 7 responses to the request for discussion on charter. > >O'Brien - "I'd say we are clearly interested in number 4 (Multi-Master)" >Huber - "I think the highest priority should go to 4." >Lloyd - [to Huber] "Agree" >Merrells - 1-way, 2-way, multi-master - "I think that we should tackle these three, in this order." >Stokes - "On items 1-4, the target should be 4 - multi-master." >Strassner - "I think that the order should be as is...though i would like to go on record that in terms of need, 4 is, imho, highest." >Reed - "I agree work should proceed on 1, 2, and 4." > >I'm amending mine to be "work on 4, with 1 and 2 falling out of that", which is consistent with that I've been saying. > >That said, there are 5 votes for 4, with 1 noting the need for 4 is = highest. >There was 1 vote to work on 1, 2, and then 4. > >The notion that working first on one way synchronization, and then = two-way synchronization, and then multi master replication will "let us learn as = we go" is wishfull, but mis-leading. There's nothing new to be learned in = the master-slave synchronization world - it's old hat, with NIS, DNS, DISP and other widely deployed technologies already doing that - and there is very little to be gained by coming up with yet-another master-slave protocol that doesn't explicitly include the bits necessary to _also_ support multi-master replication. > >I oppose the charter as written, and would replace the second paragraph and milestones as follows... >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >The approach is to first publish the requirements for, and then an architecture for LDAP directory synchronization. The ITU X.500 DISP will serve as a basis of comparison for the analysis and design. We will publish a directory synchronization architecture that will identify the necessary data elements, security implications, and service responsibilities appropriate to each of several replication scenarios, including one-way synchronization of information from a master to shadow (slave, read-only) replicas, and multi-master synchronization of information among two or more update-able replicas. Finally, a protocol specification for multi-master synchronization, along with one-way and two-way synchronization limited subset profiles, will be published. > > >Milestones: > >Jun 98 Working Group Last Call on Dir Sync Requirements I-D >Aug 98 Publish Dir Sync Requirements Document as Informational RFC >Aug 98 Publish Directory Synchronization Architecture as I-D (for discussion at Aug IETF) >Dec 98 Publish Dir Sync Architecture to Proposed Standard RFC >Feb 99 Publish Multi-Master Dir Sync Spec as I-D >Feb 99 Publish One-Way Dir Sync Usage Profile as I-D >Sep 99 Publish Multi-Master Dir Sync Spec as Proposed Standard >Sep 99 Publish One-Way Dir Sync Usage Profile as Proposed Standard >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > >Best regards, and see you in LA! >Ed > >------------------- >Ed Reed, Technologist >Group Technology Office >Novell, Inc. >+1 801 861 3320 > >>>> Chris Weider 03/25/1998 18:51:38 >>> >Hi gang: > Here is my proposed charter for LDUP. We'll be discussing it on = Wednesday. >Chris > >LDAP Directory Synchronization (LDUP) > >Chair: John Strassner, Cisco Systems (johns@cisco.com) >Document Editor: Ellen Stokes, IBM (stokes@austin.ibm.com) > >Mailing List: ietf-ldup@imc.org=20 >To Subscribe: ietf-ldup-request@imc.org=20 >Archive: http://www.imc.org/ietf-ldup/=20 > >As LDAP becomes more widely deployed, synchronization of data between >directory servers running different implementations of LDAP becomes an >important part of providing a distributed and reliable directory service. >However, to this point, LDAP servers have standardized only on the >client-server access protocol. Therefore, this group will tackle >standardization of synchronization. > >The approach is to first develop a set of requirements for LDAP directory >synchronization, and write an applicability statement that defines for = which >applications the synchronization protocols will suffice. Once this is = done, >the working group will address three work items, in this order: one-way >directory synchronization, allowing an LDAP directory to act as a source = to >other services; two-way synchronization, to allow to servers to converge >their data; and then multi-master synchronization, to allow widely >distributed update and management.=20 > >Milestones: > >Jun 98 Publish Applicability Statement as Internet-Draft >Aug 98 Publish Directory Synchronization Requirements document as >Informational RFC >Aug 98 Publish Applicability Statement as Informational RFC >Oct 98 Publish specification for One-Way Directory Sync as Internet-Draft= >Dec 98 Publish spec for Two-way Directory Sync as Internet-Draft >Feb 99 Publish One-Way Dir Sync as Proposed Standard >Apr 99 Publish Two-way Dir Sync as Proposed Standard >Aug 99 Publish Multi-Master Dir Sync as Internet Draft >Dec 99 Publish Multi-Master Dir Sync as Proposed Standard > > > > From owner-ietf-ldup Fri Mar 27 16:22:18 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id QAA24583 for ietf-ldup-bks; Fri, 27 Mar 1998 16:22:18 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.23]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id QAA24579 for ; Fri, 27 Mar 1998 16:22:16 -0800 (PST) Received: by INET-03-IMC with Internet Mail Service (5.5.1960.3) id ; Fri, 27 Mar 1998 16:22:37 -0800 Message-ID: From: Chris Weider To: "'Ed Reed'" , johns@cisco.com, jstrassn@cisco.com, ietf-ldup@imc.org Cc: stokes@austin.ibm.com, Harald.Alvestrand@maxware.no Subject: RE: Proposed charter for LDUP Date: Fri, 27 Mar 1998 16:22:33 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ietf-ldup@imc.org Precedence: bulk Ed: There's no such thing as an 'authoritative poll'. The chair of the BOF or WG is supposed to get a sense of consensus from both the in person meeting and from the list. If s/he makes a decision based on that and everyone hates it, obviously there's not enough consensus :^). There were approximately 20 people at the WG who wanted multi-master first, and 40 who didn't. Even with the opinions on the list, there's still too much of a divide to declare consensus one way or another. So I'll have to work harder on it. Chris > -----Original Message----- > From: Ed Reed [SMTP:ED_REED@novell.com] > Sent: Friday, March 27, 1998 2:49 PM > To: johns@cisco.com; jstrassn@cisco.com; ietf-ldup@imc.org; Chris Weider > Cc: stokes@austin.ibm.COM; Harald.Alvestrand@maxware.no > Subject: Re: Proposed charter for LDUP > > Granted there may have been a staw poll at the meeting in Washington, but > I seem to recall that authoritative polls are supposed to be taken from > the mail distribution list, so that non-attendees can be heard. No? > > Ed > > ------------------- > Ed Reed, Technologist > Group Technology Office > Novell, Inc. > +1 801 861 3320 > > >>> "John C. Strassner" 03/27/1998 09:37:19 >>> > Ed, > > thanks for the comments. The problem is that only 7 people responded to > the > email-call for charter acceptance. At the last LDUP meeting, the majority > of people indicated that they were uncomfortable with leaping directly > into > multi-master. I would suggest that this be our first order of business on > Wednesday - one last vote to ensure that this ordering of work is indeed > what the group wants to work on. > > regards, > John > > At 01:02 PM 3/26/98 -0700, Ed Reed wrote: > >I don't concur, and don't believe the discussion on the work group > supports, > >the ordering of work items proposed in the charter...specifically that > after a requirements document is published, that work will proceed with > one-way synch, then two way synch, and then three way synch. > > > >There were 7 responses to the request for discussion on charter. > > > >O'Brien - "I'd say we are clearly interested in number 4 (Multi-Master)" > >Huber - "I think the highest priority should go to 4." > >Lloyd - [to Huber] "Agree" > >Merrells - 1-way, 2-way, multi-master - "I think that we should tackle > these three, in this order." > >Stokes - "On items 1-4, the target should be 4 - multi-master." > >Strassner - "I think that the order should be as is...though i would like > to go on record that in terms of need, 4 is, imho, highest." > >Reed - "I agree work should proceed on 1, 2, and 4." > > > >I'm amending mine to be "work on 4, with 1 and 2 falling out of that", > which is consistent with that I've been saying. > > > >That said, there are 5 votes for 4, with 1 noting the need for 4 is > highest. > >There was 1 vote to work on 1, 2, and then 4. > > > >The notion that working first on one way synchronization, and then > two-way > synchronization, and then multi master replication will "let us learn as > we > go" is wishfull, but mis-leading. There's nothing new to be learned in > the > master-slave synchronization world - it's old hat, with NIS, DNS, DISP and > other widely deployed technologies already doing that - and there is very > little to be gained by coming up with yet-another master-slave protocol > that doesn't explicitly include the bits necessary to _also_ support > multi-master replication. > > > >I oppose the charter as written, and would replace the second paragraph > and milestones as follows... > >=============================================== > >The approach is to first publish the requirements for, and then an > architecture for LDAP directory synchronization. The ITU X.500 DISP will > serve as a basis of comparison for the analysis and design. We will > publish a directory synchronization architecture that will identify the > necessary data elements, security implications, and service > responsibilities appropriate to each of several replication scenarios, > including one-way synchronization of information from a master to shadow > (slave, read-only) replicas, and multi-master synchronization of > information among two or more update-able replicas. Finally, a protocol > specification for multi-master synchronization, along with one-way and > two-way synchronization limited subset profiles, will be published. > > > > > >Milestones: > > > >Jun 98 Working Group Last Call on Dir Sync Requirements I-D > >Aug 98 Publish Dir Sync Requirements Document as Informational RFC > >Aug 98 Publish Directory Synchronization Architecture as I-D (for > discussion at Aug IETF) > >Dec 98 Publish Dir Sync Architecture to Proposed Standard RFC > >Feb 99 Publish Multi-Master Dir Sync Spec as I-D > >Feb 99 Publish One-Way Dir Sync Usage Profile as I-D > >Sep 99 Publish Multi-Master Dir Sync Spec as Proposed Standard > >Sep 99 Publish One-Way Dir Sync Usage Profile as Proposed Standard > >===================================================== > > > >Best regards, and see you in LA! > >Ed > > > >------------------- > >Ed Reed, Technologist > >Group Technology Office > >Novell, Inc. > >+1 801 861 3320 > > > >>>> Chris Weider 03/25/1998 18:51:38 >>> > >Hi gang: > > Here is my proposed charter for LDUP. We'll be discussing it on > Wednesday. > >Chris > > > >LDAP Directory Synchronization (LDUP) > > > >Chair: John Strassner, Cisco Systems (johns@cisco.com) > >Document Editor: Ellen Stokes, IBM (stokes@austin.ibm.com) > > > >Mailing List: ietf-ldup@imc.org > >To Subscribe: ietf-ldup-request@imc.org > >Archive: http://www.imc.org/ietf-ldup/ > > > >As LDAP becomes more widely deployed, synchronization of data between > >directory servers running different implementations of LDAP becomes an > >important part of providing a distributed and reliable directory service. > >However, to this point, LDAP servers have standardized only on the > >client-server access protocol. Therefore, this group will tackle > >standardization of synchronization. > > > >The approach is to first develop a set of requirements for LDAP directory > >synchronization, and write an applicability statement that defines for > which > >applications the synchronization protocols will suffice. Once this is > done, > >the working group will address three work items, in this order: one-way > >directory synchronization, allowing an LDAP directory to act as a source > to > >other services; two-way synchronization, to allow to servers to converge > >their data; and then multi-master synchronization, to allow widely > >distributed update and management. > > > >Milestones: > > > >Jun 98 Publish Applicability Statement as Internet-Draft > >Aug 98 Publish Directory Synchronization Requirements document as > >Informational RFC > >Aug 98 Publish Applicability Statement as Informational RFC > >Oct 98 Publish specification for One-Way Directory Sync as > Internet-Draft > >Dec 98 Publish spec for Two-way Directory Sync as Internet-Draft > >Feb 99 Publish One-Way Dir Sync as Proposed Standard > >Apr 99 Publish Two-way Dir Sync as Proposed Standard > >Aug 99 Publish Multi-Master Dir Sync as Internet Draft > >Dec 99 Publish Multi-Master Dir Sync as Proposed Standard > > > > > > > > From owner-ietf-ldup Fri Mar 27 17:48:52 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id RAA25236 for ietf-ldup-bks; Fri, 27 Mar 1998 17:48:52 -0800 (PST) Received: from novell.com (prv-mail25.Provo.Novell.COM [137.65.40.3]) by mail.proper.com (8.8.8/8.7.3) with SMTP id RAA25232 for ; Fri, 27 Mar 1998 17:48:51 -0800 (PST) Received: from INET-PRV1-Message_Server by novell.com with Novell_GroupWise; Fri, 27 Mar 1998 18:48:40 -0700 Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Fri, 27 Mar 1998 18:48:03 -0700 From: "Russel Weiser" To: ietf-ldup@imc.org, cweider@microsoft.com Cc: ED_REED@novell.com Subject: Re: RE: Proposed charter for LDUP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: owner-ietf-ldup@imc.org Precedence: bulk Chris:=20 I understood that the requirements would be hammered out from the point = of view of multimaster and that the initial synchronization drafts would = possibly start in as one way dir-sync=20 then followed by 2-way dirsync. But it is extremely important that the = requirements cover the most complex case of multi master before we go down = this trail. And I thought That was your=20 feelings and the general consensus. My concerns are a single interoperable = solution for LDAP not 3 different solutions that might interoperate.=20 When it came to the charter I guess I should of been more vocal about how = I personally felt about the Charter I agreed with ED so I didn't. My = mistake! So anyway you know my feelings now. cheers=20 see you next week. RFW =20 >>> Chris Weider 03/27 5:22 PM >>> Ed: There's no such thing as an 'authoritative poll'. The chair of the BOF = or WG is supposed to get a sense of consensus from both the in person meeting and from the list. If s/he makes a decision based on that and everyone = hates it, obviously there's not enough consensus :^). There were approximately = 20 people at the WG who wanted multi-master first, and 40 who didn't. Even = with the opinions on the list, there's still too much of a divide to declare consensus one way or another. So I'll have to work harder on it. Chris=20 > -----Original Message----- > From: Ed Reed [SMTP:ED_REED@novell.com]=20 > Sent: Friday, March 27, 1998 2:49 PM > To: johns@cisco.com; jstrassn@cisco.com; ietf-ldup@imc.org; Chris = Weider > Cc: stokes@austin.ibm.COM; Harald.Alvestrand@maxware.no=20 > Subject: Re: Proposed charter for LDUP >=20 > Granted there may have been a staw poll at the meeting in Washington, = but > I seem to recall that authoritative polls are supposed to be taken from > the mail distribution list, so that non-attendees can be heard. No? >=20 > Ed >=20 > ------------------- > Ed Reed, Technologist > Group Technology Office > Novell, Inc. > +1 801 861 3320 >=20 > >>> "John C. Strassner" 03/27/1998 09:37:19 >>> > Ed, >=20 > thanks for the comments. The problem is that only 7 people responded to > the > email-call for charter acceptance. At the last LDUP meeting, the = majority > of people indicated that they were uncomfortable with leaping directly > into > multi-master. I would suggest that this be our first order of business = on > Wednesday - one last vote to ensure that this ordering of work is indeed > what the group wants to work on. >=20 > regards, > John >=20 > At 01:02 PM 3/26/98 -0700, Ed Reed wrote: > >I don't concur, and don't believe the discussion on the work group > supports,=20 > >the ordering of work items proposed in the charter...specifically that > after a requirements document is published, that work will proceed with > one-way synch, then two way synch, and then three way synch. > > > >There were 7 responses to the request for discussion on charter. > > > >O'Brien - "I'd say we are clearly interested in number 4 (Multi-Master)"= > >Huber - "I think the highest priority should go to 4." > >Lloyd - [to Huber] "Agree" > >Merrells - 1-way, 2-way, multi-master - "I think that we should tackle > these three, in this order." > >Stokes - "On items 1-4, the target should be 4 - multi-master." > >Strassner - "I think that the order should be as is...though i would = like > to go on record that in terms of need, 4 is, imho, highest." > >Reed - "I agree work should proceed on 1, 2, and 4." > > > >I'm amending mine to be "work on 4, with 1 and 2 falling out of that", > which is consistent with that I've been saying. > > > >That said, there are 5 votes for 4, with 1 noting the need for 4 is > highest. > >There was 1 vote to work on 1, 2, and then 4. > > > >The notion that working first on one way synchronization, and then > two-way > synchronization, and then multi master replication will "let us learn as > we > go" is wishfull, but mis-leading. There's nothing new to be learned in > the > master-slave synchronization world - it's old hat, with NIS, DNS, DISP = and > other widely deployed technologies already doing that - and there is = very > little to be gained by coming up with yet-another master-slave protocol > that doesn't explicitly include the bits necessary to _also_ support > multi-master replication. > > > >I oppose the charter as written, and would replace the second paragraph > and milestones as follows... > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >The approach is to first publish the requirements for, and then an > architecture for LDAP directory synchronization. The ITU X.500 DISP will > serve as a basis of comparison for the analysis and design. We will > publish a directory synchronization architecture that will identify the > necessary data elements, security implications, and service > responsibilities appropriate to each of several replication scenarios, > including one-way synchronization of information from a master to shadow > (slave, read-only) replicas, and multi-master synchronization of > information among two or more update-able replicas. Finally, a protocol > specification for multi-master synchronization, along with one-way and > two-way synchronization limited subset profiles, will be published. > > > > > >Milestones: > > > >Jun 98 Working Group Last Call on Dir Sync Requirements I-D > >Aug 98 Publish Dir Sync Requirements Document as Informational RFC > >Aug 98 Publish Directory Synchronization Architecture as I-D (for > discussion at Aug IETF) > >Dec 98 Publish Dir Sync Architecture to Proposed Standard RFC > >Feb 99 Publish Multi-Master Dir Sync Spec as I-D > >Feb 99 Publish One-Way Dir Sync Usage Profile as I-D > >Sep 99 Publish Multi-Master Dir Sync Spec as Proposed Standard > >Sep 99 Publish One-Way Dir Sync Usage Profile as Proposed Standard > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > >Best regards, and see you in LA! > >Ed > > > >------------------- > >Ed Reed, Technologist > >Group Technology Office > >Novell, Inc. > >+1 801 861 3320 > > > >>>> Chris Weider 03/25/1998 18:51:38 >>> > >Hi gang: > > Here is my proposed charter for LDUP. We'll be discussing it on > Wednesday. > >Chris > > > >LDAP Directory Synchronization (LDUP) > > > >Chair: John Strassner, Cisco Systems (johns@cisco.com) > >Document Editor: Ellen Stokes, IBM (stokes@austin.ibm.com) > > > >Mailing List: ietf-ldup@imc.org=20 > >To Subscribe: ietf-ldup-request@imc.org=20 > >Archive: http://www.imc.org/ietf-ldup/=20 > > > >As LDAP becomes more widely deployed, synchronization of data between > >directory servers running different implementations of LDAP becomes an > >important part of providing a distributed and reliable directory = service. > >However, to this point, LDAP servers have standardized only on the > >client-server access protocol. Therefore, this group will tackle > >standardization of synchronization. > > > >The approach is to first develop a set of requirements for LDAP = directory > >synchronization, and write an applicability statement that defines for > which > >applications the synchronization protocols will suffice. Once this is > done, > >the working group will address three work items, in this order: one-way > >directory synchronization, allowing an LDAP directory to act as a = source > to > >other services; two-way synchronization, to allow to servers to = converge > >their data; and then multi-master synchronization, to allow widely > >distributed update and management.=20 > > > >Milestones: > > > >Jun 98 Publish Applicability Statement as Internet-Draft > >Aug 98 Publish Directory Synchronization Requirements document as > >Informational RFC > >Aug 98 Publish Applicability Statement as Informational RFC > >Oct 98 Publish specification for One-Way Directory Sync as > Internet-Draft > >Dec 98 Publish spec for Two-way Directory Sync as Internet-Draft > >Feb 99 Publish One-Way Dir Sync as Proposed Standard > >Apr 99 Publish Two-way Dir Sync as Proposed Standard > >Aug 99 Publish Multi-Master Dir Sync as Internet Draft > >Dec 99 Publish Multi-Master Dir Sync as Proposed Standard > > > > > > > > From owner-ietf-ldup Fri Mar 27 17:54:34 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id RAA25251 for ietf-ldup-bks; Fri, 27 Mar 1998 17:54:34 -0800 (PST) Received: from mail2-b.microsoft.com (mail2-b.microsoft.com [131.107.3.124]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id RAA25247 for ; Fri, 27 Mar 1998 17:54:33 -0800 (PST) Received: by mail2-b.microsoft.com with Internet Mail Service (5.5.2166.0) id ; Fri, 27 Mar 1998 17:54:21 -0800 Message-ID: From: Chris Weider To: "'Russel Weiser'" , ietf-ldup@imc.org, Chris Weider Cc: ED_REED@novell.com Subject: RE: RE: Proposed charter for LDUP Date: Fri, 27 Mar 1998 17:54:20 -0800 X-Mailer: Internet Mail Service (5.5.2166.0) Sender: owner-ietf-ldup@imc.org Precedence: bulk Russ: I didn't think I was upsetting the consensus that MM was what we had to aim for in the end. But we can keep the MM requirements in mind while working on the other items; in fact, as you point out, we have to! I'm sorry if that's not clear from the proposed charter. We'll continue to discuss this in L.A. Chris > -----Original Message----- > From: Russel Weiser [SMTP:RWEISER@novell.com] > Sent: Friday, March 27, 1998 5:48 PM > To: ietf-ldup@imc.org; cweider@microsoft.com > Cc: ED_REED@novell.com > Subject: Re: RE: Proposed charter for LDUP > > Chris: > I understood that the requirements would be hammered out from the point > of view of multimaster and that the initial synchronization drafts would > possibly start in as one way dir-sync > then followed by 2-way dirsync. But it is extremely important that the > requirements cover the most complex case of multi master before we go down > this trail. And I thought That was your > feelings and the general consensus. My concerns are a single interoperable > solution for LDAP not 3 different solutions that might interoperate. > > When it came to the charter I guess I should of been more vocal about how > I personally felt about the Charter I agreed with ED so I didn't. My > mistake! So anyway you know my feelings now. > > cheers > see you next week. > RFW > >>> Chris Weider 03/27 5:22 PM >>> > Ed: > There's no such thing as an 'authoritative poll'. The chair of the BOF > or > WG is supposed to get a sense of consensus from both the in person meeting > and from the list. If s/he makes a decision based on that and everyone > hates > it, obviously there's not enough consensus :^). There were approximately > 20 > people at the WG who wanted multi-master first, and 40 who didn't. Even > with > the opinions on the list, there's still too much of a divide to declare > consensus one way or another. So I'll have to work harder on it. > Chris > > > -----Original Message----- > > From: Ed Reed [SMTP:ED_REED@novell.com] > > Sent: Friday, March 27, 1998 2:49 PM > > To: johns@cisco.com; jstrassn@cisco.com; ietf-ldup@imc.org; Chris Weider > > Cc: stokes@austin.ibm.COM; Harald.Alvestrand@maxware.no > > Subject: Re: Proposed charter for LDUP > > > > Granted there may have been a staw poll at the meeting in Washington, > but > > I seem to recall that authoritative polls are supposed to be taken from > > the mail distribution list, so that non-attendees can be heard. No? > > > > Ed > > > > ------------------- > > Ed Reed, Technologist > > Group Technology Office > > Novell, Inc. > > +1 801 861 3320 > > > > >>> "John C. Strassner" 03/27/1998 09:37:19 >>> > > Ed, > > > > thanks for the comments. The problem is that only 7 people responded to > > the > > email-call for charter acceptance. At the last LDUP meeting, the > majority > > of people indicated that they were uncomfortable with leaping directly > > into > > multi-master. I would suggest that this be our first order of business > on > > Wednesday - one last vote to ensure that this ordering of work is indeed > > what the group wants to work on. > > > > regards, > > John > > > > At 01:02 PM 3/26/98 -0700, Ed Reed wrote: > > >I don't concur, and don't believe the discussion on the work group > > supports, > > >the ordering of work items proposed in the charter...specifically that > > after a requirements document is published, that work will proceed with > > one-way synch, then two way synch, and then three way synch. > > > > > >There were 7 responses to the request for discussion on charter. > > > > > >O'Brien - "I'd say we are clearly interested in number 4 > (Multi-Master)" > > >Huber - "I think the highest priority should go to 4." > > >Lloyd - [to Huber] "Agree" > > >Merrells - 1-way, 2-way, multi-master - "I think that we should tackle > > these three, in this order." > > >Stokes - "On items 1-4, the target should be 4 - multi-master." > > >Strassner - "I think that the order should be as is...though i would > like > > to go on record that in terms of need, 4 is, imho, highest." > > >Reed - "I agree work should proceed on 1, 2, and 4." > > > > > >I'm amending mine to be "work on 4, with 1 and 2 falling out of that", > > which is consistent with that I've been saying. > > > > > >That said, there are 5 votes for 4, with 1 noting the need for 4 is > > highest. > > >There was 1 vote to work on 1, 2, and then 4. > > > > > >The notion that working first on one way synchronization, and then > > two-way > > synchronization, and then multi master replication will "let us learn as > > we > > go" is wishfull, but mis-leading. There's nothing new to be learned in > > the > > master-slave synchronization world - it's old hat, with NIS, DNS, DISP > and > > other widely deployed technologies already doing that - and there is > very > > little to be gained by coming up with yet-another master-slave protocol > > that doesn't explicitly include the bits necessary to _also_ support > > multi-master replication. > > > > > >I oppose the charter as written, and would replace the second paragraph > > and milestones as follows... > > >=============================================== > > >The approach is to first publish the requirements for, and then an > > architecture for LDAP directory synchronization. The ITU X.500 DISP will > > serve as a basis of comparison for the analysis and design. We will > > publish a directory synchronization architecture that will identify the > > necessary data elements, security implications, and service > > responsibilities appropriate to each of several replication scenarios, > > including one-way synchronization of information from a master to shadow > > (slave, read-only) replicas, and multi-master synchronization of > > information among two or more update-able replicas. Finally, a protocol > > specification for multi-master synchronization, along with one-way and > > two-way synchronization limited subset profiles, will be published. > > > > > > > > >Milestones: > > > > > >Jun 98 Working Group Last Call on Dir Sync Requirements I-D > > >Aug 98 Publish Dir Sync Requirements Document as Informational RFC > > >Aug 98 Publish Directory Synchronization Architecture as I-D (for > > discussion at Aug IETF) > > >Dec 98 Publish Dir Sync Architecture to Proposed Standard RFC > > >Feb 99 Publish Multi-Master Dir Sync Spec as I-D > > >Feb 99 Publish One-Way Dir Sync Usage Profile as I-D > > >Sep 99 Publish Multi-Master Dir Sync Spec as Proposed Standard > > >Sep 99 Publish One-Way Dir Sync Usage Profile as Proposed Standard > > >===================================================== > > > > > >Best regards, and see you in LA! > > >Ed > > > > > >------------------- > > >Ed Reed, Technologist > > >Group Technology Office > > >Novell, Inc. > > >+1 801 861 3320 > > > > > >>>> Chris Weider 03/25/1998 18:51:38 >>> > > >Hi gang: > > > Here is my proposed charter for LDUP. We'll be discussing it on > > Wednesday. > > >Chris > > > > > >LDAP Directory Synchronization (LDUP) > > > > > >Chair: John Strassner, Cisco Systems (johns@cisco.com) > > >Document Editor: Ellen Stokes, IBM (stokes@austin.ibm.com) > > > > > >Mailing List: ietf-ldup@imc.org > > >To Subscribe: ietf-ldup-request@imc.org > > >Archive: http://www.imc.org/ietf-ldup/ > > > > > >As LDAP becomes more widely deployed, synchronization of data between > > >directory servers running different implementations of LDAP becomes an > > >important part of providing a distributed and reliable directory > service. > > >However, to this point, LDAP servers have standardized only on the > > >client-server access protocol. Therefore, this group will tackle > > >standardization of synchronization. > > > > > >The approach is to first develop a set of requirements for LDAP > directory > > >synchronization, and write an applicability statement that defines for > > which > > >applications the synchronization protocols will suffice. Once this is > > done, > > >the working group will address three work items, in this order: one-way > > >directory synchronization, allowing an LDAP directory to act as a > source > > to > > >other services; two-way synchronization, to allow to servers to > converge > > >their data; and then multi-master synchronization, to allow widely > > >distributed update and management. > > > > > >Milestones: > > > > > >Jun 98 Publish Applicability Statement as Internet-Draft > > >Aug 98 Publish Directory Synchronization Requirements document as > > >Informational RFC > > >Aug 98 Publish Applicability Statement as Informational RFC > > >Oct 98 Publish specification for One-Way Directory Sync as > > Internet-Draft > > >Dec 98 Publish spec for Two-way Directory Sync as Internet-Draft > > >Feb 99 Publish One-Way Dir Sync as Proposed Standard > > >Apr 99 Publish Two-way Dir Sync as Proposed Standard > > >Aug 99 Publish Multi-Master Dir Sync as Internet Draft > > >Dec 99 Publish Multi-Master Dir Sync as Proposed Standard > > > > > > > > > > > > From owner-ietf-ldup Sun Apr 5 17:45:14 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id RAA09959 for ietf-ldup-bks; Sun, 5 Apr 1998 17:45:14 -0700 (PDT) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id RAA09952 for ; Sun, 5 Apr 1998 17:44:59 -0700 (PDT) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id ; Mon, 6 Apr 1998 10:37:22 +1000 Message-ID: From: Alan Lloyd To: "'Chris Weider'" , "'Ed Reed'" , johns@cisco.com, jstrassn@cisco.com, ietf-ldup@imc.org Cc: stokes@austin.ibm.com, Harald.Alvestrand@maxware.no Subject: RE: Proposed charter for LDUP Date: Mon, 6 Apr 1998 10:37:19 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldup@imc.org Precedence: bulk If its of any help - I have done some work on multi- master from an operational perspective (ADDMD issues) and how that will work with X.500. I will post that to the lists later this week for comment. regards alan > -----Original Message----- > From: Chris Weider [SMTP:cweider@microsoft.com] > Sent: Saturday, March 28, 1998 11:23 AM > To: 'Ed Reed'; johns@cisco.com; jstrassn@cisco.com; > ietf-ldup@imc.org > Cc: stokes@austin.ibm.com; Harald.Alvestrand@maxware.no > Subject: RE: Proposed charter for LDUP > > Ed: > There's no such thing as an 'authoritative poll'. The chair of the > BOF or > WG is supposed to get a sense of consensus from both the in person > meeting > and from the list. If s/he makes a decision based on that and everyone > hates > it, obviously there's not enough consensus :^). There were > approximately 20 > people at the WG who wanted multi-master first, and 40 who didn't. > Even with > the opinions on the list, there's still too much of a divide to > declare > consensus one way or another. So I'll have to work harder on it. > Chris > > > -----Original Message----- > > From: Ed Reed [SMTP:ED_REED@novell.com] > > Sent: Friday, March 27, 1998 2:49 PM > > To: johns@cisco.com; jstrassn@cisco.com; ietf-ldup@imc.org; Chris > Weider > > Cc: stokes@austin.ibm.COM; Harald.Alvestrand@maxware.no > > Subject: Re: Proposed charter for LDUP > > > > Granted there may have been a staw poll at the meeting in > Washington, but > > I seem to recall that authoritative polls are supposed to be taken > from > > the mail distribution list, so that non-attendees can be heard. No? > > > > Ed > > > > ------------------- > > Ed Reed, Technologist > > Group Technology Office > > Novell, Inc. > > +1 801 861 3320 > > > > >>> "John C. Strassner" 03/27/1998 09:37:19 >>> > > Ed, > > > > thanks for the comments. The problem is that only 7 people responded > to > > the > > email-call for charter acceptance. At the last LDUP meeting, the > majority > > of people indicated that they were uncomfortable with leaping > directly > > into > > multi-master. I would suggest that this be our first order of > business on > > Wednesday - one last vote to ensure that this ordering of work is > indeed > > what the group wants to work on. > > > > regards, > > John > > > > At 01:02 PM 3/26/98 -0700, Ed Reed wrote: > > >I don't concur, and don't believe the discussion on the work group > > supports, > > >the ordering of work items proposed in the charter...specifically > that > > after a requirements document is published, that work will proceed > with > > one-way synch, then two way synch, and then three way synch. > > > > > >There were 7 responses to the request for discussion on charter. > > > > > >O'Brien - "I'd say we are clearly interested in number 4 > (Multi-Master)" > > >Huber - "I think the highest priority should go to 4." > > >Lloyd - [to Huber] "Agree" > > >Merrells - 1-way, 2-way, multi-master - "I think that we should > tackle > > these three, in this order." > > >Stokes - "On items 1-4, the target should be 4 - multi-master." > > >Strassner - "I think that the order should be as is...though i > would like > > to go on record that in terms of need, 4 is, imho, highest." > > >Reed - "I agree work should proceed on 1, 2, and 4." > > > > > >I'm amending mine to be "work on 4, with 1 and 2 falling out of > that", > > which is consistent with that I've been saying. > > > > > >That said, there are 5 votes for 4, with 1 noting the need for 4 is > > highest. > > >There was 1 vote to work on 1, 2, and then 4. > > > > > >The notion that working first on one way synchronization, and then > > two-way > > synchronization, and then multi master replication will "let us > learn as > > we > > go" is wishfull, but mis-leading. There's nothing new to be learned > in > > the > > master-slave synchronization world - it's old hat, with NIS, DNS, > DISP and > > other widely deployed technologies already doing that - and there is > very > > little to be gained by coming up with yet-another master-slave > protocol > > that doesn't explicitly include the bits necessary to _also_ support > > multi-master replication. > > > > > >I oppose the charter as written, and would replace the second > paragraph > > and milestones as follows... > > >=============================================== > > >The approach is to first publish the requirements for, and then an > > architecture for LDAP directory synchronization. The ITU X.500 DISP > will > > serve as a basis of comparison for the analysis and design. We will > > publish a directory synchronization architecture that will identify > the > > necessary data elements, security implications, and service > > responsibilities appropriate to each of several replication > scenarios, > > including one-way synchronization of information from a master to > shadow > > (slave, read-only) replicas, and multi-master synchronization of > > information among two or more update-able replicas. Finally, a > protocol > > specification for multi-master synchronization, along with one-way > and > > two-way synchronization limited subset profiles, will be published. > > > > > > > > >Milestones: > > > > > >Jun 98 Working Group Last Call on Dir Sync Requirements I-D > > >Aug 98 Publish Dir Sync Requirements Document as Informational RFC > > >Aug 98 Publish Directory Synchronization Architecture as I-D (for > > discussion at Aug IETF) > > >Dec 98 Publish Dir Sync Architecture to Proposed Standard RFC > > >Feb 99 Publish Multi-Master Dir Sync Spec as I-D > > >Feb 99 Publish One-Way Dir Sync Usage Profile as I-D > > >Sep 99 Publish Multi-Master Dir Sync Spec as Proposed Standard > > >Sep 99 Publish One-Way Dir Sync Usage Profile as Proposed Standard > > >===================================================== > > > > > >Best regards, and see you in LA! > > >Ed > > > > > >------------------- > > >Ed Reed, Technologist > > >Group Technology Office > > >Novell, Inc. > > >+1 801 861 3320 > > > > > >>>> Chris Weider 03/25/1998 18:51:38 >>> > > >Hi gang: > > > Here is my proposed charter for LDUP. We'll be discussing it on > > Wednesday. > > >Chris > > > > > >LDAP Directory Synchronization (LDUP) > > > > > >Chair: John Strassner, Cisco Systems (johns@cisco.com) > > >Document Editor: Ellen Stokes, IBM (stokes@austin.ibm.com) > > > > > >Mailing List: ietf-ldup@imc.org > > >To Subscribe: ietf-ldup-request@imc.org > > >Archive: http://www.imc.org/ietf-ldup/ > > > > > >As LDAP becomes more widely deployed, synchronization of data > between > > >directory servers running different implementations of LDAP becomes > an > > >important part of providing a distributed and reliable directory > service. > > >However, to this point, LDAP servers have standardized only on the > > >client-server access protocol. Therefore, this group will tackle > > >standardization of synchronization. > > > > > >The approach is to first develop a set of requirements for LDAP > directory > > >synchronization, and write an applicability statement that defines > for > > which > > >applications the synchronization protocols will suffice. Once this > is > > done, > > >the working group will address three work items, in this order: > one-way > > >directory synchronization, allowing an LDAP directory to act as a > source > > to > > >other services; two-way synchronization, to allow to servers to > converge > > >their data; and then multi-master synchronization, to allow widely > > >distributed update and management. > > > > > >Milestones: > > > > > >Jun 98 Publish Applicability Statement as Internet-Draft > > >Aug 98 Publish Directory Synchronization Requirements document as > > >Informational RFC > > >Aug 98 Publish Applicability Statement as Informational RFC > > >Oct 98 Publish specification for One-Way Directory Sync as > > Internet-Draft > > >Dec 98 Publish spec for Two-way Directory Sync as Internet-Draft > > >Feb 99 Publish One-Way Dir Sync as Proposed Standard > > >Apr 99 Publish Two-way Dir Sync as Proposed Standard > > >Aug 99 Publish Multi-Master Dir Sync as Internet Draft > > >Dec 99 Publish Multi-Master Dir Sync as Proposed Standard > > > > > > > > > > > > From owner-ietf-ldup Fri Apr 10 12:04:51 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id MAA13995 for ietf-ldup-bks; Fri, 10 Apr 1998 12:04:51 -0700 (PDT) Received: from coyotes.cisco.com (coyotes.cisco.com [171.71.80.22]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id MAA13991 for ; Fri, 10 Apr 1998 12:04:50 -0700 (PDT) Received: from jstrassn-pc (ricochet-8.cisco.com [171.68.11.200]) by coyotes.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with SMTP id MAA25245; Fri, 10 Apr 1998 12:04:42 -0700 (PDT) Message-Id: <3.0.2.32.19980410120429.00a1cd70@coyotes.cisco.com> X-Sender: jstrassn@coyotes.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) X-Priority: 2 (High) Date: Fri, 10 Apr 1998 12:04:29 -0700 To: ietf-ldup@imc.org From: "John C. Strassner" Subject: LDUP Meeting Minutes Cc: capple@master.control.att.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@imc.org Precedence: bulk LDUP-ers, attached are the preliminary minutes of the LDUP meeting in LA. If you have any comments, please send them to Chris or myself by April 17. regards, John We first reviewed the proposed charter and arguments that led to the charter from the December meeting. The point of concern was the prescribed ordering of problems to solve in the charter - one-way dir sync, then two-way dir-sync, then multi-master replication. We then reviewed recent discussion on the list concerning the charter. Central to this were two themes: 1) the need for an architecture document that addresses multi-master replication, with other forms of replication and synchronization emanating from that, and 2) the concept of a specification "bake-off", which would seek to bring together differing implementations Theme #1 means that we must define a replication architecture that addresses multi-master requirements from the beginning. The concern is that if was not not done first, there might be fundamental deficiencies in the resulting architecture that would have to be revisited. Furthermore, it was thought that other flavors of replication (as mentioned in the proposed charter) could be treated as functional subsets of such a multi-master replication architecture. Theme #2 addresses the fact that individual vendors have already started addressing the need to do multi-master replication. However, this has resulted in differing implementation approaches, and there is concern that with no agreed-upon standard in place, this will fragment the LDAP community and lead to solutions that are not interoperable. To prevent this, the idea of a "specification bake-off" was proposed. The intent is to get rapid convergence on a common implementation. By forcing candidate implementations and ideas from those implementations to be written down and reviewed in an open forum, it will "weed out" people that don't have time to come up with a full proposal, and help converge dissimilar architectures that are starting to be developed from differing implementations. This was proven to be true - about 25 people raised their hands when asked if they had an implementation to offer or were working on one; only 8 companies ended up agreeing to present a specification for the proposed bake-off. Concern was expressed that the architecture document must be structured in such a way as to enable the parts that are required only for multi-master to be "stripped off" so that "clean and lean" simpler implementations (e.g., 1-way dir sync) could be supported. After much discussion, the group converged on the following approach: 1) finish off a new draft of the requirements document asap (note that this document already assumes a multi-master system) 2) concurrently, set up an engineering group to enable interested people to work on a common architecture. 3) the architecture document would then result in a set of specifications that were aimed specifically at 1-way, 2-way, and multi-master implementations. An engineering team mailing list has been set up to allow interested architectural constituents to share information about their ideas for an architectural draft. An abstract of each proposal is due to be submitted to the engineering group by 17 Arpil. A face-to-face meeting of these constituents is scheduled for May 1, 1998. Constituents will discuss their proposal concepts at this meeting with a goal of reducing the total number of independent architectural proposals to one. The idea is for individual proposals to build off of each other and either result in a new proposal that uses elements from previous proposals or be subsumed by another proposal. If this goal is not achieved, we may end up with multiple proposals that will be discussed on the LDUP mailing list by a broader community. The proposers were exhorted by Harald as well as other members of the group to try to converge asap. There are currently 6 companies involved: Netscape, Microsoft, Innosoft, IBM, Novell, Oracle, Cisco, and Stanford. Several of these stated up front that they are not trying to submit a full-blown proposal by themselves; rather, they are looking to contribute resources and ideas as part of a larger effort. It appears that there are at least 4 proposals that will be written. The applicability statement will be folded into the requirements document. Each proposal will address how it satisfies the functionality stated in the requirements draft. Our schedule is as follows: - "Sneak preview" of the new draft of the requirements document will be submitted by 10 April. - New draft of the requirements doc will be submitted by Russ and Ellen by May 1. - All companies that are submitting architectural proposals MUST commit to review this document and post written feed back by 31 May. - The requirements document might not be ready for last-call, pending any new requirements that arise from the architectural proposal - Abstracts of each architectural proposal will be submitted to the engineering mailing list by 17 April - A face-to-face meeting of all architectural proposal editors is scheduled for 1 May. - Each finalized architectural proposal will be submitted to the LDUP group for general review by 31 July. Regards, John Strassner and Chris Apple From owner-ietf-ldup Tue Apr 14 11:08:29 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA06276 for ietf-ldup-bks; Tue, 14 Apr 1998 11:08:29 -0700 (PDT) Received: from novell.com (prv-mail25.Provo.Novell.COM [137.65.40.3]) by mail.proper.com (8.8.8/8.7.3) with SMTP id LAA06272 for ; Tue, 14 Apr 1998 11:08:24 -0700 (PDT) Received: from INET-PRV1-Message_Server by novell.com with Novell_GroupWise; Tue, 14 Apr 1998 12:08:33 -0600 Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Tue, 14 Apr 1998 12:07:52 -0600 From: "Russel Weiser" To: ldup-repl@external.cicso.com, internet-drafts@ietf.org, ietf-ldup@imc.org Subject: LDAP V3 REPLICATION REQUIREMENTS DRAFT Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_F9ADF231.81E0A0A6" Sender: owner-ietf-ldup@imc.org Precedence: bulk This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_F9ADF231.81E0A0A6 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline To the drafts editor: please publish the attached draft. To the LDUP group: please find attached draft of the ldap rplication requirements document Please note that the applicability = statement is not included and currently I am working on it. Sorry for the delay I will respond in new questions and previous = questions in an attempt to prefresh this document. again jby the end of = the day. =20 Thanks --=_F9ADF231.81E0A0A6 Content-Type: text/plain Content-Disposition: attachment; filename="draft-ietf-ldup-replica-req-00.txt" INTERNET-DRAFT Russel Weiser Informational Draft Novell, Inc. Expires 13 October 1998 Ellen Stokes IBM 13 April 1998 LDAP Replication Requirements ; Tue, 14 Apr 1998 12:20:25 -0700 (PDT) Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id MAA12107 for ; Tue, 14 Apr 1998 12:19:21 -0700 (PDT) Received: from netscape.com ([208.12.63.187]) by tintin.mcom.com (Netscape Messaging Server 3.52) with ESMTP id AAA13C0; Tue, 14 Apr 1998 12:19:21 -0700 Message-ID: <3533B692.BC3F58B0@netscape.com> Date: Tue, 14 Apr 1998 12:18:43 -0700 From: "John Merrells" Organization: Netscape Communications X-Mailer: Mozilla 4.04 [en]C-NSCP (WinNT; I) MIME-Version: 1.0 To: Russel Weiser CC: ldup-repl@external.cicso.com, ietf-ldup@imc.org, Ellen Stokes Subject: Re: LDAP V3 REPLICATION REQUIREMENTS DRAFT References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk The Terminology section defines the terms Replication and Synchronization as... Replication - The process of copying portions of naming context information and content, between multiple LDAP servers, such that certain, predefined portions of the information are available from many geographic locations. Synchronization - The process whereby LDAP servers participating in the replication, are brought into a state where copies of the information they make accessible are consistent with the other. These statements don't seem to draw out the distinction between these two concepts. From an email exchange with Ellen Stokes I believe that Synchronization extends Replication by including some mapping procedure. This mapping would be between disparate Schema, Access Control Models, and Namespaces. I agree that there is a big Directory Synchronisation problem to solve, but I believe we are trying to solve that problem by standardising a replication mechanism, not by defining generalised mapping mechanisms. I'd like us to either declare these two terms to be interchangeable, or rewrite them to clarify their differences. I'd also like us to revisit the problem we're trying to solve... ...Synchronisation via standardised Replication... OR ...Synchronisation... John -- John Merrells Netscape Communications Directory Server Software Engineer http://people.netscape.com/merrells From owner-ietf-ldup Tue Apr 14 12:30:37 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id MAA06980 for ietf-ldup-bks; Tue, 14 Apr 1998 12:30:37 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id MAA06976 for ; Tue, 14 Apr 1998 12:30:35 -0700 (PDT) Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id MAA04676 for ; Tue, 14 Apr 1998 12:30:37 -0700 (PDT) Received: from netscape.com ([208.12.63.187]) by tintin.mcom.com (Netscape Messaging Server 3.52) with ESMTP id AAA15C0; Tue, 14 Apr 1998 12:30:37 -0700 Message-ID: <3533B937.D705F710@netscape.com> Date: Tue, 14 Apr 1998 12:29:59 -0700 From: "John Merrells" Organization: Netscape Communications X-Mailer: Mozilla 4.04 [en]C-NSCP (WinNT; I) MIME-Version: 1.0 To: Russel Weiser CC: ldup-repl@external.cicso.com, ietf-ldup@imc.org Subject: Re: LDAP V3 REPLICATION REQUIREMENTS DRAFT References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk I would argue that none of the following requirements are necessary to meet our 'interoperability' objective. Additionally, the confirmance of an implementation to these statements would be subjective. 4. General Requirements Simple - Replication MUST be simple to configure and maintain. 4.5 Administration Utility Requirements Administration of replicated servers SHALL be defined in such a manner to include: 1. The capability to check the differences between two replicas of the same information. 2. The capability to view the replication topology from a single server in the topology. 3. The capability to view the current state and replication history of each replicated copy in the replication topology, from a single server in the topology. 4. The ability to view replication conflicts, and override the resolution derived by the replication policy. Yes, an implementation would need these features in order to be successful, but I don't feel these are interoperability issues. John -- John Merrells Netscape Communications Directory Server Software Engineer http://people.netscape.com/merrells From owner-ietf-ldup Tue Apr 14 13:10:30 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id NAA07225 for ietf-ldup-bks; Tue, 14 Apr 1998 13:10:30 -0700 (PDT) Received: from novell.com (prv-mail25.Provo.Novell.COM [137.65.40.3]) by mail.proper.com (8.8.8/8.7.3) with SMTP id NAA07221 for ; Tue, 14 Apr 1998 13:10:29 -0700 (PDT) Received: from INET-PRV1-Message_Server by novell.com with Novell_GroupWise; Tue, 14 Apr 1998 14:10:12 -0600 Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Tue, 14 Apr 1998 14:09:40 -0600 From: "Russel Weiser" To: merrells@netscape.com Cc: ldup-repl@external.cicso.com, ietf-ldup@imc.org Subject: Re: LDAP V3 REPLICATION REQUIREMENTS DRAFT Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: owner-ietf-ldup@imc.org Precedence: bulk John=20 I guess, that I'm not stating correctly is that the configuration and = maintance issues are an interoprability issue such that in an true = interoperable evnivonment such as Extranet scenario.=20 where two trading partners. Inorder yto exchange information corectly and = insure that it is in facts working correctly how does the administrator of = the replica say it me at novell look at the replica data and know from a = management point of view that all the information in the local replica is = correctly synchronized and when was it last performed. =20 My real point here is that the selective attribute defining the Replica in = and its schedule information=20 these may be in a "predetermined agreement" must be availiable at an = approperiate Management point and be replicated so I can use my fancy = admin tool and not need your fancy admin tool... Additionally I should be = able to use LDAP protocol to access this information in a mixed topology=20= IBM/Netscape and Novell using a single adimin tool that may be provided by = any of our companies.=20 I also know from deployment and Myrphy's Law that the unexpected will = happen during the syschronization process and we need to understand how = correct these problems. Now if we don't provide the hooks now it will = never fly in the long run. =20 Cheers RFW >>> "John Merrells" 04/14 1:29 PM >>> I would argue that none of the following requirements are necessary to meet our 'interoperability' objective. Additionally, the confirmance of an implementation to these statements would be subjective. 4. General Requirements Simple - Replication MUST be simple to configure and maintain. 4.5 Administration Utility Requirements Administration of replicated servers SHALL be defined in such a manner to include: 1. The capability to check the differences between two replicas of the same information. 2. The capability to view the replication topology from a single server in the topology. 3. The capability to view the current state and replication history of each replicated copy in the replication topology, from a single server in the topology. 4. The ability to view replication conflicts, and override the resolution derived by the replication policy. Yes, an implementation would need these features in order to be successful,= but I don't feel these are interoperability issues. John -- John Merrells Netscape Communications Directory Server Software Engineer http://people.netscape.com/merrells=20 From owner-ietf-ldup Tue Apr 14 13:40:14 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id NAA07579 for ietf-ldup-bks; Tue, 14 Apr 1998 13:40:14 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id NAA07571 for ; Tue, 14 Apr 1998 13:40:00 -0700 (PDT) Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id NAA17749 for ; Tue, 14 Apr 1998 13:39:05 -0700 (PDT) Received: from netscape.com ([208.12.63.187]) by tintin.mcom.com (Netscape Messaging Server 3.52) with ESMTP id AAA2057; Tue, 14 Apr 1998 13:38:46 -0700 Message-ID: <3533C92F.EF7F63F2@netscape.com> Date: Tue, 14 Apr 1998 13:38:07 -0700 From: "John Merrells" Organization: Netscape Communications X-Mailer: Mozilla 4.04 [en]C-NSCP (WinNT; I) MIME-Version: 1.0 To: Russel Weiser CC: ldup-repl@external.cicso.com, ietf-ldup@imc.org Subject: Re: LDAP V3 REPLICATION REQUIREMENTS DRAFT [Trimming] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk 7. Entry change information shall be purged upon completion of a synchronization cycle where all replica members have been synchronized with the master(s). This is implementation defined behaviour, which should not be mandated by the standard. I'm sure there are reasons why an implementor or administrator may choose to store information longer than is required by all replica members. It may be for back up insurance, or because some remote client which is not a formal replica member connects infrequently to collect updates. John -- John Merrells Netscape Communications Directory Server Software Engineer http://people.netscape.com/merrells From owner-ietf-ldup Tue Apr 14 13:49:34 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id NAA07703 for ietf-ldup-bks; Tue, 14 Apr 1998 13:49:34 -0700 (PDT) Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.7.3) with SMTP id NAA07699 for ; Tue, 14 Apr 1998 13:49:33 -0700 (PDT) Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Tue, 14 Apr 1998 14:48:04 -0600 Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Tue, 14 Apr 1998 14:46:37 -0600 From: "Ed Reed" To: merrells@netscape.com, RWEISER@novell.com Cc: ldup-repl@external.cicso.com, ietf-ldup@imc.org Subject: Re: LDAP V3 REPLICATION REQUIREMENTS DRAFT [Trimming] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: owner-ietf-ldup@imc.org Precedence: bulk As from my previous note, the interesting topic here is how one knows when = information, particularly obituaries/death warrants/tombstones for deleted = objects, are no longer needed. And the behavior of systems who have = purged that information when they interact with other systems who have not = is a reasonable topic of discussion, here... Ed ------------------- Ed Reed, Technologist Group Technology Office Novell, Inc. +1 801 861 3320 >>> "John Merrells" 04/14/1998 14:38:07 >>> 7. Entry change information shall be purged upon completion of a synchronization cycle where all replica members have been synchronized with the master(s). This is implementation defined behaviour, which should not be mandated by the standard. I'm sure there are reasons why an implementor or administrat= or may choose to store information longer than is required by all replica = members. It may be for back up insurance, or because some remote client which is = not a formal replica member connects infrequently to collect updates. John -- John Merrells Netscape Communications Directory Server Software Engineer http://people.netscape.com/merrells=20 From owner-ietf-ldup Tue Apr 14 14:03:52 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id OAA07824 for ietf-ldup-bks; Tue, 14 Apr 1998 14:03:52 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id OAA07820 for ; Tue, 14 Apr 1998 14:03:51 -0700 (PDT) Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id OAA10168 for ; Tue, 14 Apr 1998 14:03:58 -0700 (PDT) Received: from netscape.com ([208.12.63.187]) by tintin.mcom.com (Netscape Messaging Server 3.52) with ESMTP id AAA2545; Tue, 14 Apr 1998 14:03:57 -0700 Message-ID: <3533CF16.F4223222@netscape.com> Date: Tue, 14 Apr 1998 14:03:18 -0700 From: "John Merrells" Organization: Netscape Communications X-Mailer: Mozilla 4.04 [en]C-NSCP (WinNT; I) MIME-Version: 1.0 To: Russel Weiser CC: ldup-repl@external.cicso.com, ietf-ldup@imc.org Subject: Re: LDAP V3 REPLICATION REQUIREMENTS DRAFT [Critical Attribute] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk 2. Immediate replication of critical values in secs/mins such as user password changed SHALL be supported. What's the motivation for this scheduling policy? Say a site sets up a replica with the 'user password' to be replicated frequently, and every other attribute infrequently. The alternative equivalent configuration would be for *all* attributes to be updated frequently. The sum resource usage of the replication process is the same regardless of the scheduling policy enforced. In fact the infrequent schedule causes changes to be bunched up and transmitted on mass possibly consuming a high proportion of available bandwidth. Granted, this feature would allow an administrator to defer updates until 'after hours', but with fully connected WANs across multiple time zones the argument doesn't seem to hold. The bandwidth costs the same 24 hours a day, and there's always people on the network who would be affected by the surge of updates. Do you and/or your customers have network bandwidth price differentials they wish to optimise for? Is this replication scheduling policy something which you require? John -- John Merrells Netscape Communications Directory Server Software Engineer http://people.netscape.com/merrells From owner-ietf-ldup Tue Apr 14 14:09:47 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id OAA07870 for ietf-ldup-bks; Tue, 14 Apr 1998 14:09:47 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id OAA07866 for ; Tue, 14 Apr 1998 14:09:46 -0700 (PDT) Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id OAA10521 for ; Tue, 14 Apr 1998 14:09:57 -0700 (PDT) Received: from netscape.com ([208.12.63.187]) by tintin.mcom.com (Netscape Messaging Server 3.52) with ESMTP id AAA2654; Tue, 14 Apr 1998 14:09:56 -0700 Message-ID: <3533D07D.42EE9FF8@netscape.com> Date: Tue, 14 Apr 1998 14:09:17 -0700 From: "John Merrells" Organization: Netscape Communications X-Mailer: Mozilla 4.04 [en]C-NSCP (WinNT; I) MIME-Version: 1.0 To: Ed Reed CC: RWEISER@novell.com, ldup-repl@external.cicso.com, ietf-ldup@imc.org Subject: Re: LDAP V3 REPLICATION REQUIREMENTS DRAFT [Trimming] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk Ed Reed wrote: > As from my previous note, the interesting topic here is how one knows when information, particularly obituaries/death warrants/tombstones for deleted objects, are no longer needed. And the behavior of systems who have purged that information when they interact with other systems who have not is a reasonable topic of discussion, here... Yes, this is an interesting topic, one which all implementations must address, and indeed something we should discuss. >From the replication architecture I'm investigating I've found no need to mandate the way the server trims changes. I guess that your approach requires this. John -- John Merrells Netscape Communications Directory Server Software Engineer http://people.netscape.com/merrells From owner-ietf-ldup Tue Apr 14 14:19:18 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id OAA07948 for ietf-ldup-bks; Tue, 14 Apr 1998 14:19:18 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id OAA07944 for ; Tue, 14 Apr 1998 14:19:17 -0700 (PDT) Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id NAA07999 for ; Tue, 14 Apr 1998 13:23:39 -0700 (PDT) Received: from netscape.com ([208.12.63.187]) by tintin.mcom.com (Netscape Messaging Server 3.52) with ESMTP id AAA1DF4; Tue, 14 Apr 1998 13:23:39 -0700 Message-ID: <3533C5A4.C54FB826@netscape.com> Date: Tue, 14 Apr 1998 13:23:00 -0700 From: "John Merrells" Organization: Netscape Communications X-Mailer: Mozilla 4.04 [en]C-NSCP (WinNT; I) MIME-Version: 1.0 To: Russel Weiser CC: ldup-repl@external.cicso.com, ietf-ldup@imc.org Subject: Re: LDAP V3 REPLICATION REQUIREMENTS DRAFT [Auditability] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk Auditability - Each copy of a replica MUST maintain a history of who it has replicated with and who has replicated with it. I'm not sure I understand the reasoning for this requirement. Is this another administration / managability feature? John -- John Merrells Netscape Communications Directory Server Software Engineer http://people.netscape.com/merrells From owner-ietf-ldup Tue Apr 14 14:48:30 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id OAA08175 for ietf-ldup-bks; Tue, 14 Apr 1998 14:48:30 -0700 (PDT) Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.7.3) with SMTP id OAA08171 for ; Tue, 14 Apr 1998 14:48:30 -0700 (PDT) Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Tue, 14 Apr 1998 15:48:38 -0600 Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Tue, 14 Apr 1998 15:47:59 -0600 From: "Ed Reed" To: merrells@netscape.com, RWEISER@novell.com Cc: ldup-repl@external.cicso.com, ietf-ldup@imc.org Subject: Re: LDAP V3 REPLICATION REQUIREMENTS DRAFT [Critical Attribute] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: owner-ietf-ldup@imc.org Precedence: bulk John Merrells wrote... > 2. Immediate replication of critical values in secs/mins such as user > password changed SHALL be supported. > >What's the motivation for this scheduling policy? > >Say a site sets up a replica with the 'user password' to be replicated >frequently, and every other attribute infrequently. The alternative >equivalent configuration would be for *all* attributes to be updated >frequently. The sum resource usage of the replication process is the >same regardless of the scheduling policy enforced. In fact the >infrequent schedule causes changes to be bunched up and transmitted >on mass possibly consuming a high proportion of available bandwidth. >Granted, this feature would allow an administrator to defer updates >until 'after hours', but with fully connected WANs across multiple >time zones the argument doesn't seem to hold. The bandwidth costs >the same 24 hours a day, and there's always people on the network >who would be affected by the surge of updates. > >Do you and/or your customers have network bandwidth price >differentials they wish to optimise for? Is this replication scheduling >policy something which you require? Yes - explicitly in Europe, where ISDN connection setup charges are high, = and sites, particularly for branch offices, are usually NOT interconnected via WAN but by dial-on-demand ISDN lines, = there is a critical need to support queueing of low priority information for scheduled transmission. This is = one of the major factors motivating replication of STATE and not HISTORY...let me tell you from experience, = chatty replication protocols are a=20 bad thing, and you design them at your own commercial peril. The = bandwidth customers are willing to commit to WAN propagation of changes to directory infrastructure is considerably = less than directory architects usually assume they have available to them. Ed > >John > >-- >John Merrells >Netscape Communications >Directory Server >Software Engineer > >http://people.netscape.com/merrells=20 > > ------------------- Ed Reed, Technologist Group Technology Office Novell, Inc. +1 801 861 3320 From owner-ietf-ldup Tue Apr 14 14:46:08 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id OAA08147 for ietf-ldup-bks; Tue, 14 Apr 1998 14:46:08 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id OAA08143 for ; Tue, 14 Apr 1998 14:46:07 -0700 (PDT) Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id OAA21628 for ; Tue, 14 Apr 1998 14:45:49 -0700 (PDT) Received: from netscape.com ([208.12.63.54]) by tintin.mcom.com (Netscape Messaging Server 3.52) with ESMTP id AAA2C42; Tue, 14 Apr 1998 14:40:06 -0700 Message-ID: <3533D7B8.8F1A5AB0@netscape.com> Date: Tue, 14 Apr 1998 14:40:08 -0700 From: "Gordon Good" X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Russel Weiser CC: merrells@netscape.com, ldup-repl@external.cicso.com, ietf-ldup@imc.org Subject: Re: LDAP V3 REPLICATION REQUIREMENTS DRAFT References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms4FCFA2543BB254A2055692CE" Sender: owner-ietf-ldup@imc.org Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms4FCFA2543BB254A2055692CE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Russel Weiser wrote: > John > > I guess, that I'm not stating correctly is that the configuration and maintance issues are an interoprability issue such that in an true interoperable evnivonment such as Extranet scenario. > where two trading partners. Inorder yto exchange information corectly and insure that it is in facts working correctly how does the administrator of the replica say it me at novell look at the replica data and know from a management point of view that all the information in the local replica is correctly synchronized and when was it last performed. > > My real point here is that the selective attribute defining the Replica in and its schedule information > these may be in a "predetermined agreement" must be availiable at an approperiate Management point and be replicated so I can use my fancy admin tool and not need your fancy admin tool... Additionally I should be able to use LDAP protocol to access this information in a mixed topology > IBM/Netscape and Novell using a single adimin tool that may be provided by any of our companies. Agreed. We do need to define a standard way of representing the replication agreement information (we have the beginnings of that in http://search.ietf.org/internet-drafts/draft-ietf-asid-ldap-repl-info-01.txt, although it does need updating) so that management tools can interoperate. This also means that if we permit modifications to replication agreements over LDAP (which I think is a good thing), then we need to define the semantics associated with manipulating those agreements. For example, if there is an attribute which describes the update schedule for a given replica, then what happens when I modify that attribute? Besides this static configuration information, we also need to provide some way for a management application to retrieve replication state information from a server. Again, I think it would be good to do this by reading attribute values over LDAP. So, how about this language? Instead of: "Simple - Replication MUST be simple to configure and maintain" we say: "The Replication Protocol documents MUST define a standard schema for representing replication agreements, and MUST define the semantics associated with modifying the attributes of replication agreements. The documents MUST also define a standard method for determining the location of these agreements." "The Replication Protocol documents MUST define a standard schema for publishing state information about a given replica, and MUST define a standard method for determining the location of this information." Is this the gist of what you meant, Russell? --------------ms4FCFA2543BB254A2055692CE Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIGwgYJKoZIhvcNAQcCoIIGszCCBq8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BSkwggJoMIIB0aADAgECAgIKbzANBgkqhkiG9w0BAQQFADB3MQswCQYDVQQGEwJVUzEsMCoG A1UEChMjTmV0c2NhcGUgQ29tbXVuaWNhdGlvbnMgQ29ycG9yYXRpb24xHDAaBgNVBAsTE0lu Zm9ybWF0aW9uIFN5c3RlbXMxHDAaBgNVBAMTE3Jvb3RjYS5uZXRzY2FwZS5jb20wHhcNOTgw MzEyMTk0MDEzWhcNOTgwOTA4MTk0MDEzWjCBhzELMAkGA1UEBhMCVVMxJjAkBgNVBAoTHU5l dHNjYXBlIENvbW11bmljYXRpb25zIENvcnAuMRYwFAYDVQQDEw1Hb3Jkb24gUyBHb29kMSEw HwYJKoZIhvcNAQkBFhJnZ29vZEBuZXRzY2FwZS5jb20xFTATBgoJkiaJk/IsZAEBEwVnZ29v ZDBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDiq/4MD9jix6GMhWto/QMNLmSHoqFqLbHZLEiK 2iyvIO7ewVL1TEInb9Be/gGiytnTJgRBhVPX7RsgZojnwJ4RAgMBAAGjNjA0MBEGCWCGSAGG +EIBAQQEAwIAoDAfBgNVHSMEGDAWgBT84FToB/GV3jr3mcau+hUMbsQukjANBgkqhkiG9w0B AQQFAAOBgQAOI4HppvITt9kHdJJYsBhXwOjP6nZPQVi9qjZY/TXfHb8hF7Lbiu4tublZNYUS 1YAyYQdqSX9ZHq6Mxg/lTnP4lsfsL3LY7hY2sYWnhamhPX6sYOK1VygkzfLgTueuCOot+4mZ QIxJU+rD1/bAGpSAl9grCuYVAGyYGx2Pk7I3wDCCArkwggIioAMCAQICAQEwDQYJKoZIhvcN AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25z IENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0ZW1zMRwwGgYDVQQDExNy b290Y2EubmV0c2NhcGUuY29tMB4XDTk3MDMyNjAxNDQzOFoXDTk5MDMyNjAxNDQzOFowdzEL MAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIENvcnBvcmF0 aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0ZW1zMRwwGgYDVQQDExNyb290Y2EubmV0 c2NhcGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDBqj7+LT+lh8NH3/vabdgY oEU9+cebQ84ntFoTnBF9v9LyiF7Hv7KLebqn5SgLQKaOmTFVxfjOlgZeIoR2vwEiYsOpmSe7 CGgRFMcKftyyh/jH4CQwAbwtloXnGcMuoZN3LDQYL/vfokiz56CvegPki4x1pC2TIIwgOVSn RbpAZQIDAQABo1UwUzARBglghkgBhvhCAQEEBAMCAAQwHQYDVR0OBBYEFPzgVOgH8ZXeOveZ xq76FQxuxC6SMB8GA1UdIwQYMBaAFPzgVOgH8ZXeOveZxq76FQxuxC6SMA0GCSqGSIb3DQEB BAUAA4GBAFn32xtcegbE5sWYYYQYzvoGSyCxJMr8WX4/GPHkvqwQ2UrSaY9u/JHK9QQcCq65 +so57E0AGaZnlMzlQFtZhCSS8AEsGeQLLzsc9g8bhUXsw5fx4LpAy91XcYngi0lwSR/dtss0 b2/PLyHkU9EZZo9nYvDd7h1IKvBHe4N0h3nIMYIBYTCCAV0CAQEwfTB3MQswCQYDVQQGEwJV UzEsMCoGA1UEChMjTmV0c2NhcGUgQ29tbXVuaWNhdGlvbnMgQ29ycG9yYXRpb24xHDAaBgNV BAsTE0luZm9ybWF0aW9uIFN5c3RlbXMxHDAaBgNVBAMTE3Jvb3RjYS5uZXRzY2FwZS5jb20C AgpvMAkGBSsOAwIaBQCgfTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw05ODA0MTQyMTQwMDhaMB4GCSqGSIb3DQEJDzERMA8wDQYIKoZIhvcNAwICASgwIwYJ KoZIhvcNAQkEMRYEFPps+h3zPzGSG1exhh8j4x3DF+nmMA0GCSqGSIb3DQEBAQUABECOtb+X CL6e9zQul8YCG0l+RiVVtq6gNmwA4kL2A9xRFZ+cxiWrZ3ttIY3LbFaclIwV/r+FEnUn4yMw Nx95UHaV --------------ms4FCFA2543BB254A2055692CE-- From owner-ietf-ldup Tue Apr 14 15:13:36 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id PAA08408 for ietf-ldup-bks; Tue, 14 Apr 1998 15:13:36 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id PAA08404 for ; Tue, 14 Apr 1998 15:13:35 -0700 (PDT) Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id PAA14586 for ; Tue, 14 Apr 1998 15:13:45 -0700 (PDT) Received: from netscape.com ([208.12.63.187]) by tintin.mcom.com (Netscape Messaging Server 3.52) with ESMTP id AAA3337; Tue, 14 Apr 1998 15:13:44 -0700 Message-ID: <3533DF71.A665120D@netscape.com> Date: Tue, 14 Apr 1998 15:13:05 -0700 From: "John Merrells" Organization: Netscape Communications X-Mailer: Mozilla 4.04 [en]C-NSCP (WinNT; I) MIME-Version: 1.0 To: Russel Weiser CC: ldup-repl@external.cicso.com, ietf-ldup@imc.org Subject: Re: LDAP V3 REPLICATION REQUIREMENTS DRAFT [Scalability] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk I have some queries about the Scalability section.... 4.3 Scalability 1. Real time Vs. non-real-time operations. 2. Large amounts of replicated data. The unit of replication is defined to be the naming context. This naming context may consist of large amounts of data, all of which may be replicated. The replication mechanism must account for any amount of data to be replicated. Incremental replication must be allowed to attempt to keep the amount of data replicated to a minimum. 3. Large numbers transactions per second. 4. Scale to global Internet, or not. Due to the acceptance and usage of the Internet, and the requirement that LDAP replication be available across disparate vendors directory services, LDAP replication must scale to the internet level, but also must function at the enterprise level. 5. Large numbers of replicas, ie distributivity. A policy must be defined to account for simultaneous updates to multiple master replicas, where simultaneous is defined to be a period between replications. In such a case, these replication "conflicts" SHALL be resolved by the replication policy. A replica MAY store the conflicted versions of the replicated object to allow optional human review and intervention. 6. Arbitrary replication topology. Replication SHALL be allowed to any LDAP server available on the network. 7. Arbitrary Management topologies My thoughts... 1) What is meant by real-time and non-real-time operations, in the context of an LDAP server? This should be defined. It implies that the implementation should provide some guarantee of the maximum time period an operation will take to complete. Is this what's meant? 2) Firstly, 'large' can't really be defined very well. Different operating systems, and hardware architectures would limit the support of large replicas. Also, an implementor may choose to only support 'small' replicas. For instance; a laptop email client might keep a corporate address book replica on local storage; it shouldn't have to support 'Four11' because that's the definition of large. We should probably say that 'this Replication Standard should not limit the size of a replica'. 3) Again, 'large numbers of transactions'. Implementation Dependent. My Palm Pilot can't cope with high TPS, but I might want to have a partial replica of the corporate phone book. We should say 'this Replication Standard should not limit the transaction rate of a replication session.' 4) This statement doesn't really add much which isn't stated in the previous two statements. 7) Arbitary Management Topologies. This could also be further defined to make its meaning clear.. Generally this section needs to be tightened up to ensure that the proposed replication architecture imposes no scalability limits on an implementation. John -- John Merrells Netscape Communications Directory Server Software Engineer http://people.netscape.com/merrells From owner-ietf-ldup Tue Apr 14 15:06:42 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id PAA08336 for ietf-ldup-bks; Tue, 14 Apr 1998 15:06:42 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id PAA08332 for ; Tue, 14 Apr 1998 15:06:41 -0700 (PDT) Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id PAA23389 for ; Tue, 14 Apr 1998 15:06:52 -0700 (PDT) Received: from netscape.com ([208.12.63.54]) by tintin.mcom.com (Netscape Messaging Server 3.52) with ESMTP id AAA31FA; Tue, 14 Apr 1998 15:06:51 -0700 Message-ID: <3533DDFD.27C25586@netscape.com> Date: Tue, 14 Apr 1998 15:06:53 -0700 From: "Gordon Good" X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Russel Weiser CC: ldup-repl@external.cicso.com, ietf-ldup@imc.org Subject: Re: LDAP V3 REPLICATION REQUIREMENTS DRAFT References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msFBF92D35756A9BAFD488E41B" Sender: owner-ietf-ldup@imc.org Precedence: bulk This is a cryptographically signed message in MIME format. --------------msFBF92D35756A9BAFD488E41B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Russel Weiser wrote: > To the drafts editor: please publish the attached draft. > > To the LDUP group: please find attached draft of the > ldap rplication requirements document Please note that the applicability statement is not included and currently I am working on it. Russell, thanks for getting this out to the list. Here's a proposal. Since we seem to be hung up on the difference between "replication" and "synchronization", let's step back and ask, "do our customers perceive those two terms as having different meanings". In my experience, the answer is "no". I would therefore argue that we treat the two terms as synonyms. Then we can move on to defining the problem space we're operating in. I feel strongly that we should limit our problem space to that of making exact, partial, or fractional copies of directory entries contained in LDAP directories. I think we should stay away from trying to map schema elements from one directory to another - this starts to get into the space of metadirectories, which are a science project in and of themselves. Of course, we do need to address the issue of synchronizing directories with non-identical schema. However, I think that's an issue of merging schema definitions from multiple sources, where that schema is published in a well-defined format in a well-defined location in the DIT, according to the LDAPv3 documents. --------------msFBF92D35756A9BAFD488E41B Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIGwgYJKoZIhvcNAQcCoIIGszCCBq8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BSkwggJoMIIB0aADAgECAgIKbzANBgkqhkiG9w0BAQQFADB3MQswCQYDVQQGEwJVUzEsMCoG A1UEChMjTmV0c2NhcGUgQ29tbXVuaWNhdGlvbnMgQ29ycG9yYXRpb24xHDAaBgNVBAsTE0lu Zm9ybWF0aW9uIFN5c3RlbXMxHDAaBgNVBAMTE3Jvb3RjYS5uZXRzY2FwZS5jb20wHhcNOTgw MzEyMTk0MDEzWhcNOTgwOTA4MTk0MDEzWjCBhzELMAkGA1UEBhMCVVMxJjAkBgNVBAoTHU5l dHNjYXBlIENvbW11bmljYXRpb25zIENvcnAuMRYwFAYDVQQDEw1Hb3Jkb24gUyBHb29kMSEw HwYJKoZIhvcNAQkBFhJnZ29vZEBuZXRzY2FwZS5jb20xFTATBgoJkiaJk/IsZAEBEwVnZ29v ZDBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDiq/4MD9jix6GMhWto/QMNLmSHoqFqLbHZLEiK 2iyvIO7ewVL1TEInb9Be/gGiytnTJgRBhVPX7RsgZojnwJ4RAgMBAAGjNjA0MBEGCWCGSAGG +EIBAQQEAwIAoDAfBgNVHSMEGDAWgBT84FToB/GV3jr3mcau+hUMbsQukjANBgkqhkiG9w0B AQQFAAOBgQAOI4HppvITt9kHdJJYsBhXwOjP6nZPQVi9qjZY/TXfHb8hF7Lbiu4tublZNYUS 1YAyYQdqSX9ZHq6Mxg/lTnP4lsfsL3LY7hY2sYWnhamhPX6sYOK1VygkzfLgTueuCOot+4mZ QIxJU+rD1/bAGpSAl9grCuYVAGyYGx2Pk7I3wDCCArkwggIioAMCAQICAQEwDQYJKoZIhvcN AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25z IENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0ZW1zMRwwGgYDVQQDExNy b290Y2EubmV0c2NhcGUuY29tMB4XDTk3MDMyNjAxNDQzOFoXDTk5MDMyNjAxNDQzOFowdzEL MAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIENvcnBvcmF0 aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0ZW1zMRwwGgYDVQQDExNyb290Y2EubmV0 c2NhcGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDBqj7+LT+lh8NH3/vabdgY oEU9+cebQ84ntFoTnBF9v9LyiF7Hv7KLebqn5SgLQKaOmTFVxfjOlgZeIoR2vwEiYsOpmSe7 CGgRFMcKftyyh/jH4CQwAbwtloXnGcMuoZN3LDQYL/vfokiz56CvegPki4x1pC2TIIwgOVSn RbpAZQIDAQABo1UwUzARBglghkgBhvhCAQEEBAMCAAQwHQYDVR0OBBYEFPzgVOgH8ZXeOveZ xq76FQxuxC6SMB8GA1UdIwQYMBaAFPzgVOgH8ZXeOveZxq76FQxuxC6SMA0GCSqGSIb3DQEB BAUAA4GBAFn32xtcegbE5sWYYYQYzvoGSyCxJMr8WX4/GPHkvqwQ2UrSaY9u/JHK9QQcCq65 +so57E0AGaZnlMzlQFtZhCSS8AEsGeQLLzsc9g8bhUXsw5fx4LpAy91XcYngi0lwSR/dtss0 b2/PLyHkU9EZZo9nYvDd7h1IKvBHe4N0h3nIMYIBYTCCAV0CAQEwfTB3MQswCQYDVQQGEwJV UzEsMCoGA1UEChMjTmV0c2NhcGUgQ29tbXVuaWNhdGlvbnMgQ29ycG9yYXRpb24xHDAaBgNV BAsTE0luZm9ybWF0aW9uIFN5c3RlbXMxHDAaBgNVBAMTE3Jvb3RjYS5uZXRzY2FwZS5jb20C AgpvMAkGBSsOAwIaBQCgfTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw05ODA0MTQyMjA2NTNaMB4GCSqGSIb3DQEJDzERMA8wDQYIKoZIhvcNAwICASgwIwYJ KoZIhvcNAQkEMRYEFBBSxrsBxdK8ryVsD3X4ASyQrBg+MA0GCSqGSIb3DQEBAQUABEBPN/Ly MjrDdsbGiCZW+MD76Dt/K7SiWFlpZyLWukP9ClnLk9511h1PR+9N6CXamYfT+1J6YhvshSCX B2GvhIiM --------------msFBF92D35756A9BAFD488E41B-- From owner-ietf-ldup Tue Apr 14 16:48:45 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id QAA09669 for ietf-ldup-bks; Tue, 14 Apr 1998 16:48:45 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id QAA09665 for ; Tue, 14 Apr 1998 16:48:44 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id QAA28987 for ; Tue, 14 Apr 1998 16:48:55 -0700 (PDT) Received: from netscape.com ([208.12.63.97]) by dredd.mcom.com (Netscape Messaging Server 3.52) with ESMTP id AAA71B0; Tue, 14 Apr 1998 16:48:54 -0700 Message-ID: <3533F2D7.C5265392@netscape.com> Date: Tue, 14 Apr 1998 16:35:51 -0700 From: Tim Howes Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.04 [en] (X11; I; IRIX 6.2 IP22) MIME-Version: 1.0 To: John Merrells CC: Russel Weiser , ldup-repl@external.cicso.com, ietf-ldup@imc.org Subject: Re: LDAP V3 REPLICATION REQUIREMENTS DRAFT [Auditability] References: <3533C5A4.C54FB826@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk The underlying problem here, and what's behind many of the issues John is raising, seems to be that it's not clear what we are proposing to standardize. In the current document, there are requirements relating to all four of the following things which could be standardized. - The overall LDAP replication model. Like, what can you replicate, when can you replicate it, what gets sent during an update, etc. - The means by which two or more LDAP servers can synchronize their data. Like, the protocol two servers use to propagate updates. - The means by which a replication agreement between two or more LDAP servers can be created, deleted, or modified. Like, defining attributes representing replication agreements, where they live, what they mean, etc. - The means by which an existing LDAP replication environment can be monitored and/or managed. Like, defining attributes representing the state of replication, where they live, what it means to change them, etc. There are also some requirements that relate to the local administrative policies that implementations must make available. I don't think it's a bad idea to write down requirements relating to all of these things, but I do think it's a bad idea to mix them together. Mixing them together makes it hard for us to say, for example, that we are going to tackle the model and the protocol first, and leave the management and administration tasks for later. Also, for all of these requirements, we should ask ourselves whether the requirement is needed to provide interoperability or not. If so, in what area? If not, we should not worry about it. -- Tim John Merrells wrote: > Auditability - Each copy of a replica MUST maintain a history of > who it has replicated with and who has replicated with it. > > I'm not sure I understand the reasoning for this requirement. Is this > another administration / managability feature? > > John > > -- > John Merrells > Netscape Communications > Directory Server > Software Engineer > > http://people.netscape.com/merrells From owner-ietf-ldup Tue Apr 14 17:29:42 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id RAA10084 for ietf-ldup-bks; Tue, 14 Apr 1998 17:29:42 -0700 (PDT) Received: from novell.com (prv-mail25.Provo.Novell.COM [137.65.40.3]) by mail.proper.com (8.8.8/8.7.3) with SMTP id RAA10078 for ; Tue, 14 Apr 1998 17:29:32 -0700 (PDT) Received: from INET-PRV1-Message_Server by novell.com with Novell_GroupWise; Tue, 14 Apr 1998 18:29:43 -0600 Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Tue, 14 Apr 1998 18:28:58 -0600 From: "Russel Weiser" To: ggood@netscape.com Cc: ldup-repl@external.cicso.com, ietf-ldup@imc.org Subject: Re: LDAP V3 REPLICATION REQUIREMENTS DRAFT Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: owner-ietf-ldup@imc.org Precedence: bulk Gordon OK I'll agree that the mapping is something that we don't want to = get into at this point.=20 I'm not sure that I'm sugguesting to provide meta directory either. I = would like to be able to Filter=20 say a subset of Attributes to a new replica which basically becomes a = new naming context. Say to create a Whitepages directory from my Corp = directory.=20 I) Synchronization is the process of bringing a set of replica into sync. = So I would go on to say that the synchronization is the actual replication = protocol exchange over the Wire. 2) Replica of course is the reproduction of two or more copies of a = directory=20 =20 So what is replication???? I think it is the combiniation of the 1) and 2) = Now we may get into the concept of what ED and termed Sparse Replica's = where not all information in necessarly replicated.=20 cheers=20 RFW=20 PS I'm not that married to born terms being defined differently I just = want everyone to Agree what we're working on.=20 >>> "Gordon Good" 04/14 4:06 PM >>> Russel Weiser wrote: > To the drafts editor: please publish the attached draft. > > To the LDUP group: please find attached draft of the > ldap rplication requirements document Please note that the applicability= statement is not included and currently I am working on it. Russell, thanks for getting this out to the list. Here's a proposal. Since we seem to be hung up on the difference between = "replication" and "synchronization", let's step back and ask, "do our customers perceive those two terms as having different meanings". In my experience, the answer is "no". I would therefore argue that we = treat the two terms as synonyms. Then we can move on to defining the = problem space we're operating in. I feel strongly that we should limit our problem space to that of making = exact, partial, or fractional copies of directory entries contained in = LDAP directories. I think we should stay away from trying to map schema = elements from one directory to another - this starts to get into the space = of metadirectories, which are a science project in and of themselves. Of course, we do need to address the issue of synchronizing directories = with non-identical schema. However, I think that's an issue of merging schema definitions from multiple sources, where that schema is published = in a well-defined format in a well-defined location in the DIT, according = to the LDAPv3 documents. From owner-ietf-ldup Tue Apr 14 17:34:47 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id RAA10130 for ietf-ldup-bks; Tue, 14 Apr 1998 17:34:47 -0700 (PDT) Received: from novell.com (prv-mail25.Provo.Novell.COM [137.65.40.3]) by mail.proper.com (8.8.8/8.7.3) with SMTP id RAA10126 for ; Tue, 14 Apr 1998 17:34:46 -0700 (PDT) Received: from INET-PRV1-Message_Server by novell.com with Novell_GroupWise; Tue, 14 Apr 1998 18:34:57 -0600 Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Tue, 14 Apr 1998 18:34:20 -0600 From: "Russel Weiser" To: howes@netscape.com, merrells@netscape.com Cc: ldup-repl@external.cicso.com, ietf-ldup@imc.org Subject: Re: LDAP V3 REPLICATION REQUIREMENTS DRAFT [Auditability] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: owner-ietf-ldup@imc.org Precedence: bulk Tim=20 I agree that that seperating the four area out would be good,=20 but I have a strong opinion that they should all be worked on=20 in this group.=20 If you would take the Draft and Number things into 1-4 I'll=20 reorder things for it tomorrow . cheers=20 RFW =20 >>> Tim Howes 04/14 5:35 PM >>> The underlying problem here, and what's behind many of the issues John is raising, seems to be that it's not clear what we are proposing to standardize. In the current document, there are requirements relating to all four of the following things which could be standardized. - The overall LDAP replication model. Like, what can you replicate, when can you replicate it, what gets sent during an update, etc. - The means by which two or more LDAP servers can synchronize their data. Like, the protocol two servers use to propagate updates. - The means by which a replication agreement between two or more LDAP servers can be created, deleted, or modified. Like, defining attributes representing replication agreements, where they live, what they mean, etc. - The means by which an existing LDAP replication environment can be monitored and/or managed. Like, defining attributes representing the state of replication, where they live, what it means to change them, etc. There are also some requirements that relate to the local administrative policies that implementations must make available. I don't think it's a bad idea to write down requirements relating to all of these things, but I do think it's a bad idea to mix them together. Mixing them together makes it hard for us to say, for example, that we are going to tackle the model and the protocol first, and leave the management and administration tasks for later. Also, for all of these requirements, we should ask ourselves whether the requirement is needed to provide interoperability or not. If so, in what area? If not, we should not worry about it. -- Tim John Merrells wrote: > Auditability - Each copy of a replica MUST maintain a history of > who it has replicated with and who has replicated with it. > > I'm not sure I understand the reasoning for this requirement. Is this > another administration / managability feature? > > John > > -- > John Merrells > Netscape Communications > Directory Server > Software Engineer > > http://people.netscape.com/merrells=20 From owner-ietf-ldup Tue Apr 14 22:31:14 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id WAA11778 for ietf-ldup-bks; Tue, 14 Apr 1998 22:31:14 -0700 (PDT) Received: from ausmail.austin.ibm.com (ausmail.austin.ibm.com [192.35.232.19]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id WAA11774 for ; Tue, 14 Apr 1998 22:31:12 -0700 (PDT) Received: from netmail2.austin.ibm.com (netmail2.austin.ibm.com [9.53.250.97]) by ausmail.austin.ibm.com (8.8.5/8.8.5) with ESMTP id AAA23438; Wed, 15 Apr 1998 00:31:50 -0500 Received: from dceperf.austin.ibm.com (dceperf.austin.ibm.com [9.53.94.159]) by netmail2.austin.ibm.com (8.8.5/8.8.5) with SMTP id AAA77602; Wed, 15 Apr 1998 00:31:50 -0500 Received: from lig32-225-7-190.us.lig-dial.ibm.com by dceperf.austin.ibm.com (AIX 4.1/UCB 5.64/4.03-client-2.6) for ietf-ldup@imc.org at austin.ibm.com; id AA56966; Wed, 15 Apr 1998 00:31:24 -0500 Message-Id: X-Sender: stokes@popmail2.austin.ibm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 14 Apr 1998 23:52:07 -0500 To: Tim Howes From: Ellen Stokes Subject: Re: LDAP V3 REPLICATION REQUIREMENTS DRAFT [Auditability] Cc: John Merrells , Russel Weiser , ldup-repl@external.cicso.com, ietf-ldup@imc.org In-Reply-To: <3533F2D7.C5265392@netscape.com> References: <3533C5A4.C54FB826@netscape.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@imc.org Precedence: bulk Tim, I understand your motivation for grouping requirements so we can understand what we choose to tackle first. I also understand that the focus is interoperability. But, I want to make sure the requirements list is complete. There are some requriements that we'll find are independent of which mechanism is chosen to tackle when. And some of these items, such as auditability, may not be implemented first time out the chute, but still needs to be investigated and factored into the architecture and design now so we don't hang ourselves in the future. And it's not a bad thing to get 'policy stuff' on the table now either even if it goes in a separate document from the deployment group, for example. I'm certainly all in favor of keeping it simple and stating that interop is first and foremost, but we need to keep in mind the longer term vision. Ellen At 04:35 PM 4/14/98 -0700, Tim Howes wrote: >The underlying problem here, and what's behind many of >the issues John is raising, seems to be that it's not clear what >we are proposing to standardize. In the current document, >there are requirements relating to all four of the following >things which could be standardized. > >- The overall LDAP replication model. Like, what can >you replicate, when can you replicate it, what gets sent >during an update, etc. > >- The means by which two or more LDAP servers can >synchronize their data. Like, the protocol two servers use >to propagate updates. > >- The means by which a replication agreement between >two or more LDAP servers can be created, deleted, or >modified. Like, defining attributes representing replication >agreements, where they live, what they mean, etc. > >- The means by which an existing LDAP replication >environment can be monitored and/or managed. Like, >defining attributes representing the state of replication, >where they live, what it means to change them, etc. > >There are also some requirements that relate to the local >administrative policies that implementations must >make available. > >I don't think it's a bad idea to write down requirements >relating to all of these things, but I do think it's a bad idea >to mix them together. Mixing them together makes it hard >for us to say, for example, that we are going to tackle the >model and the protocol first, and leave the management >and administration tasks for later. > >Also, for all of these requirements, we should ask ourselves >whether the requirement is needed to provide interoperability >or not. If so, in what area? If not, we should not worry >about it. -- Tim > >John Merrells wrote: > >> Auditability - Each copy of a replica MUST maintain a history of >> who it has replicated with and who has replicated with it. >> >> I'm not sure I understand the reasoning for this requirement. Is this >> another administration / managability feature? >> >> John >> >> -- >> John Merrells >> Netscape Communications >> Directory Server >> Software Engineer >> >> http://people.netscape.com/merrells > From owner-ietf-ldup Wed Apr 15 04:06:01 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id EAA27543 for ietf-ldup-bks; Wed, 15 Apr 1998 04:06:01 -0700 (PDT) Received: from mothra.rs.itd.umich.edu (0@mothra.rs.itd.umich.edu [141.211.83.20]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id EAA27539 for ; Wed, 15 Apr 1998 04:06:00 -0700 (PDT) Received: from umich (pm2-14.ismi.net [206.31.56.54]) by mothra.rs.itd.umich.edu (8.8.5/2.4) with SMTP id HAA03456; Wed, 15 Apr 1998 07:04:52 -0400 (EDT) X-Mailer: BeyondMail for Windows/SMTP 3.0 Beta Build 1-21-97 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="BeyondBoundary_1_Wed_Apr_15_07:04:01_1998__29" Message-Id: In-Reply-To: Conversation-Id: Subject: Re: LDAP V3 REPLICATION REQUIREMENTS DRAFT Date: Wed, 15 Apr 1998 07:03:57 -0400 From: Larry Gauthier Reply-To: Larry Gauthier To: ggood@netscape.com, "Russel Weiser" Cc: ietf-ldup@imc.org, ldup-repl@external.cicso.com Sender: owner-ietf-ldup@imc.org Precedence: bulk --BeyondBoundary_1_Wed_Apr_15_07:04:01_1998__29 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit I guess I am not prepared to admit that Replicaton and Synchronization are identical operations. Getting back to the original definitions: > Replication - The process of copying portions of naming context > information and content, between multiple LDAP servers, such that > certain, predefined portions of the information are available from > many geographic locations. This sounds like a data (naming context: content, attributes, schema, object definitions) operation, in which all or a portion of the naming context from one server is shared with another server. > Synchronization - The process whereby LDAP servers participating in > the replication, are brought into a state where copies of the > information they make accessible are consistent with the other. This sounds more like naming context PLUS the coordination of admin and management practices - such as sharing of Policy, and Server process information(directory topology, replications order, availability, journaling) Since this interoperability will include intranet (other servers I own, know well, and trust fully) and extranet (trading partners and external parties) I would suggest that you can practice Replication (the sharing of an agreed naming context) without practicing Synchronization. Synchronization would be restricted to servers over which I exert administrative control. To be fully successful, I think this group needs to define the protocols for both practices, but all things must happen in some sequence and priority, and I would suggest the Replication is the first on the list. -larry gauthier the burton group ---------- Original Text ---------- From: "Russel Weiser" , on 4/14/98 6:28 PM: Gordon OK I'll agree that the mapping is something that we don't want to get into at this point. I'm not sure that I'm sugguesting to provide meta directory either. I would like to be able to Filter say a subset of Attributes to a new replica which basically becomes a new naming context. Say to create a Whitepages directory from my Corp directory. I) Synchronization is the process of bringing a set of replica into sync. So I would go on to say that the synchronization is the actual replication protocol exchange over the Wire. 2) Replica of course is the reproduction of two or more copies of a directory So what is replication???? I think it is the combiniation of the 1) and 2) Now we may get into the concept of what ED and termed Sparse Replica's where not all information in necessarly replicated. cheers RFW PS I'm not that married to born terms being defined differently I just want everyone to Agree what we're working on. >>> "Gordon Good" 04/14 4:06 PM >>> Russel Weiser wrote: > To the drafts editor: please publish the attached draft. > > To the LDUP group: please find attached draft of the > ldap rplication requirements document Please note that the applicability statement is not included and currently I am working on it. Russell, thanks for getting this out to the list. Here's a proposal. Since we seem to be hung up on the difference between "replication" and "synchronization", let's step back and ask, "do our customers perceive those two terms as having different meanings". In my experience, the answer is "no". I would therefore argue that we treat the two terms as synonyms. Then we can move on to defining the problem space we're operating in. I feel strongly that we should limit our problem space to that of making exact, partial, or fractional copies of directory entries contained in LDAP directories. I think we should stay away from trying to map schema elements from one directory to another - this starts to get into the space of metadirectories, which are a science project in and of themselves. Of course, we do need to address the issue of synchronizing directories with non-identical schema. However, I think that's an issue of merging schema definitions from multiple sources, where that schema is published in a well-defined format in a well-defined location in the DIT, according to the LDAPv3 documents. --BeyondBoundary_1_Wed_Apr_15_07:04:01_1998__29 Content-Type: application/X-BeyondMail Content-Transfer-Encoding: X-UUENCODE Content-Disposition: attachment; filename="Beyond.rtf" begin 666 Beyond.rtf M1F]R;3H@4F5P;'D-"E!R979I;W5S($9R;VTZ(")2=7-S96P@5V5I'1E'0Z( T**CY686QU93PJ#0I[ M7')T9EQA;G-I7&1E9F8P>UQF;VYT=&)L>UQF,%QF;FEL7&9C:&%RF%T:6]N(&%R92!I9&5N=&EC86P@;W!E'1<<&%R( T* M/B @:6YF;W)M871I;VX@86YD(&-O;G1E;G0L(&)E='=E96X@;75L=&EP;&4@ M3$1!4"!S97)V97)S+"!S=6-H('1H871<<&%R( T*/B @8V5R=&%I;BP@<')E M9&5F:6YE9"!P;W)T:6]N6YC:')O;FEZ871I;VX@+2!4:&4@<')O8V5S2!M86ME(&%C8V5S'0@4$Q54R!T M:&4@8V]O'1R86YE=" H=')A9&EN9R!P87)T M;F5R6]U(&-A;B!PF%T:6]N+B!3>6YC:')O;FEZ871I;VX@=V]U;&0@8F4@ M&5R="!A9&UI M;FES=')A=&EV92!C;VYT2!G875T M:&EE'0N(%-A>2!T;R!C2!FF%T:6]N(&ES('1H92!A8W1U86P@ M2!R97!L M:6-A=&5D+B *"F-H965R2!)(&IU M6]N92!T;R!!9W)E92!W:&%T("!W92=R92!W;W)K:6YG M(&]N+B *"@H^/CX@(D=O2!S=&%T96UE;G0@:7,@;F]T(&EN8VQU9&5D(&%N9"!C=7)R M96YT;'D@22!A;2!W;W)K:6YG(&]N(&ET+@H*4G5SF%T:6]N(BP@;&5T)W,@6YO;GEM2!A=V%Y(&9R;VT@=')Y:6YG('1O(&UA<"!S M8VAE;6$@96QE;65N=',@9G)O;2!O;F4@9&ER96-T;W)Y('1O(&%N;W1H97(@ M+2!T:&ES('-T87)TFEN9R!D:7)E8W1Ointo at this point. I'm not sure that I'm sugguesting to provide meta directory >either. I would like to be able to Filter say a subset of Attributes to a new >replica which basically becomes a new naming context. Say to create a >Whitepages directory from my Corp directory. > >I) Synchronization is the process of bringing a set of replica into sync. So I >would go on to say that the synchronization is the actual replication protocol >exchange over the Wire. > >2) Replica of course is the reproduction of two or more copies of a directory >So what is replication???? I think it is the combiniation of the 1) and 2) Now >we may get into the concept of what ED and termed Sparse Replica's where not >all information in necessarly replicated. > >cheers RFW >PS I'm not that married to born terms being defined differently I just want >everyone to Agree what we're working on. > > >>>> "Gordon Good" 04/14 4:06 PM >>> >Russel Weiser wrote: > >> To the drafts editor: please publish the attached draft. >> >> To the LDUP group: please find attached draft of the >> ldap rplication requirements document Please note that the applicability >statement is not included and currently I am working on it. > >Russell, thanks for getting this out to the list. > >Here's a proposal. Since we seem to be hung up on the difference between >"replication" and "synchronization", let's step back and ask, "do our >customers perceive those two terms as having different meanings". > >In my experience, the answer is "no". I would therefore argue that we treat >the two terms as synonyms. Then we can move on to defining the problem >space we're operating in. > >I feel strongly that we should limit our problem space to that of making exact, >partial, or fractional copies of directory entries contained in LDAP >directories. I think we should stay away from trying to map schema elements >from one directory to another - this starts to get into the space of >metadirectories, which are a science project in and of themselves. > >Of course, we do need to address the issue of synchronizing directories with >non-identical schema. However, I think that's an issue of merging >schema definitions from multiple sources, where that schema is published in a >well-defined format in a well-defined location in the DIT, according to >the LDAPv3 documents. > > > >Attachment Converted: "C:\Program Files\Eudora\Attach\Beyond1.rtf" > From owner-ietf-ldup Wed Apr 15 08:17:38 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id IAA29297 for ietf-ldup-bks; Wed, 15 Apr 1998 08:17:38 -0700 (PDT) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id IAA29293 for ; Wed, 15 Apr 1998 08:17:37 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id LAA02007; Wed, 15 Apr 1998 11:17:35 -0400 (EDT) Message-Id: <199804151517.LAA02007@ns.ietf.org> To: "Russel Weiser" cc: ldup-repl@external.cicso.com, cclark@ietf.org, ietf-ldup@imc.org Subject: Re: LDAP V3 REPLICATION REQUIREMENTS DRAFT In-reply-to: Your message of "Tue, 14 Apr 1998 12:07:52 MDT." Date: Wed, 15 Apr 1998 11:17:34 -0400 From: Cynthia Clark Sender: owner-ietf-ldup@imc.org Precedence: bulk Russel, Please clarify this: You've just submitted the new Internet-Draft filename but there is another Internet-Draft with an exact same title: "LDAP Replication Requirements" Do you mean that the new Internet-Draft replaces the previous Internet-Draft ?? Please reply back to me at asap. FYI: I've just made a minor editorial change by replacing the third paragraph of the Status of this Memo section: To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Please use this one for the future reference. Please note that I've removed "ds.internic.net" from this paragraph mainly due to the fact it's no longer in service. I look forward hearing from you before I'll do anything with your new Internet-Draft. Thanks, Cynthia ------------------------------------------------------ Cynthia Clark, IETF Internet-Drafts Administrator E-mail: ------------------------------------------------------- From owner-ietf-ldup Wed Apr 15 11:59:17 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA02202 for ietf-ldup-bks; Wed, 15 Apr 1998 11:59:17 -0700 (PDT) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id LAA02198 for ; Wed, 15 Apr 1998 11:59:10 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id OAA08674; Wed, 15 Apr 1998 14:59:07 -0400 (EDT) Message-Id: <199804151859.OAA08674@ns.ietf.org> To: "Russel Weiser" cc: Cynthia Clark , ldup-repl@external.cicso.com, ietf-ldup@imc.org Subject: Re: LDAP V3 REPLICATION REQUIREMENTS DRAFT In-reply-to: Your message of "Tue, 14 Apr 1998 12:07:52 MDT." Date: Wed, 15 Apr 1998 14:59:07 -0400 From: Cynthia Clark Sender: owner-ietf-ldup@imc.org Precedence: bulk FYI: The filename you've submitted has been changed from to I will send the announcement to the entire ietf sometime soon If you have any questions/concerns about any drafts, please contact me directly at Cynthia ------------------------------------------------------ Cynthia Clark, IETF Internet-Drafts Administrator E-mail Address preference: ------------------------------------------------------- From owner-ietf-ldup Wed Apr 15 12:39:12 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id MAA04113 for ietf-ldup-bks; Wed, 15 Apr 1998 12:39:12 -0700 (PDT) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id MAA04108 for ; Wed, 15 Apr 1998 12:39:06 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id PAA09566; Wed, 15 Apr 1998 15:39:16 -0400 (EDT) Message-Id: <199804151939.PAA09566@ns.ietf.org> To: "Russel Weiser" cc: Cynthia Clark , ldup-repl@external.cicso.com, ietf-ldup@imc.org Subject: Re: LDAP V3 REPLICATION REQUIREMENTS DRAFT In-reply-to: Your message of "Tue, 14 Apr 1998 12:07:52 MDT." Date: Wed, 15 Apr 1998 15:39:16 -0400 From: Cynthia Clark Sender: owner-ietf-ldup@imc.org Precedence: bulk Russel, Sorry, the filename has been changed from to - I will be sending the announcement to the entire ietf sometime tomorrow Kind Regards, Cynthia ------------------------------------------------------ Cynthia Clark, IETF Internet-Drafts Administrator E-mail Address preference: ------------------------------------------------------- From owner-ietf-ldup Wed Apr 15 13:08:57 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id NAA04485 for ietf-ldup-bks; Wed, 15 Apr 1998 13:08:57 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id NAA04481 for ; Wed, 15 Apr 1998 13:08:56 -0700 (PDT) Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id NAA10099 for ; Wed, 15 Apr 1998 13:09:11 -0700 (PDT) Received: from netscape.com ([208.12.63.187]) by tintin.mcom.com (Netscape Messaging Server 3.52) with ESMTP id AAA42A6 for ; Wed, 15 Apr 1998 13:09:11 -0700 Message-ID: <353513BE.45D25CE3@netscape.com> Date: Wed, 15 Apr 1998 13:08:30 -0700 From: "John Merrells" Organization: Netscape Communications X-Mailer: Mozilla 4.04 [en]C-NSCP (WinNT; I) MIME-Version: 1.0 To: LDUP Subject: Repl Req Summary Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk To help my understanding of the requirements document I extracted and numbered all the clauses. This may help you too... Summary of Replication Requirements <4. General Requirements> 1) Simple - Replication MUST be simple to configure and maintain. 2) Efficient - The act of replication MUST have minimal impact on both the system and network performance and throughput. In order to achieve this efficiency, replication policies SHALL allow replication of changed information to be postponed to a more convenient period, or done at user request. It is not required to have all replica copies on the network available at replication time. In a distributed enterprise environment, it is unrealistic to assume that all copies of a replica will be available for update at all times. Under this circumstance, when a previously unavailable replica copy comes on line, it SHOULD initiate replication with another replicated copy such that its local replicated information is brought up to date. 3) Reliable - All replicated copies MUST eventually be updated with the changed information, specified by the replication policy. 4) Provides Interoperability between vendors - Replicas MUST be allowed to span different vendors directory services. Without such vendor interoperability, Internet based directory services will not be feasible. 5) Security of data, connections and replication process - Replicated data MUST be transferred in a secure manner, where both endpoints in the communication have identified and authenticated themselves to the other server. 6) Robustness - The ability to deal with differences in directory services schemas in a cross vendor enterprise. The ability to recover when a replica server is unavailable during replication. 7) Location independent manageability - A replica administrator MUST be allowed access to the replication policies, regardless of network location. 8) Auditability - Each copy of a replica MUST maintain a history of who it has replicated with and who has replicated with it. 9) Ability to Set Change Metrics - Replication schedules MUST be dynamic to allow for periodic replication, with the replication period determined by administrator of the replicated system. In addition, replication policy must be globally available to any authorized administrator from anyplace on the network. 10) Replication Policy Mechanisms - Policies to allow both schedule and content of replicated information MUST be allowed. Policies SHALL allow replication to be schedule both on a periodic basis, as well as on a number of changes basis. 11) Multi-master and Master-Slave - Support for both multi-master and master-slave environments should be a driving requirement. Since master-slave is considered a proper subset of multi-master, both these models MUST be supported. 12) Flexibility - LDAP replication MUST allow for both total and incremental update of objects. In addition, updates MUST be allowed to multiple replicas to enhance distributed performance and reliability. 13) Synchronization of LDAP replicas MUST allow either master or replica to initiate the replication process and allow the initiator to determine whether it will become a consumer and or supplier during the synchronization process. This would allow a replica to be periodically connected and synchronized from remote sites at the local administrator's discretion. 14) All replicated information between the master database and its replica databases SHALL be identical including all no user modify operational attributes such as time stamps. Note this does not imply that the entire database is identical from replica to replica, but that the subset of data, chosen to replicate is identical from replica to replica. 15) Distributed multi-vendor environment, LDAP replication SHALL NOT ensure all copies of the replicated information be complete copies of the replicated object. It is not realistic to assume that all vendors have cooperating schemas, but it is required that different vendors schemas allow replication from diverse schemas. LDAP replication SHALL encompass common schema objects and attributes, and MAY define a model whereby divergent schemas can replicate non-common or extended attributes for common LDAP objects. 16) SubTree Replication - Subtree Replication SHALL be defined to allow for greater flexibility replication toplologies of the DIT as discussed in X.525 section 7.2 [X.525]. <4.1 Replication policy> 17) Policies for the LDAP replication SHALL be defined in such a manner as to allow programmatic representation; these policies shall be kept as replica attributes or as entries of the predetermined agreement discussed in section 4.2 to be propagated during replication. <4.1.1 Propagation behavior> 18) Replication SHALL only be allowed after the authentication and verification of authorization of both the replica and the source directory. 19) The transport for LDAP synchronization MUST allow for the integrity and confidentiality of each replicated server. 20) The replica synchronization MUST be handled in such a manner as to not saturate network with repetitive entry replication from multiple synchronization providers points. 21) Full copy replication SHOULD be supported for reset and initial loading of a replica using the LDIF [LDIF]. 22) The normal means of synchronizing replicas SHALL be performed through incremental synchronization and in accordance with the scheduling policies of section 4.1.2. 23) Multiple LDAP changes, to a single server, SHOULD be allowed to be treated as single atomic unit of work propagated during replication. 24) Entry change information SHALL be purged upon completion of a synchronization cycle where all replica members have been synchronized with the master(s). 25) Replication policies SHOULD contain clauses to account for the instance of a replica being unavailable at the scheduled update time. <4.1.2 Scheduling policies> 26) A propagation schedule SHALL be defined and SHOULD be tunable such that every X hours and or N changes will automatically begin a replication cycle. 27) Immediate replication of critical values in secs/mins such as user password changed SHALL be supported. 28) Allowance for non scheduled replication of a replica SHALL be provided upon request such that the replica server has been down or unconnected for a period of time. <4.2 Predetermined Replication Agreements> 29) The use of predetermined replication agreements between the master directories and replica directories MUST be addressed to provide proper knowledge of access requirements and credentials between the synchronizing directories. 30) Replication agreements SHOULD be accessible, via LDAP, to all servers containing replicated information. <4.3 Scalability> 31) Large amounts of replicated data. The unit of replication is defined to be the naming context. This naming context may consist of large amounts of data, all of which may be replicated. The replication mechanism must account for any amount of data to be replicated. Incremental replication MUST be allowed to attempt to keep the amount of data replicated to a minimum. 32) Scale to global Internet, or not. Due to the acceptance and usage of the Internet, and the requirement that LDAP replication be available across disparate vendors directory services, LDAP replication MUST scale to the internet level, but also must function at the enterprise level. 33) Large numbers of replicas, ie distributivity. A policy MUST be defined to account for simultaneous updates to multiple master replicas, where simultaneous is defined to be a period between replications. In such a case, these replication "conflicts" SHALL be resolved by the replication policy. A replica MAY store the conflicted versions of the replicated object to allow optional human review and intervention. 34) Arbitrary replication topology. Replication SHALL be allowed to any LDAP server available on the network. <4.4 LDAP Access> 35) MUST provide access to replication topology and policies via LDAP. <4.5 Administration Utility Requirements> 36) SHALL The capability to check the differences between two replicas of the same information. 37) SHALL The capability to view the replication topology from a single server in the topology. 38) SHALL The capability to view the current state and replication history of each replicated copy in the replication topology, from a single server in the topology. 39) SHALL The ability to view replication conflicts, and override the resolution derived by the replication policy. -- John Merrells Netscape Communications Directory Server Software Engineer http://people.netscape.com/merrells From owner-ietf-ldup Wed Apr 15 13:40:44 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id NAA04688 for ietf-ldup-bks; Wed, 15 Apr 1998 13:40:44 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id NAA04683 for ; Wed, 15 Apr 1998 13:40:43 -0700 (PDT) Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id NAA11974 for ; Wed, 15 Apr 1998 13:40:59 -0700 (PDT) Received: from netscape.com ([208.12.63.187]) by tintin.mcom.com (Netscape Messaging Server 3.52) with ESMTP id AAA46FC for ; Wed, 15 Apr 1998 13:40:58 -0700 Message-ID: <35351B30.D2FE49E0@netscape.com> Date: Wed, 15 Apr 1998 13:40:16 -0700 From: "John Merrells" Organization: Netscape Communications X-Mailer: Mozilla 4.04 [en]C-NSCP (WinNT; I) MIME-Version: 1.0 To: LDUP Subject: requirements List Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk The architecture abstracts to be aired on Friday must cover all the requirements in the repl req draft. Here's my list of the sub-clauses which must be addressed. It's expressed in my terms, and represents my understand of the current requirements. I hope this will spur on some more debate... John Mega-Summary of Replication Requirements <4. General Requirements> 1) Replication MUST be simple to configure and maintain. 2.1) MUST be resource efficient. 2.2) SHALL allow replication to be postponed. 2.3) SHALL allow user initiated replication. 2.4) SHOULD update any unavailable replica when it comes back online. 3) All changes MUST eventually be applied to all Replicas. 4) MUST be interoperable. 5.1) MUST authenticate identity of replication partners. 5.2) MUST transfer updates securely. 6.1) MUST deal with differing schema 6.2) MUST recover if a replication party fails during update. 7) MUST provide LDAP access to replication agreements. 8) MUST maintain audit log. 9.1) Replication Agreements MUST allow scheduled replication. 9.2) MUST provide LDAP access to replication agreements. (Repeat of 1 & 7) 10.1) Replication Policy MUST allow scheduled replication. (Repeat of 9.1?) 10.2) Replication Policy MUST allow definition of replication content. 10.3) SHALL support scheduled replication Replication Policy. (repeat of 10.1, 9.1) 10.4) SHALL allow 'number of changes' Replication Policy . 11.1) MUST support Multi-master. 11.2) MUST support Master-Slave. 12.1) MUST allow total update. 12.2) MUST allow incremental update. 12.3) MUST allow updates to multiple replicas 13.1) MUST allow either master or replica be initiator 13.2) MUST allow initiator to determine if it is a supplier or consumer. 14) Master and Replica data SHALL be identical. 15.1) SHALL NOT ensure all Replicas are complete copies. 15.2) SHALL encompass common schema objects and attributes, 15.3) MAY define a mapping between divergent schemas for non-common schema objects and attributes. 16) SHALL define subtree replication (X.525 section 7.2) <4.1 Replication policy> 17) SHALL store Replication Agreements as entries. <4.1.1 Propagation behavior> 18) SHALL authenticate identity of replication parties (Repeat of 5.1) 19) SHALL transfer updates securely (Repeat of 5.2) 20) MUST NOT saturate network. 21) SHALL support total update. (Repeat of 12.1) 22) SHALL support be incremental update. (Repeat of 12.2) 23) SHOULD support transactions. 24) SHALL purge change information after replication. 25) Replication policies SHOULD contain clauses to account for the instance of a replica being unavailable at the scheduled update time. <4.1.2 Scheduling policies> 26.1) SHALL define replication schedule (Repeat of 9.1?) 26.2) SHOULD support 'every X hours' schedule 26.3) SHOULD support 'every N changes' schedule 27) SHALL support immediate replication of critical attributes. 28) SHALL allow user to initiate replication (Repeat of 2.3) <4.2 Predetermined Replication Agreements> 29) MUST have Replication Agreements. 30) SHOULD allow LDAP access to Replication Agreements. <4.3 Scalability> 31) MUST support incremental update. (Repeat of 12.2 & 22) 32.1) MUST scale to internet. 32.2) MUST function in enterprise. 33.1) MUST detect and resolve update conflicts in multi-master topology. 33.2) SHALL detect and resolve update conflicts in multi-master topology. 33.3) MAY store conflicts to allow user intervention. 34) SHALL allow replication with any LDAP server on network <4.4 LDAP Access> 35) MUST allow LDAP access to replication topology. 35) MUST allow LDAP access to replication agreements. (Repeat) <4.5 Administration Utility Requirements> 36) SHALL allow diff of Replicas. 37) SHALL allow view of replication topology from single server. 38.1) SHALL report state of each replica. 38.2) SHALL report replication history of each replica. 39) SHALL allow user intervention to resolve conflicts. (Conflict with MAY in 33.3) -- John Merrells Netscape Communications Directory Server Software Engineer http://people.netscape.com/merrells From owner-ietf-ldup Wed Apr 15 17:19:14 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id RAA09784 for ietf-ldup-bks; Wed, 15 Apr 1998 17:19:14 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id RAA09780 for ; Wed, 15 Apr 1998 17:19:13 -0700 (PDT) Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id RAA28202 for ; Wed, 15 Apr 1998 17:17:37 -0700 (PDT) Received: from netscape.com ([208.12.63.187]) by tintin.mcom.com (Netscape Messaging Server 3.52) with ESMTP id AAA6DC3 for ; Wed, 15 Apr 1998 17:17:37 -0700 Message-ID: <35354DF7.B2D7D4C5@netscape.com> Date: Wed, 15 Apr 1998 17:16:55 -0700 From: "John Merrells" Organization: Netscape Communications X-Mailer: Mozilla 4.04 [en]C-NSCP (WinNT; I) MIME-Version: 1.0 To: LDUP Subject: Repl Req: Unavailability Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk 25) Replication policies SHOULD contain clauses to account for the instance of a replica being unavailable at the scheduled update time. I'm not sure what this 'clause' in the policy would say. Do you have a driving example? John -- John Merrells Netscape Communications Directory Server Software Engineer http://people.netscape.com/merrells From owner-ietf-ldup Wed Apr 15 17:30:29 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id RAA09905 for ietf-ldup-bks; Wed, 15 Apr 1998 17:30:29 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id RAA09901 for ; Wed, 15 Apr 1998 17:30:28 -0700 (PDT) Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id RAA29176 for ; Wed, 15 Apr 1998 17:30:43 -0700 (PDT) Received: from netscape.com ([208.12.63.187]) by tintin.mcom.com (Netscape Messaging Server 3.52) with ESMTP id AAA6FD0 for ; Wed, 15 Apr 1998 17:30:43 -0700 Message-ID: <35355109.AB936485@netscape.com> Date: Wed, 15 Apr 1998 17:30:01 -0700 From: "John Merrells" Organization: Netscape Communications X-Mailer: Mozilla 4.04 [en]C-NSCP (WinNT; I) MIME-Version: 1.0 To: LDUP Subject: Requirements Categorisation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk Yesterday, Tim Howes suggested that there were four or five broad categories into which our requirements could be disected. I've taken the list of requirements, removed the duplicates, and broken them down into the groups Tim suggested. Our architecture proposal will address groups A & B & C. John A) ----------- Replication Model ----------- 2.4) SHOULD update any unavailable replica when it comes back online. 3) All changes MUST eventually be applied to all Replicas. 4) MUST be interoperable. 9.1) MUST allow scheduled replication. 10.2) Replication Policy MUST allow definition of replication content. 10.4) SHALL allow 'number of changes' Replication Policy . 11.1) MUST support Multi-master. 11.2) MUST support Master-Slave. 14) Master and Replica data SHALL be identical. 15.1) SHALL NOT ensure all Replicas are complete copies. 15.2) SHALL encompass common schema objects and attributes, 16) SHALL define subtree replication (X.525 section 7.2) 26.2) SHOULD support 'every X hours' schedule 26.3) SHOULD support 'every N changes' schedule 27) SHALL support immediate replication of critical attributes. 29) MUST have Replication Agreements. 32.1) MUST scale to internet. 32.2) MUST function in enterprise. 33.1) MUST detect and resolve update conflicts in multi-master topology. 34) SHALL allow replication with any LDAP server on network B) ----------- Replication Protocol ----------- 2.1) MUST be resource efficient. 5.1) MUST authenticate identity of replication partners. 5.2) MUST transfer updates securely. 6.2) MUST recover if a replication party fails during update. 12.1) MUST allow total update. 12.2) MUST allow incremental update. 12.3) MUST allow updates to multiple replicas 13.1) MUST allow either master or replica be initiator 13.2) MUST allow initiator to determine if it is a supplier or consumer. 20) MUST NOT saturate network. 23) SHOULD support transactions. 24) SHALL purge change information after replication. C) ----------- Replication Agreements ----------- 7) MUST provide LDAP access to replication agreements. 17) SHALL store Replication Agreements as entries. D) ----------- Administration And Management ----------- 1) Replication MUST be simple to configure and maintain. 2.2) SHALL allow replication to be postponed. 2.3) SHALL allow user initiated replication. 8) MUST maintain audit log. 33.3) MAY store conflicts to allow user intervention. 35) MUST allow LDAP access to replication topology. 36) SHALL allow diff of Replicas. 37) SHALL allow view of replication topology from single server. 38.1) SHALL report state of each replica. 38.2) SHALL report replication history of each replica. 39) SHALL allow user intervention to resolve conflicts. (Conflict with MAY in 33.3) E) ----------- Other ----------- 25) Replication policies SHOULD contain clauses to account for the instance of a replica being unavailable at the scheduled update time. 6.1) MUST deal with differing schema 15.3) MAY define a mapping between divergent schemas for non-common schema objects and attributes. -- John Merrells Netscape Communications Directory Server Software Engineer http://people.netscape.com/merrells From owner-ietf-ldup Thu Apr 16 11:27:39 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA05695 for ietf-ldup-bks; Thu, 16 Apr 1998 11:27:39 -0700 (PDT) Received: from nome.software.com (nome.software.com [207.175.94.3]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id LAA05688 for ; Thu, 16 Apr 1998 11:27:37 -0700 (PDT) Received: from sanjay_jain ([10.8.5.3]) by nome.software.com (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-41946U5000L500S0) with ESMTP id AAA11535; Thu, 16 Apr 1998 11:27:56 -0700 From: Sanjay.Jain@software.com (Sanjay Jain) To: "John Merrells" , "LDUP" Subject: Re: Requirements Categorisation Date: Thu, 16 Apr 1998 11:27:54 -0700 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1161 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <19980416182756.AAA11535@sanjay_jain> Sender: owner-ietf-ldup@imc.org Precedence: bulk > > B) ----------- Replication Protocol ----------- > > 13.2) MUST allow initiator to determine if it is a supplier or consumer. Should it be specified in the replication agreement or should it be determined at the replication updates exchange time ? > 23) SHOULD support transactions. What does that mean ? Does it mean that either all replication updates are applied at the consumer site or none ? Have we covered somewhere the requirement that the relevant meta information e.g. relevant ACLs should also be transfered from the supplier to the consumer ? sanjay From owner-ietf-ldup Thu Apr 16 17:48:49 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id RAA20487 for ietf-ldup-bks; Thu, 16 Apr 1998 17:48:49 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id RAA20479 for ; Thu, 16 Apr 1998 17:48:48 -0700 (PDT) Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id RAA29573 for ; Thu, 16 Apr 1998 17:49:09 -0700 (PDT) Received: from netscape.com ([208.12.63.187]) by tintin.mcom.com (Netscape Messaging Server 3.52) with ESMTP id AAA2B84; Thu, 16 Apr 1998 17:49:08 -0700 Message-ID: <3536A6D8.613BFCA@netscape.com> Date: Thu, 16 Apr 1998 17:48:24 -0700 From: "John Merrells" Organization: Netscape Communications X-Mailer: Mozilla 4.04 [en]C-NSCP (WinNT; I) MIME-Version: 1.0 To: Sanjay Jain CC: LDUP Subject: Re: Requirements Categorisation References: <19980416182756.AAA11535@sanjay_jain> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk Sanjay Jain wrote: > > > > B) ----------- Replication Protocol ----------- > > > > 13.2) MUST allow initiator to determine if it is a supplier or consumer. > > Should it be specified in the replication agreement or should it be > determined at the replication updates exchange time ? I believe that the Replication Agreement should specify this. But, I don'tthink an architecture should have to implement all the combinations of: one-way/two-way, full/incremental update, and consumer/supplier. > > 23) SHOULD support transactions. > > What does that mean ? Does it mean that either all replication updates are > applied at the consumer site or none ? I asked about this, but haven't received a response. My interpretation is that if we support transactions, then we must faithfully repliciate each transaction as a transaction. > Have we covered somewhere the requirement that the relevant meta > information e.g. relevant ACLs should also be transfered from the supplier > to the consumer ? There is no mention of access control in the requirements. I think we should have a statement in there regarding this. Part of the Replication Session initiation should include some handshaking about what access control models are supported. An administrator may wish to only allow replciation to occur with foreign servers which can apply that administrators access control policy. John -- John Merrells Netscape Communications Directory Server Software Engineer http://people.netscape.com/merrells From owner-ietf-ldup Thu Apr 16 20:50:20 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id UAA21930 for ietf-ldup-bks; Thu, 16 Apr 1998 20:50:20 -0700 (PDT) Received: from novell.com (prv-mail25.Provo.Novell.COM [137.65.40.3]) by mail.proper.com (8.8.8/8.7.3) with SMTP id UAA21926 for ; Thu, 16 Apr 1998 20:50:19 -0700 (PDT) Received: from INET-PRV1-Message_Server by novell.com with Novell_GroupWise; Thu, 16 Apr 1998 21:50:32 -0600 Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Thu, 16 Apr 1998 21:50:00 -0600 From: "Russel Weiser" To: merrells@netscape.com, Sanjay.Jain@software.com Cc: ietf-ldup@imc.org Subject: Re: Requirements Categorisation Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: owner-ietf-ldup@imc.org Precedence: bulk John=20 1 ) I think we should at least all agree on how the architecture should work with all aspects of oneway/twoway/incremental, comsumer/suppli= er then we can implements subsets. 2) As far as transactions are concerned I agree with you on how it should = work but will have to fully understand the new transaction draft and its = impact here. If you asked me I'm sorry if I missed responding to you.=20 3) ACLs should be in there, I believe that authorization should cover = that but I'm sure it should be made more clearly. =20 cheers=20 RFW=20 >>> "John Merrells" 04/16 6:48 PM >>> Sanjay Jain wrote: > > > > B) ----------- Replication Protocol ----------- > > > > 13.2) MUST allow initiator to determine if it is a supplier or = consumer. > > Should it be specified in the replication agreement or should it be > determined at the replication updates exchange time ? I believe that the Replication Agreement should specify this. But, I = don'tthink an architecture should have to implement all the combinations of: one-way/two-way, full/incremental update, and consumer/supplier. > > 23) SHOULD support transactions. > > What does that mean ? Does it mean that either all replication updates = are > applied at the consumer site or none ? I asked about this, but haven't received a response. My interpretation is = that if we support transactions, then we must faithfully repliciate each = transaction as a transaction. > Have we covered somewhere the requirement that the relevant meta > information e.g. relevant ACLs should also be transfered from the = supplier > to the consumer ? There is no mention of access control in the requirements. I think we = should have a statement in there regarding this. Part of the Replication Session initiation should include some handshaking about what access control = models are supported. An administrator may wish to only allow replciation to = occur with foreign servers which can apply that administrators access control = policy. John -- John Merrells Netscape Communications Directory Server Software Engineer http://people.netscape.com/merrells=20 From owner-ietf-ldup Thu Apr 16 23:45:50 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id XAA01039 for ietf-ldup-bks; Thu, 16 Apr 1998 23:45:50 -0700 (PDT) Received: from mail.telstra.com.au (mail.telstra.com.au [192.148.160.16]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id XAA01035 for ; Thu, 16 Apr 1998 23:45:47 -0700 (PDT) Received: (from uucp@localhost) by mail.telstra.com.au (8.8.2/8.6.9) id QAA16730; Fri, 17 Apr 1998 16:42:40 +1000 (EST) Received: from UNKNOWN(192.111.105.145), claiming to be "odin.trl.OZ.AU" via SMTP by mail.telstra.com.au, id smtpd016618; Fri Apr 17 16:42:12 1998 Received: (from slegg@localhost) by odin.trl.OZ.AU (8.6.9/8.6.12) id QAA04201; Fri, 17 Apr 1998 16:42:01 +1000 From: Steven Legg Message-Id: <199804170642.QAA04201@odin.trl.OZ.AU> Subject: Proposed specification for multimaster replication To: ietf-ldup@imc.org Date: Fri, 17 Apr 1998 16:41:57 +1000 (EST) Cc: jstrassn@coyotes.cisco.com, capple@master.control.att.com X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk All, >LDUP-ers, > >attached are the preliminary minutes of the LDUP meeting in LA. If you have >any comments, please send them to Chris or myself by April 17. Telstra Corporation Ltd has been working on a proposal for multi-master replication for LDAP which we would like to enter into the discussion. Telstra is the leading telecommunications service provider in Australia and is a supplier of high-end LDAP/X.500 directory servers. We have been working in this area for many years. Our proposal is relatively mature having been reviewed by a number of independent parties, and has been subjected to extensive computer simulation running a wide variety of replication tests across many different server topoologies and modification patterns. However, an actual implementation is not yet available. Our design goals were - efficient, simple implementation with low overheads - no permanent inconsistency in the distributed database - simple localized (two-party) replication agreements - no restrictions on network topology - continuing operation despite single or multiple server failure - ability to operate in various modes: multi-master, master-slave, or contingency mastering (master-slave with reconfigurable mastership). We will be posting the proposal to this mailing list in the next few days. We would like to participate in the discussion on requirements, the review of candidate architectures, and any 'bake-off' that takes place. We will find it difficult to attend meetings (being based in Australia), but will participate to the fullest extent possible for us. Steven Legg (s.legg@trl.oz.au) for Directories Team Telstra Research Laboratories From owner-ietf-ldup Sun Apr 19 22:46:15 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id WAA29704 for ietf-ldup-bks; Sun, 19 Apr 1998 22:46:15 -0700 (PDT) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id WAA29687 for ; Sun, 19 Apr 1998 22:46:11 -0700 (PDT) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <27KGXZQ6>; Mon, 20 Apr 1998 15:37:23 +1000 Message-ID: From: Alan Lloyd To: ietf-ldup@imc.org, ldup-repl@external.cicso.com Cc: ldup-repl@external.cicso.com, internet-drafts@ietf.org Subject: Comments on ldup-replica-req-00.txt Date: Mon, 20 Apr 1998 15:37:22 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ietf-ldup@imc.org Precedence: bulk Dear All Just some observations - re the replication model. It seems from the requirements text that the client software replicates by reading one server and then passing that to another. In X.500 replicas are implied in the replicated system on the fact they have rxd the data by DISP (a totally different protocol to the access protocols). Therefore it is the DSA that determines the entry information context be it a master or a replica. With LDAP doing updates on behalf of replication operations - is the client software now responsible for marking the data as a replica before it is sent to the replicated server. How is this done? Do we need more labels and/or attribute options in the schema documents to say that each attribute is a replica or not? In multimaster mode, information will have to mastered in both - so now the client software will have to know this if it replicating to a multi master. or not In transferring many objects/entries over LDAP the connection may fail so a recovery point is needed. X.500 DISP is an atomic operation and implementations must ensure that a single DISP pdu works or does not. In the LDAP case - what are the recovery steps - are DIT locking mechanisms required. ie. If the master has added parts and then deleted others - and this is sent to the replica via LDAP , the adds could get applied and the deletes not. (as per 4.1.1 bullet 6.) Also DAP has a control which can select master or copy information. Will this be added to LDAP. Is the LDAP for replication protocol likely to be employed between servers in a bi- directional fashion to deal with replication or will the replication be performed as a free standing client? In the first case looping may happen in multimasters unless attribute value checking is done . In both cases client or recipient has to apply copy flags and deal with atomicity and recovery. I am not sure how this will work given the previous debates re transactions, object paradigms, resource locking and conflicts with persistent searches (which can be used in replication for incremental updates on change). Are there issues with replica - incomplete entries regards alan From owner-ietf-ldup Mon Apr 20 10:46:00 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id KAA17427 for ietf-ldup-bks; Mon, 20 Apr 1998 10:46:00 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id KAA17423 for ; Mon, 20 Apr 1998 10:45:42 -0700 (PDT) Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id KAA22336 for ; Mon, 20 Apr 1998 10:46:18 -0700 (PDT) Received: from netscape.com ([208.12.63.187]) by tintin.mcom.com (Netscape Messaging Server 3.52) with ESMTP id AAA3AF2; Mon, 20 Apr 1998 10:46:17 -0700 Message-ID: <353B89B6.D071B325@netscape.com> Date: Mon, 20 Apr 1998 10:45:26 -0700 From: "John Merrells" Organization: Netscape Communications X-Mailer: Mozilla 4.04 [en]C-NSCP (WinNT; I) MIME-Version: 1.0 To: Alan Lloyd CC: ietf-ldup@imc.org, ldup-repl@external.cicso.com, internet-drafts@ietf.org Subject: Re: Comments on ldup-replica-req-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk Alan Lloyd wrote: > It seems from the requirements text that the client software replicates > by reading one server and then passing that to another. I'm not sure how you managed to derive this from the text. I see nomention of a client maintaining replica consistency between two servers. > In transferring many objects/entries over LDAP the connection may fail > so a recovery point is needed. X.500 DISP is an atomic operation and > implementations must ensure that a single DISP pdu works or does not. In > the LDAP case - what are the recovery steps - are DIT locking mechanisms > required. The architecture draft(s) will have to address this reliability issue. It couldinvolve DIT/subtree locking mechanisms, and transactions. > Also DAP has a control which can select master or copy information. Will > this be added to LDAP. No one's mentioned it so far. Somehow I doubt it. > Is the LDAP for replication protocol likely to be employed between > servers in a bi- directional fashion to deal with replication > > In the first case looping may happen in multimasters unless attribute > value checking is done . Depends if you replicate attribute values or change operations. In eithercase an increasing tag value is applied so that updates propagate no further than required. > Are there issues with replica - incomplete entries Er.. We intend to support both fractional and partial replicas. That's an entry filter, and an attribute filter. John -- John Merrells Netscape Communications Directory Server Software Engineer http://people.netscape.com/merrells From owner-ietf-ldup Mon Apr 20 16:55:21 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id QAA20773 for ietf-ldup-bks; Mon, 20 Apr 1998 16:55:21 -0700 (PDT) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id QAA20768 for ; Mon, 20 Apr 1998 16:55:11 -0700 (PDT) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <27KGXZTA>; Tue, 21 Apr 1998 09:46:22 +1000 Message-ID: From: Alan Lloyd To: "'John Merrells'" , Alan Lloyd Cc: ietf-ldup@imc.org, ldup-repl@external.cicso.com, internet-drafts@ietf.org Subject: RE: Comments on ldup-replica-req-00.txt Date: Tue, 21 Apr 1998 09:46:21 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldup@imc.org Precedence: bulk > -----Original Message----- > From: John Merrells [SMTP:merrells@netscape.com] > Sent: Tuesday, April 21, 1998 3:45 AM > To: Alan Lloyd > Cc: ietf-ldup@imc.org; ldup-repl@external.cicso.com; > internet-drafts@ietf.org > Subject: Re: Comments on ldup-replica-req-00.txt > > Alan Lloyd wrote: > > > It seems from the requirements text that the client software > replicates > > by reading one server and then passing that to another. > > I'm not sure how you managed to derive this from the text. I see > nomention of a client maintaining replica consistency between > two servers. Perhaps it was that LDAP - as a client-server ACCESS protocol that swayed me. Is LDAP now a LDRP or something (replication) and server to server operations. Does this mean changes to the LDAP RFC? You see replication needs to be initated by either server and replicas transferred in either direction so its either a bi-directional LDAP server to server with transaction control and server based management and a lot of Gods help (this is not a religious statement ;-)) OR its a third party client application controlling the replication via LDAP. I dont care which - the transaction/atomicity problems are the same. And the updates to the LDAP RFC may be needed. > > In transferring many objects/entries over LDAP the connection may > fail > > so a recovery point is needed. X.500 DISP is an atomic operation and > > implementations must ensure that a single DISP pdu works or does > not. In > > the LDAP case - what are the recovery steps - are DIT locking > mechanisms > > required. > > The architecture draft(s) will have to address this reliability issue. > It couldinvolve DIT/subtree locking mechanisms, and > transactions. > Go for it. we do ours online. without "protocol" - eg a DISP arrives we process it - all done. no additional protocol, no client app headaches, no recovery at the protocol level, etc. Naturally there is a scheduling management issue above this in case DSAs are off line at the replication time - but this is not protocol - its the management of it via utilities. The distinction must be made. Its seems that LDAP is getting more onerous with its DIT locking and transactions and exposing this into the protocol. Is it likely that X.500 DAP and DISP will be less protocol than LDAP and do more - more effectively? > > Also DAP has a control which can select master or copy information. > Will > > this be added to LDAP. > > No one's mentioned it so far. Somehow I doubt it. > But then how will I get the master entry if I need it. I may be connected to a replica server for my address book details, but would really like the military target information from the master in case its been updated in the last ten minutes and has not been propagated yet. Users must have the mechansims to get to master info - in case of inconsistencies caused by latent replica updates - See X.500 - Dont Use Copy, Copy Shall Do, its defined, it works and its useful. > > Is the LDAP for replication protocol likely to be employed between > > servers in a bi- directional fashion to deal with replication > > > > In the first case looping may happen in multimasters unless > attribute > > value checking is done . > > Depends if you replicate attribute values or change operations. In > eithercase an increasing tag value is applied so that > updates propagate no further > than required. > How do we manage these tags (in attributes?) across tens of replicas if not hundreds - or with LDAP servers that have no distribution capabilities and all servers must be replicated to each other - millions of replicated servers. On this point this is the danger of dealing with replication before distribution - simply because with distribution - the requirement for replication almost disipates and the management of it becomes a lot less - But without distribution - there is only replication and everything must be replicated to everything and then the scale and management problems hit. I just think that distribution is seen to be more difficult that replication hence the hype around replication and a lot of single directory server solutions - however, like all obstacles - they eventually arive. > > Are there issues with replica - incomplete entries > > Er.. We intend to support both fractional and partial replicas. > That's an > entry filter, and an attribute filter. Oh really - how does the server know its a partial entry or not. See X.500 Copy shall do... Alan Lloyd Manager - Strategic Development OpenDirectory www.opendirectory.com > John > > -- > John Merrells > Netscape Communications > Directory Server > Software Engineer > > http://people.netscape.com/merrells > From owner-ietf-ldup Mon Apr 20 17:22:22 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id RAA21015 for ietf-ldup-bks; Mon, 20 Apr 1998 17:22:22 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id RAA21011 for ; Mon, 20 Apr 1998 17:22:21 -0700 (PDT) Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id RAA28442 for ; Mon, 20 Apr 1998 17:23:01 -0700 (PDT) Received: from netscape.com ([208.12.63.187]) by tintin.mcom.com (Netscape Messaging Server 3.52) with ESMTP id AAAC68; Mon, 20 Apr 1998 17:23:01 -0700 Message-ID: <353BE6B0.B4F18BD3@netscape.com> Date: Mon, 20 Apr 1998 17:22:08 -0700 From: "John Merrells" Organization: Netscape Communications X-Mailer: Mozilla 4.04 [en]C-NSCP (WinNT; I) MIME-Version: 1.0 To: Alan Lloyd CC: ietf-ldup@imc.org, ldup-repl@external.cicso.com Subject: Re: Comments on ldup-replica-req-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk Alan Lloyd wrote: > > I'm not sure how you managed to derive this from the text. I see > > nomention of a client maintaining replica consistency between > > two servers. > Perhaps it was that LDAP - as a client-server ACCESS protocol > that swayed me. Is LDAP now a LDRP or something (replication) and server > to server operations. Servers can behave as clients to each other. > Does this mean changes to the LDAP RFC? Probably, in the form of new controls, and possibly extended operations. > You see replication needs to be initated by either server and > replicas transferred in either direction so its either a bi-directional > LDAP server to server with transaction control and server based > management and a lot of Gods help (this is not a religious statement > ;-)) It could be a session in each direction. > OR its a third party client application controlling the > replication via LDAP. I doubt anyone would want to implement that... unless it had someother synchronization functionality. > I dont care which - the transaction/atomicity problems are the > same. And the updates to the LDAP RFC may be needed. I should think that new controls will suffice. > Its seems that LDAP is getting more onerous with its DIT locking > and transactions and exposing this into the protocol. Is it likely that > X.500 DAP and DISP will be less protocol than LDAP and do more - more > effectively? Depends what the LDAP replication architectural proposals are like. > But then how will I get the master entry if I need it. I may be > connected to a replica server for my address book details, but would > really like the military target information from the master in case its > been updated in the last ten minutes and has not been propagated yet. > Users must have the mechansims to get to master info - in case > of inconsistencies caused by latent replica updates - > See X.500 - Dont Use Copy, Copy Shall Do, its defined, it works > and its useful. So far, no one's suggested this as a requirement. I'd wonder though... that if your application has real-time constraints then you probably don't want to store your data in some loosly consistent store. Also... if an entry is mastered by many servers... then you won't know which server holds the 'correct' value anyway. So it doesn't sound like this buys you much. > How do we manage these tags (in attributes?) across tens of > replicas if not hundreds - I'm worried that attribute value tagging might limit scalability, but amexploring a change log approach to see if a server can be limited to only knowing about the state of it's peer, rather than the entire directory server topology. How does X.500 deal with this? > Oh really - how does the server know its a partial entry or not. The replication agreements define the area of the tree to be replicated,including an entry and attribute filter. > See X.500 Copy shall do... Eh? John -- John Merrells Netscape Communications Directory Server Software Engineer http://people.netscape.com/merrells From owner-ietf-ldup Mon Apr 20 18:08:28 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id SAA21367 for ietf-ldup-bks; Mon, 20 Apr 1998 18:08:28 -0700 (PDT) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id SAA21360 for ; Mon, 20 Apr 1998 18:08:19 -0700 (PDT) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <27KGXZTT>; Tue, 21 Apr 1998 10:59:36 +1000 Message-ID: From: Alan Lloyd To: "'John Merrells'" Cc: ietf-ldup@imc.org, ldup-repl@external.cicso.com Subject: RE: Comments on ldup-replica-req-00.txt Date: Tue, 21 Apr 1998 10:59:35 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldup@imc.org Precedence: bulk Thanks John for the reply. Comments follow. > -----Original Message----- > From: John Merrells [SMTP:merrells@netscape.com] > Sent: Tuesday, April 21, 1998 10:22 AM > To: Alan Lloyd > Cc: ietf-ldup@imc.org; ldup-repl@external.cicso.com > Subject: Re: Comments on ldup-replica-req-00.txt > > Alan Lloyd wrote: > > > > I'm not sure how you managed to derive this from the text. I see > > > nomention of a client maintaining replica consistency between > > > two servers. > > Perhaps it was that LDAP - as a client-server ACCESS > protocol > > that swayed me. Is LDAP now a LDRP or something (replication) and > server > > to server operations. > > Servers can behave as clients to each other. > Of course - its just that these servers just become "normal" users of the directory that must be authenticated and if one changes the credentials of a server in one server - how does that get into the second - unless servers need to use their old credentials depending if they have replicated them or not... is this chicken and egg stuff. > > Does this mean changes to the LDAP RFC? > > Probably, in the form of new controls, and possibly extended > operations. > > > You see replication needs to be initated by either server > and > > replicas transferred in either direction so its either a > bi-directional > > LDAP server to server with transaction control and server based > > management and a lot of Gods help (this is not a religious statement > > ;-)) > > It could be a session in each direction. With God in most cases it seems to be simplex - but I realise it is bothways with LDAP :-) see above. > > OR its a third party client application controlling the > > replication via LDAP. > > I doubt anyone would want to implement that... unless it had someother > synchronization functionality. > I doubt that too - its tends to lead to lots of problems - as defined. > > I dont care which - the transaction/atomicity problems are > the > > same. And the updates to the LDAP RFC may be needed. > > I should think that new controls will suffice. > Thats a view as I would say it. Protocol fields are easy to write down . eg ip6 address is just 16 bytes - now try and deploy it and make it work as a global network. Want to ask Oracle, Ingres or Sybase about transaction locking systems and deadlock issues? > > Its seems that LDAP is getting more onerous with its DIT > locking > > and transactions and exposing this into the protocol. Is it likely > that > > X.500 DAP and DISP will be less protocol than LDAP and do more - > more > > effectively? > > Depends what the LDAP replication architectural proposals are like. If they stay like DISP there is a chance of success - : -) .. existance proof is good. > > But then how will I get the master entry if I need it. I may > be > > connected to a replica server for my address book details, but would > > really like the military target information from the master in case > its > > been updated in the last ten minutes and has not been propagated > yet. > > Users must have the mechansims to get to master info - in > case > > of inconsistencies caused by latent replica updates - > > See X.500 - Dont Use Copy, Copy Shall Do, its defined, it > works > > and its useful. > > So far, no one's suggested this as a requirement. > May I suggest a feature which......................... > I'd wonder though... that if your application has real-time > constraints then > you probably don't want to store your data in some loosly consistent > store. X.500 permits inconsistencies - but leaves the ops people to sort that out- but X.500 provides the services to always get the master entry just in case the ops people dont make it. > Also... if an entry is mastered by many servers... then you won't know > which server holds the 'correct' value anyway. So it doesn't sound > like > this buys you much. > In X.500 one does via the information being tagged as copies (internally in the DSA because it arrived via DISP) - and with the knowledge information in the replication agreements the replica DSA knows of the master - and the via DSP (distribution again - an LDAP deficiency) I can request of the replica I am connected to to go to the master via DSP to get it by specifying Dont Use Copy - all seamlessly to the user - you see replication and distribution in X.500 work together. In LDAP land all the parts arn't there yet. So replication on its own is very limited.... > > How do we manage these tags (in attributes?) across tens of > > replicas if not hundreds - > > I'm worried that attribute value tagging might limit scalability, but > amexploring a change log approach to see if a server can > be limited to > only knowing about the state of it's peer, rather than the entire > directory server topology. > > How does X.500 deal with this? > through replication agreements and using op attrs. But the distinction must be made between the replication protocol and the management of it. ie Utilities will be needed to reschedule protocol that could not work at a specific time. Utilities will be needed to consolidate DIBs that might be inconsistent, etc. The replication scaling problem is reduced with distributed directories in the first place. Replicated systems are defined for recovery/backup and or geographically distributed loading. There must be a strong desire to limit the number of masters and replicas that have high update rates. If they do, then split them in a distributed fashion under a distributed naming context. This just means the area of replication becomes manageable. I think that the replication problems that LDAP will run into to do with scale is a by-product of not having distribution. If LDAP deals with this then one can connect servers together and just replicate fractional parts of them to deal with the loading and the redundancy issue. At the moment replication is being pushed to solve a User connectivity issue - and that is unscaleable - ie all users entries in all servers and thousands of replication transaction and synchronisation issues to deal with. We took a very hard decision with DXserver in that we would crack distribution and performance issues first (and that was a hard one) because it means dealing with naming, knowledge, access controls, domain based issues and distributed system concepts AND performance of DSP interchange + search results correlation, etc. and then we dealt with replication. Many servers and DSAs have not dealt with this distribution too well - so they blast "replication" as the strong point ...But that does not scale ie. the more replication there is - the worse it gets. Then one has to ask why and then one is forced to deal with distribution. In closing - the replication work must define the replication information model - eg are replicas marked, what is the processing around agreements (re knowledge of master/copies) - what are the protocol issues re atomicity of the transfer - and then the utilities needed to make sure there is system robustness and management. as said - just dealing with protocol in a large sacle system design can be a non event. regards alan > > Oh really - how does the server know its a partial entry or > not. > > The replication agreements define the area of the tree to be > replicated,including an entry and attribute filter. > > > See X.500 Copy shall do... > > Eh? See X.511. DAP - controls for acceptance of partial, replica > entries in a search response. > > > John > > -- > John Merrells > Netscape Communications > Directory Server > Software Engineer > > http://people.netscape.com/merrells > From owner-ietf-ldup Tue Apr 21 11:56:14 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA13613 for ietf-ldup-bks; Tue, 21 Apr 1998 11:56:14 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id LAA13609 for ; Tue, 21 Apr 1998 11:56:13 -0700 (PDT) Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id LAA07365 for ; Tue, 21 Apr 1998 11:56:54 -0700 (PDT) Received: from netscape.com ([208.12.63.187]) by tintin.mcom.com (Netscape Messaging Server 3.52) with ESMTP id AAA7B6; Tue, 21 Apr 1998 11:56:54 -0700 Message-ID: <353CEBC0.AC3B8E84@netscape.com> Date: Tue, 21 Apr 1998 11:56:00 -0700 From: "John Merrells" Organization: Netscape Communications X-Mailer: Mozilla 4.04 [en]C-NSCP (WinNT; I) MIME-Version: 1.0 To: Alan Lloyd CC: ietf-ldup@imc.org Subject: Re: Comments on ldup-replica-req-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk Alan Lloyd wrote: > Of course - its just that these servers just become "normal" > users of the directory that must be authenticated and if one changes the > credentials of a server in one server - how does that get into the > second - unless servers need to use their old credentials depending if > they have replicated them or not... is this chicken and egg stuff. That hasn't been raised as a requirement either. An administrator's intention may indeed be to permanently or temporarily deny access to some other server. In any case, the administrators should sort it out. > > > Does this mean changes to the LDAP RFC? > > > > Probably, in the form of new controls, and possibly extended > > operations. > > > > > You see replication needs to be initated by either server > > and > > > replicas transferred in either direction so its either a > > bi-directional > > > LDAP server to server with transaction control and server based > > > management and a lot of Gods help (this is not a religious statement > > > ;-)) > > > > It could be a session in each direction. > With God in most cases it seems to be simplex - but I realise it > is bothways with LDAP :-) see above. Alan, you've lost me with the God acronym. An LDAP Replication session could be implemented as one bi-directional session, or two uni-directional sessions. > Protocol fields are easy to > write down . eg ip6 address is just 16 bytes - now try and deploy it and > make it work as a global network. Um, LDAP Replication might require some extra controls to definethe start and end of a replcation session. > Want to ask Oracle, Ingres or Sybase about transaction locking > systems and deadlock issues? No, I've got a book all about it. An LDAP Replication protocol specifiction could mandate the use of transactions, but it's probably not essential that it does. > If they stay like DISP there is a chance of success - : -) .. > existance proof is good. Is that documented in X.525? Are there any documents that address using DISP for multi-master directory topologies? > > So far, no one's suggested this as a requirement. > > > May I suggest a feature which......................... Are you suggesting identifying an entry as a master/shadow as arequirement then? > > I'd wonder though... that if your application has real-time > > constraints then > > you probably don't want to store your data in some loosly consistent > > store. > X.500 permits inconsistencies - but leaves the ops people to > sort that out- but X.500 provides the services to always get the master > entry just in case the ops people dont make it. Who are ops people? 'One of the master copies', seems no better than 'One of the replica copies'. > > Also... if an entry is mastered by many servers... then you won't know > > which server holds the 'correct' value anyway. So it doesn't sound > > like > > this buys you much. > > > In X.500 one does via the information being tagged as copies > (internally in the DSA because it arrived via DISP) - and with the > knowledge information in the replication agreements the replica DSA > knows of the master - and the via DSP (distribution again - an LDAP > deficiency) I can request of the replica I am connected to to go to the > master via DSP to get it by specifying Dont Use Copy - all seamlessly to > the user - you see replication and distribution in X.500 work together. > In LDAP land all the parts arn't there yet. So replication on its own is > very limited.... I think you're missing my point. Which of the master copies is the onetrue correct copy? You'll just never know. > through replication agreements and using op attrs. > > The replication scaling problem is reduced with distributed > directories in the first place. Reduced, but not elliminated. Say you have a set of N masters for an entry.Each server maintains an increasing counter which is used to tag attribute values as they're updated. These tags are then used to determine which values are communicated to each of its peers. The question is: 'How do you avoid each server having to know the highest tag value sent from each other server?' This seems to be the big scalability problem for multi-master directories. How does X.500 solve this? John -- John Merrells Netscape Communications Directory Server Software Engineer http://people.netscape.com/merrells From owner-ietf-ldup Tue Apr 21 14:25:09 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id OAA14565 for ietf-ldup-bks; Tue, 21 Apr 1998 14:25:09 -0700 (PDT) Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.7.3) with SMTP id OAA14560 for ; Tue, 21 Apr 1998 14:25:08 -0700 (PDT) Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Tue, 21 Apr 1998 15:25:49 -0600 Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Tue, 21 Apr 1998 09:19:15 -0600 From: "Sukanta Ganguly" To: merrells@netscape.com, Sanjay.Jain@software.com Cc: ietf-ldup@imc.org Subject: Re: Requirements Categorisation Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: owner-ietf-ldup@imc.org Precedence: bulk Hi, About the Replication agreement, if the architecture does not nail = down the different possibilities i.e one-way/two-way, full/incremental = updates and consumer/supplier model, then where would these standard = approaches be specified. Also, I believe that the architecture should = clearly spell them out in detail.=20 Another, issues which hink is taken rather lightly is the transaction = implications. We have to consider the use and effect of transactioning the = replication. Furthermore, the transactions need to be incorporated within = this spec or somehow closely tied to it. It would certainly have a lot to = impose on the reliability of the system and hence cannot be considered an = after thoughts. Thanks Sukanta Ganguly >>> "John Merrells" 04/16 6:48 PM >>> Sanjay Jain wrote: > > > > B) ----------- Replication Protocol ----------- > > > > 13.2) MUST allow initiator to determine if it is a supplier or = consumer. > > Should it be specified in the replication agreement or should it be > determined at the replication updates exchange time ? I believe that the Replication Agreement should specify this. But, I = don'tthink an architecture should have to implement all the combinations of: one-way/two-way, full/incremental update, and consumer/supplier. > > 23) SHOULD support transactions. > > What does that mean ? Does it mean that either all replication updates = are > applied at the consumer site or none ? I asked about this, but haven't received a response. My interpretation is = that if we support transactions, then we must faithfully repliciate each = transaction as a transaction. > Have we covered somewhere the requirement that the relevant meta > information e.g. relevant ACLs should also be transfered from the = supplier > to the consumer ? There is no mention of access control in the requirements. I think we = should have a statement in there regarding this. Part of the Replication Session initiation should include some handshaking about what access control = models are supported. An administrator may wish to only allow replciation to = occur with foreign servers which can apply that administrators access control = policy. John -- John Merrells Netscape Communications Directory Server Software Engineer http://people.netscape.com/merrells=20 From owner-ietf-ldup Tue Apr 21 14:50:19 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id OAA14799 for ietf-ldup-bks; Tue, 21 Apr 1998 14:50:19 -0700 (PDT) Received: from inet-user-gw-1.us.oracle.com (inet-user-gw-1.us.oracle.com [192.86.155.82]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id OAA14795 for ; Tue, 21 Apr 1998 14:50:18 -0700 (PDT) Received: from mailsun2.us.oracle.com (mailsun2.us.oracle.com [144.25.88.74]) by inet-user-gw-1.us.oracle.com (8.8.5/8.8.5) with SMTP id OAA13573; Tue, 21 Apr 1998 14:48:36 -0700 (PDT) Received: by mailsun2.us.oracle.com (SMI-8.6/37.8) id OAA11675; Tue, 21 Apr 1998 14:51:19 -0700 Message-Id: <199804212151.OAA11675@mailsun2.us.oracle.com> Date: 21 Apr 98 13:49:17 -0700 From: "Uppili Srinivasan" To: alan.lloyd@OpenDirectory.com.au, owner-ietf-ldup@imc.org Subject: Re: Comments on ldup-replica-req-00.txt Cc: ietf-ldup@imc.org X-Orcl-Application: InterOffice Version4.1.2.10.50 MIME-Version: 1.0 X-Mailer: Oracle InterOffice (version 4.1.1.3.40) content-type: multipart/mixed; boundary="=_ORCL_19913226_0r0" Sender: owner-ietf-ldup@imc.org Precedence: bulk --=_ORCL_19913226_0r0 content-type:multipart/alternative; boundary="=_ORCL_19913226_0r1" --=_ORCL_19913226_0r1 Content-Type:text/plain; charset="us-ascii" Content-Transfer-Encoding:7bit > John wrote: > Reduced, but not eliminated. Say you have a set of N masters for an entry.Each server maintains an > increasing counter which is > used to tag attribute > values as they're updated. These tags are then used to determine which > values are communicated to each of its peers. The question is: 'How do > you avoid each server having to know the highest tag value sent from > each other server?' This seems to be the big scalability problem for > multi-master directories. How does X.500 solve this? John: Why will each server maintain "its own" increasing counter for each attribute. If you mean the attribute version numbers, then there ought to be a systemwide version number for each attribute. The job of the conflict resolution policy should be to ensure systemwide convergence towards the same image of all items (attributes). A potential picture is: - When an entry is created all attributes start with version 1 - If the same entry (DN being the same) is created in multiple places, only one of the entries (in its entirety) would win based on the enterprise CR policy (could be time stamp). So all attributes will start with version 1 on all servers - If two servers update the same attribute from version n to version n+1 then again CR policy would have to ensure that only one of the updates win (again possibly based on timestamps). So the system would converge to version n+1 for this attribute to value associated with the winner above. can you explain the scalability problem here? -Uppili Srinivasan ____________________________________________________________________________ Oracle Corporation | Box 659510 |Phone: (650)506-3039 Internet: usriniva@us.oracle.com 500 Oracle Pkwy |Fax: (650)506-7122 Redwood Shores |X.400: c=us; a=telemail; p=oracle; o=oragate; s=usriniva CA 94065 | ___________________|________________________________________________________ --=_ORCL_19913226_0r1 Content-Type:application/x-compressed-rtf Content-Transfer-Encoding:base64 jQUAAAQKAABMWkZ1EpCs4/8ACgEPAhUCpAPkBesCgwBQEwNUAgBjaArAc2V07jIGAAbDAoMy BEcIVQeyrQKDMwRGEZcxE480FK+JFb9mNRbocHJxF/8cZjYDxRmjEiJzdGW6bQKAfQqACM8J 2TsdUvwyNRkQHb8Jqx7BAoAKgYMNsQtgbmcxMDMUkOELA2xpMTgN8AUQIpIDC1US8XMxNyA+ IGhKb2gDoHcDYBwwOu8KhwtkGREL8mMN4CQBC0abFJEL8DMH8AmAdWMJgFAsIGJ1BUBuJKAg KmUicG0LgGEcMGQuUQYBeSB5CGAgEcB2EGUgYSAR8SBvZt0HsCAAwBwhEeAgAhAFwIMDkQnw dHJ5LkUA0PpoKkFyKgAFwADAC4ABkL8LgAQgA5EkEAuABQBlKvBpC4BnIAWgdQIwE+F3vGhp LFEEAAqFJBB1EfDQZCB0bzBgYS5wKQDVK/BpKCFlL5d2B0AKUIMtcQQgdGhleScdYMkwEHBk KQQgVDKwEfD/MJItcTLxMqEDoDAmDbArET8o0SoQLxMxfzLxBaBtbX8usC8wKQIwYi4gLFEq kWl6dAQgcAngEeApQDPBIDJxMjF0aQIgL2E6IMgnSG8H4GRvL5cpovkp8G9pMFA4syyFKeEu Uj0wcWsoYAfgMqEp0Gln/zPRBUAwojIDKkECMCtQA2GfL5c4tDKhBcAshD8nM6LfBAAqQRxA MoEwgGI0kygQvz6QKkA4IAtgQ2AicHQpgH0ZwG8CYBxAK1IvlzfgbK06YC0q5DVwaR1gYzBw GwiBObEgOwQHkVguNXowJmBzBvAqATKgBAA/zwqFCoUkMjrQV2gpgAPwzmwDIDyaLPYgIjky OxD8biIt3xPhK2I4szDnM5H+SSqgKaIHgAORPkIw5zHw8yshOnJudQbQKyEoADSz/0EiKhAI YD6gPuFC0yoxHBO/A/ANsFDNTd9O4zniakSA9yqCPkIFoG4hgC8wBUAdYHdIQSgwOnJwBvAv MCmAc/poCGBsMFBC8jiRAIAIcO8/gVOIV1EssWcJ8CfQMGHudwsRMoMqQGEHgEygAMC/W1Aq ggdAAyA5MEKCKDDn9HMpM5FBWIEcMAIwBzHfOWBXoVoCOrJJVi1KITTR/yumL2EugC4ROEJd Ul4IKkDfAZAAIEphMqBQxzFgd08x81w3YYQoRCrAQvA9g1xF/ilh2kvhRaMLUCoQC1En0PtR sQIgbCmAAiBdAz5CK9L/RvFd4EvhOTJfMh1gRDBnkO53WSMD8AOgYirwMEE6gZ9qZQSQGcAE ACoQQ1JYhp4oLpFZRQdxY3JtcF6i/lMwgGKdSnNjj2SRbTJdUv8shC+GZTRsQHOmMxVcKFA4 7wNSUMgwYlDXKxnwNLMwsP9L0m5obEQp41moMqApAGmf/zMkcYIDoF3weYNYkAQQMSD/acFs 6AdycAJek3CBXDMcE/9sNVr2eC4rYkiiUCl4Mj9T+yrwSEBjBzA4QmPjPkJsoe818CuBBuAq AC5I/DggA6D5KaJleAtTXCRDv0TAUkKOPyVfJmBI/C1VcF+g/yJwBgAFEAMAMgBccAOgCoV+ X44/j0+QX5FvkeVJVk/+cgDQaPEIUG3wBbApADpyAnxgV0JveCA2NZw5NSHQM6CV5XxQWRBL NfA60CiVgDApSAA21C0zIeA5leFJLsI18K50YEEwII0kQDAgLpQhPZOhLjexYFdIApN1UGvG dymAlkJGYXhgQZbo+DcxMhIgSVYnkWxABHDfBgBZEFfhliRH4DRIEDrQ1GM9MCA7KiA9HDBE obcLcAJwOWA9mWSfkG+ggnd5gBwwn5Bzn2GNJGBXQ/1e4DmfAJWAleeWUWBXke/9pOB8pO+n D6gfkqRJVqmIL0j8Iy0KhRyBAK0w --=_ORCL_19913226_0r1-- --=_ORCL_19913226_0r0 content-type:message/rfc822 Date: 21 Apr 98 11:56:00 From:"John Merrells" To:Alan Lloyd Subject:Re: Comments on ldup-replica-req-00.txt Cc:ietf-ldup@imc.org Return-Path: Received:from mailsun2.us.oracle.com by mailsun3 with SMTP (SMI-8.6/37.9) id MAA29465; Tue, 21 Apr 1998 12:08:03 -0700 Received:from inet-user-gw-1.us.oracle.com by mailsun2.us.oracle.com with ESMTP (SMI-8.6/37.8) id MAA11159; Tue, 21 Apr 1998 12:07:57 -0700 Received:from mail.proper.com (mail.proper.com [206.86.127.224]) by inet-user-gw-1.us.oracle.com (8.8.5/8.8.5) with ESMTP id MAA00224 for ; Tue, 21 Apr 1998 12:05:01 -0700 (PDT) Received:(from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA13613 for ietf-ldup-bks; Tue, 21 Apr 1998 11:56:14 -0700 (PDT) Received:from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id LAA13609 for ; Tue, 21 Apr 1998 11:56:13 -0700 (PDT) Received:from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id LAA07365 for ; Tue, 21 Apr 1998 11:56:54 -0700 (PDT) Received:from netscape.com ([208.12.63.187]) by tintin.mcom.com (Netscape Messaging Server 3.52) with ESMTP id AAA7B6; Tue, 21 Apr 1998 11:56:54 -0700 Message-ID:<353CEBC0.AC3B8E84@netscape.com> Organization:Netscape Communications References: Sender:owner-ietf-ldup@imc.org Precedence: bulk MIME-Version: 1.0 Content-Type:text/plain; charset=us-ascii Content-Transfer-Encoding:7bit Alan Lloyd wrote: > Of course - its just that these servers just become "normal" > users of the directory that must be authenticated and if one changes the > credentials of a server in one server - how does that get into the > second - unless servers need to use their old credentials depending if > they have replicated them or not... is this chicken and egg stuff. That hasn't been raised as a requirement either. An administrator's intention may indeed be to permanently or temporarily deny access to some other server. In any case, the administrators should sort it out. > > > Does this mean changes to the LDAP RFC? > > > > Probably, in the form of new controls, and possibly extended > > operations. > > > > > You see replication needs to be initated by either server > > and > > > replicas transferred in either direction so its either a > > bi-directional > > > LDAP server to server with transaction control and server based > > > management and a lot of Gods help (this is not a religious statement > > > ;-)) > > > > It could be a session in each direction. > With God in most cases it seems to be simplex - but I realise it > is bothways with LDAP :-) see above. Alan, you've lost me with the God acronym. An LDAP Replication session could be implemented as one bi-directional session, or two uni-directional sessions. > Protocol fields are easy to > write down . eg ip6 address is just 16 bytes - now try and deploy it and > make it work as a global network. Um, LDAP Replication might require some extra controls to definethe start and end of a replcation session. > Want to ask Oracle, Ingres or Sybase about transaction locking > systems and deadlock issues? No, I've got a book all about it. An LDAP Replication protocol specifiction could mandate the use of transactions, but it's probably not essential that it does. > If they stay like DISP there is a chance of success - : -) .. > existance proof is good. Is that documented in X.525? Are there any documents that address using DISP for multi-master directory topologies? > > So far, no one's suggested this as a requirement. > > > May I suggest a feature which......................... Are you suggesting identifying an entry as a master/shadow as arequirement then? > > I'd wonder though... that if your application has real-time > > constraints then > > you probably don't want to store your data in some loosly consistent > > store. > X.500 permits inconsistencies - but leaves the ops people to > sort that out- but X.500 provides the services to always get the master > entry just in case the ops people dont make it. Who are ops people? 'One of the master copies', seems no better than 'One of the replica copies'. > > Also... if an entry is mastered by many servers... then you won't know > > which server holds the 'correct' value anyway. So it doesn't sound > > like > > this buys you much. > > > In X.500 one does via the information being tagged as copies > (internally in the DSA because it arrived via DISP) - and with the > knowledge information in the replication agreements the replica DSA > knows of the master - and the via DSP (distribution again - an LDAP > deficiency) I can request of the replica I am connected to to go to the > master via DSP to get it by specifying Dont Use Copy - all seamlessly to > the user - you see replication and distribution in X.500 work together. > In LDAP land all the parts arn't there yet. So replication on its own is > very limited.... I think you're missing my point. Which of the master copies is the onetrue correct copy? You'll just never know. > through replication agreements and using op attrs. > > The replication scaling problem is reduced with distributed > directories in the first place. Reduced, but not elliminated. Say you have a set of N masters for an entry.Each server maintains an increasing counter which is used to tag attribute values as they're updated. These tags are then used to determine which values are communicated to each of its peers. The question is: 'How do you avoid each server having to know the highest tag value sent from each other server?' This seems to be the big scalability problem for multi-master directories. How does X.500 solve this? John -- John Merrells Netscape Communications Directory Server Software Engineer http://people.netscape.com/merrells --=_ORCL_19913226_0r0-- From owner-ietf-ldup Tue Apr 21 15:06:20 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id PAA15051 for ietf-ldup-bks; Tue, 21 Apr 1998 15:06:20 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id PAA15047; Tue, 21 Apr 1998 15:06:19 -0700 (PDT) Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id PAA20325; Tue, 21 Apr 1998 15:06:59 -0700 (PDT) Received: from netscape.com ([208.12.63.187]) by tintin.mcom.com (Netscape Messaging Server 3.52) with ESMTP id AAA2BCC; Tue, 21 Apr 1998 15:06:58 -0700 Message-ID: <353D184A.9D73DFB1@netscape.com> Date: Tue, 21 Apr 1998 15:06:02 -0700 From: "John Merrells" Organization: Netscape Communications X-Mailer: Mozilla 4.04 [en]C-NSCP (WinNT; I) MIME-Version: 1.0 To: Uppili Srinivasan CC: alan.lloyd@OpenDirectory.com.au, owner-ietf-ldup@imc.org, ietf-ldup@imc.org Subject: Re: Comments on ldup-replica-req-00.txt References: <199804212151.OAA11675@mailsun2.us.oracle.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk Uppili Srinivasan wrote: > John: Why will each server maintain "its own" increasing counter for each > attribute. This is the model I believe that the Bayou project uses. Each write is assigned a number from a server specific counter. Each server then keeps track of the latest update it has received from every server in the set of master servers. This is done to avoid writes being replayed to servers which don't need them. The salability problem is that each server needs to know about every other server. I'd hope there was a solution which did away with this. The below is not actually what I meant. I guess I must have stumbled on an overloaded term. It is interesting though, as I believe this is the conflict resolution policy used by Exchange, and was proposed by Chris Weiser & John Strassner in their multi-master draft. I think this mechanism is opposed be those who believe 'most-written-wins' isn't a desirable policy. John > If you mean the attribute version numbers, then there ought to > be a systemwide version number for each attribute. The job of the conflict > resolution policy should be to ensure systemwide convergence towards the > same image of all items (attributes). A potential picture is: > - When an entry is created all attributes start with version 1 > - If the same entry (DN being the same) is created in multiple places, only > one of the entries (in its entirety) would win based on the enterprise CR > policy (could be time stamp). So all attributes will start with version 1 > on all servers > - If two servers update the same attribute from version n to version n+1 > then again CR policy would have to ensure that only one of the updates win > (again possibly based on timestamps). So the system would converge to > version n+1 for this attribute to value associated with the winner above. > > can you explain the scalability problem here? > > -Uppili Srinivasan > ____________________________________________________________________________ > Oracle Corporation | > Box 659510 |Phone: (650)506-3039 Internet: usriniva@us.oracle.com > > 500 Oracle Pkwy |Fax: (650)506-7122 > Redwood Shores |X.400: c=us; a=telemail; p=oracle; o=oragate; s=usriniva > > CA 94065 | > ___________________|________________________________________________________ > > > > > -------------------------------------------------------------------------------------------------------------------------------- > > Subject: Re: Comments on ldup-replica-req-00.txt > Date: 21 Apr 98 11:56:00 > From: "John Merrells" > Organization: Netscape Communications > To: Alan Lloyd > CC: ietf-ldup@imc.org > References: > > Alan Lloyd wrote: > > > Of course - its just that these servers just become "normal" > > users of the directory that must be authenticated and if one changes the > > credentials of a server in one server - how does that get into the > > second - unless servers need to use their old credentials depending if > > they have replicated them or not... is this chicken and egg stuff. > > That hasn't been raised as a requirement either. An administrator's > intention may indeed be to permanently or temporarily deny access to > some other server. In any case, the administrators should sort it out. > > > > > Does this mean changes to the LDAP RFC? > > > > > > Probably, in the form of new controls, and possibly extended > > > operations. > > > > > > > You see replication needs to be initated by either server > > > and > > > > replicas transferred in either direction so its either a > > > bi-directional > > > > LDAP server to server with transaction control and server based > > > > management and a lot of Gods help (this is not a religious statement > > > > ;-)) > > > > > > It could be a session in each direction. > > With God in most cases it seems to be simplex - but I realise it > > is bothways with LDAP :-) see above. > > Alan, you've lost me with the God acronym. > > An LDAP Replication session could be implemented as one bi-directional > session, or two uni-directional sessions. > > > Protocol fields are easy to > > write down . eg ip6 address is just 16 bytes - now try and deploy it and > > make it work as a global network. > > Um, LDAP Replication might require some extra controls to definethe start > and end of a replcation session. > > > Want to ask Oracle, Ingres or Sybase about transaction locking > > systems and deadlock issues? > > No, I've got a book all about it. > > An LDAP Replication protocol specifiction could mandate the use of > transactions, but it's probably not essential that it does. > > > If they stay like DISP there is a chance of success - : -) .. > > existance proof is good. > > Is that documented in X.525? > > Are there any documents that address using DISP for multi-master > directory topologies? > > > > So far, no one's suggested this as a requirement. > > > > > May I suggest a feature which......................... > > Are you suggesting identifying an entry as a master/shadow as arequirement > then? > > > > I'd wonder though... that if your application has real-time > > > constraints then > > > you probably don't want to store your data in some loosly consistent > > > store. > > X.500 permits inconsistencies - but leaves the ops people to > > sort that out- but X.500 provides the services to always get the master > > entry just in case the ops people dont make it. > > Who are ops people? > > 'One of the master copies', seems no better than 'One of the replica copies'. > > > > Also... if an entry is mastered by many servers... then you won't know > > > which server holds the 'correct' value anyway. So it doesn't sound > > > like > > > this buys you much. > > > > > In X.500 one does via the information being tagged as copies > > (internally in the DSA because it arrived via DISP) - and with the > > knowledge information in the replication agreements the replica DSA > > knows of the master - and the via DSP (distribution again - an LDAP > > deficiency) I can request of the replica I am connected to to go to the > > master via DSP to get it by specifying Dont Use Copy - all seamlessly to > > the user - you see replication and distribution in X.500 work together. > > In LDAP land all the parts arn't there yet. So replication on its own is > > very limited.... > > I think you're missing my point. Which of the master copies is the onetrue > correct copy? You'll just never know. > > > through replication agreements and using op attrs. > > > > The replication scaling problem is reduced with distributed > > directories in the first place. > > Reduced, but not elliminated. Say you have a set of N masters for an > entry.Each server maintains an increasing counter which is > used to tag attribute > values as they're updated. These tags are then used to determine which > values are communicated to each of its peers. The question is: 'How do > you avoid each server having to know the highest tag value sent from > each other server?' This seems to be the big scalability problem for > multi-master directories. How does X.500 solve this? > > John > > -- > John Merrells > Netscape Communications > Directory Server > Software Engineer > > http://people.netscape.com/merrells -- John Merrells Netscape Communications Directory Server Software Engineer http://people.netscape.com/merrells From owner-ietf-ldup Tue Apr 21 16:01:58 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id QAA15535 for ietf-ldup-bks; Tue, 21 Apr 1998 16:01:58 -0700 (PDT) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id QAA15531 for ; Tue, 21 Apr 1998 16:01:46 -0700 (PDT) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <27KGXZWJ>; Wed, 22 Apr 1998 08:53:04 +1000 Message-ID: From: Alan Lloyd To: "'John Merrells'" Cc: ietf-ldup@imc.org Subject: RE: Comments on ldup-replica-req-00.txt Date: Wed, 22 Apr 1998 08:53:02 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldup@imc.org Precedence: bulk John - first I apologise for my sad humour - I have been told by many that it needs some attention. :-({ > -----Original Message----- > From: John Merrells [SMTP:merrells@netscape.com] > Sent: Wednesday, April 22, 1998 4:56 AM > To: Alan Lloyd > Cc: ietf-ldup@imc.org > Subject: Re: Comments on ldup-replica-req-00.txt > > Alan Lloyd wrote: > > > Of course - its just that these servers just become "normal" > > users of the directory that must be authenticated and if one changes > the > > credentials of a server in one server - how does that get into the > > second - unless servers need to use their old credentials depending > if > > they have replicated them or not... is this chicken and egg stuff. > > That hasn't been raised as a requirement either. An administrator's > intention may indeed be to permanently or temporarily deny access to > some other server. In any case, the administrators should sort it > out. > Thats good but the point should go in the spec. > > > > Does this mean changes to the LDAP RFC? > > > > > > Probably, in the form of new controls, and possibly extended > > > operations. > > > > > > > You see replication needs to be initated by either > server > > > and > > > > replicas transferred in either direction so its either a > > > bi-directional > > > > LDAP server to server with transaction control and server based > > > > management and a lot of Gods help (this is not a religious > statement > > > > ;-)) > > > > > > It could be a session in each direction. > > With God in most cases it seems to be simplex - but I > realise it > > is bothways with LDAP :-) see above. > > Alan, you've lost me with the God acronym. > Its not an an acronym - and I pray for forgiveness :-( > An LDAP Replication session could be implemented as one bi-directional > session, or two uni-directional sessions. > > > Protocol fields are easy to > > write down . eg ip6 address is just 16 bytes - now try and deploy it > and > > make it work as a global network. > > Um, LDAP Replication might require some extra controls to definethe > start and end of a replcation session. > Well yes that is one way - but may I suggest that if one starts with a wooded wheel to build a car - the rest of the car will get worse not better. This is not meant to be blunt again - but. perhaps LDAP replication is not the right thing to do - because it now needs a lot more on top of it to make it work for replication. One is starting with the tool. ie. to drill a hole I dont use a saw. replication requires a protocol which can be processed (or pre processed) in one lump to see if it can be applied before it is applied. Perhaps LDAP "transactions" can do that - but we will see. > > Want to ask Oracle, Ingres or Sybase about transaction > locking > > systems and deadlock issues? > > No, I've got a book all about it. teriffic! > An LDAP Replication protocol specifiction could mandate the use of > transactions, but it's probably not essential that it does. > > > If they stay like DISP there is a chance of success - : -) > .. > > existance proof is good. > > Is that documented in X.525? DISP specification is - the success parts are usually in product specs. > Are there any documents that address using DISP for multi-master > directory topologies? > well there a few papers and the discusion is still open. Multi master again has taken (or bagged) a few issues including the areas about split entries and that global backbone stuff I did. At the lowest level multi mastering can be easily achieved with the protocols exitsing (DISP) or DSP writethrough features with some tweaks to the processing for updates/deletes and looking for cooperative MM DSAs. Not really rocket science that one. Split entry issues do require some changes to the search results correlation processing and may be some tweaking to "base object" start points based on preconfiguration - as one would want to target the search range more effectively for split entry responses. Thats tuning Global Backbone issues as described in the paper - ie. addmd and prdmd require some radical changes to search algorithms and "modes" of working processing + plus of course the ability to deal with split subordination and multi homing on superiors and some trace info upgrades as defined > > > So far, no one's suggested this as a requirement. > > > > > May I suggest a feature which......................... > > Are you suggesting identifying an entry as a master/shadow as > arequirement then? > Yes - otherwise X.500 will have the advantage or be different. > > > I'd wonder though... that if your application has real-time > > > constraints then > > > you probably don't want to store your data in some loosly > consistent > > > store. > > X.500 permits inconsistencies - but leaves the ops people to > > sort that out- but X.500 provides the services to always get the > master > > entry just in case the ops people dont make it. > > Who are ops people? > Those are the guys that design systems and run them from an operational perspective to provide a service "Operational support staff". > 'One of the master copies', seems no better than 'One of the replica > copies'. > > > > Also... if an entry is mastered by many servers... then you won't > know > > > which server holds the 'correct' value anyway. So it doesn't > sound > > > like > > > this buys you much. > > > > > In X.500 one does via the information being tagged as copies > > (internally in the DSA because it arrived via DISP) - and with the > > knowledge information in the replication agreements the replica DSA > > knows of the master - and the via DSP (distribution again - an LDAP > > deficiency) I can request of the replica I am connected to to go to > the > > master via DSP to get it by specifying Dont Use Copy - all > seamlessly to > > the user - you see replication and distribution in X.500 work > together. > > In LDAP land all the parts arn't there yet. So replication on its > own is > > very limited.... > > I think you're missing my point. Which of the master copies is the > onetrue correct copy? You'll just never know. A master copy is that a master copy - if there is two masters its the ops people that have decided that as well as decided what are copies. ITs a system design issue that uses technology features like file systems - if the two masters have different create/modify time then that is a distinction. However, inreality users will use a copy - demand a master when required - but if there is two masters its the ops people that must say that this is the way to go and then manage the consistency of these. > > through replication agreements and using op attrs. > > > > The replication scaling problem is reduced with distributed > > directories in the first place. > > Reduced, but not elliminated. Say you have a set of N masters for an > entry.Each server maintains an increasing counter which is > used to tag attribute > values as they're updated. These tags are then used to determine > which > values are communicated to each of its peers. The question is: 'How do > you avoid each server having to know the highest tag value sent from > each other server?' This seems to be the big scalability problem for > multi-master directories. How does X.500 solve this? > see above. I think my statements re replication and distribution are correct. And one can continually hypothetically imagine replication scenarios that wont work and all sorts of mechanisms that can be used and at some point dont scale. As said I have seen a number of directory systems designed around replication only strategies - simply because I believe that the market push is "replication, replication, replication and replication - or the products used dont distribute well (in terms of performance) so that part gets left behind. Then what happens one ends up with a hundred or so replication agreements between 20 or so DSAs and if one DSA croaks - its 10 agreements that have to be switched - ie. the system design is unworkable, unscaleable and unnecessary. ie. the last thing you want is when one thing goes wrong is twelve other things that can go wrong. Back to the issue - one cannot visibly add to the schema design of a directory the tags and counters to deal with this replication issue. We are looking at systems with 10s of millions of entries in and interconnected - distributed DSAs. That level of management on the scema would make the system a mess. One has to "internally" tag schema as per X.500 to deal with copies and secondaries. One can define a transaction in LDAP controls - to bound a replication unit but so what. what happens if I bound a set of persistent searches in a transaction, what happens if i get referrals passed back within a transaction - see some controls in LDAP wont mix- are inconsistent - will confuse servers and therefore will be an operational mine field. I can only state my beliefs based on 12 years of experience with directories and 20+ with large scale system designs - using LDAP for replication just seems one is using a saw to drill a hole. The concern - LDAP will end up like a swiss army knife - lots of options - some you can use sometimes, but watch out if all the attachments fly open all at once and its in your pocket... regards alan > John > > -- > John Merrells > Netscape Communications > Directory Server > Software Engineer > > http://people.netscape.com/merrells > From owner-ietf-ldup Tue Apr 21 16:07:11 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id QAA15564 for ietf-ldup-bks; Tue, 21 Apr 1998 16:07:11 -0700 (PDT) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id QAA15560 for ; Tue, 21 Apr 1998 16:07:03 -0700 (PDT) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <27KGXZWK>; Wed, 22 Apr 1998 08:58:27 +1000 Message-ID: From: Alan Lloyd To: "'Sukanta Ganguly'" , merrells@netscape.com, Sanjay.Jain@software.com Cc: ietf-ldup@imc.org Subject: RE: Requirements Categorisation Date: Wed, 22 Apr 1998 08:58:26 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ietf-ldup@imc.org Precedence: bulk > -----Original Message----- > From: Sukanta Ganguly [SMTP:SGANGULY@novell.com] > Sent: Wednesday, April 22, 1998 1:19 AM > To: merrells@netscape.com; Sanjay.Jain@software.com > Cc: ietf-ldup@imc.org > Subject: Re: Requirements Categorisation > > Hi, > About the Replication agreement, if the architecture does not nail > down the different possibilities i.e one-way/two-way, full/incremental > updates and consumer/supplier model, then where would these standard > approaches be specified. Also, I believe that the architecture should > clearly spell them out in detail. > Perhaps everyone on this list should have a read of X.525 if they have not done that. Its not that big - 30 pages or so . and it would at least set the framework for what needed - It was put together by a lot of people that did put consiuderable effort into replication issues. > Another, issues which hink is taken rather lightly is the > transaction implications. We have to consider the use and effect of > transactioning the replication. Furthermore, the transactions need to > be incorporated within this spec or somehow closely tied to it. It > would certainly have a lot to impose on the reliability of the system > and hence cannot be considered an after thoughts. > agreed - alan > Thanks > Sukanta Ganguly > > >>> "John Merrells" 04/16 6:48 PM >>> > Sanjay Jain wrote: > > > > > > > B) ----------- Replication Protocol ----------- > > > > > > 13.2) MUST allow initiator to determine if it is a supplier or > consumer. > > > > Should it be specified in the replication agreement or should it be > > determined at the replication updates exchange time ? > > I believe that the Replication Agreement should specify this. But, I > don'tthink an architecture should have to implement all > the combinations of: > one-way/two-way, full/incremental update, and consumer/supplier. > > > > 23) SHOULD support transactions. > > > > What does that mean ? Does it mean that either all replication > updates are > > applied at the consumer site or none ? > > I asked about this, but haven't received a response. My > interpretation is that > if we support transactions, then we must faithfully repliciate each > transaction > as a transaction. > > > Have we covered somewhere the requirement that the relevant meta > > information e.g. relevant ACLs should also be transfered from the > supplier > > to the consumer ? > > There is no mention of access control in the requirements. I think we > should > have a statement in there regarding this. Part of the Replication > Session > initiation should include some handshaking about what access control > models > are supported. An administrator may wish to only allow replciation to > occur > with foreign servers which can apply that administrators access > control policy. > > John > > -- > John Merrells > Netscape Communications > Directory Server > Software Engineer > > http://people.netscape.com/merrells > > From owner-ietf-ldup Tue Apr 21 16:35:40 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id QAA15737 for ietf-ldup-bks; Tue, 21 Apr 1998 16:35:40 -0700 (PDT) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id QAA15732; Tue, 21 Apr 1998 16:35:31 -0700 (PDT) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <27KGXZWT>; Wed, 22 Apr 1998 09:26:54 +1000 Message-ID: From: Alan Lloyd To: "'Uppili Srinivasan'" , Alan Lloyd , owner-ietf-ldup@imc.org Cc: ietf-ldup@imc.org Subject: RE: Comments on ldup-replica-req-00.txt Date: Wed, 22 Apr 1998 09:26:53 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldup@imc.org Precedence: bulk > -----Original Message----- > From: Uppili Srinivasan [SMTP:USRINIVA@us.oracle.com] > Sent: Wednesday, April 22, 1998 6:49 AM > To: alan.lloyd@opendirectory.com.au; owner-ietf-ldup@imc.org > Cc: ietf-ldup@imc.org > Subject: Re: Comments on ldup-replica-req-00.txt > > > John wrote: > > Reduced, but not eliminated. Say you have a set of N masters for an > entry.Each server maintains an > increasing counter which is > > used to tag attribute > > values as they're updated. These tags are then used to determine > which > > values are communicated to each of its peers. The question is: 'How > do > > you avoid each server having to know the highest tag value sent from > > each other server?' This seems to be the big scalability problem > for > > multi-master directories. How does X.500 solve this? > > John: Why will each server maintain "its own" increasing counter for > each > attribute. If you mean the attribute version numbers, then there > ought to > be a systemwide version number for each attribute. The job of the > conflict > resolution policy should be to ensure systemwide convergence towards > the > same image of all items (attributes). A potential picture is: > - When an entry is created all attributes start with version 1 > - If the same entry (DN being the same) is created in multiple places, > only > one of the entries (in its entirety) would win based on the enterprise > CR > policy (could be time stamp). So all attributes will start with > version 1 > on all servers > - If two servers update the same attribute from version n to version > n+1 > then again CR policy would have to ensure that only one of the updates > win > (again possibly based on timestamps). So the system would converge to > version n+1 for this attribute to value associated with the winner > above. > > can you explain the scalability problem here? > Yes I would love to but that would take years - I worked on multi- nodal ICL 3900 systems in the 80s - 50mb fibre optic inter connected mainframes The operating system was about 1000 time more complex than Unix and did a lot more. For instance, reservation of system resources where semaphored (locked) and this was broadcasted to other mainframes over the fiber in microseconds, similarly releases and deadlocks were dealt with in this manner. Each mainframe could be switched off and on again on the fly with full seamless recovery. The resolution rate for testing resource clashes was down in the miroseconds. That level of distributed robustness took a lot of money and a lot of engineering and glass between each node. Now imagine a 10 million entry directory system over a WAN with asymetric replicas (ie. 10 of the online DSAs replicating to a master backup) and replicas that are online and being updated and and transaction rates at 100s per second. If every DSA has a replica or two or three and an archive what will actually manage these attribute level tags/counters - how does one test they work - 100% all times, all condidtions. Switch a few DSAs off a see what happens. The more compex the information tagging and transaction mechanisms (particularly the distributed mechanisms that deal with these), the worse the recovery and system robustness becomes. Attribute tagging - if that is a solution proposed should be an internal processing issue - not an LDAP feature - simply because other types of implementations that use X.500 and RDBs as back ends as their "LDAP servers" just dont need it - or want it. And I shudder to think that every time an attribute is updated, I would have to broadcast over a the replicated system, the DN, the attribute type.value and its tag so that it could be verified and possibly superceded by a clash from one or more other places. what about time zones, transit delays, system clock resolution. Distributed - high performance DSAs seem a lot less effort and less problematic - I wonder who can supply those :-) regards alan > -Uppili Srinivasan > ______________________________________________________________________ > ______ > Oracle Corporation | > Box 659510 |Phone: (650)506-3039 Internet: > usriniva@us.oracle.com > > 500 Oracle Pkwy |Fax: (650)506-7122 > Redwood Shores |X.400: c=us; a=telemail; p=oracle; o=oragate; > s=usriniva > > CA 94065 | > ___________________|__________________________________________________ > ______ > > > > > << File: ATT00115.ATT >> << Message: Re: Comments on > ldup-replica-req-00.txt >> From owner-ietf-ldup Tue Apr 21 16:54:05 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id QAA16041 for ietf-ldup-bks; Tue, 21 Apr 1998 16:54:05 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id QAA16037; Tue, 21 Apr 1998 16:54:03 -0700 (PDT) Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id QAA08545; Tue, 21 Apr 1998 16:54:49 -0700 (PDT) Received: from netscape.com ([208.12.63.187]) by tintin.mcom.com (Netscape Messaging Server 3.52) with ESMTP id AAA3E9B; Tue, 21 Apr 1998 16:54:49 -0700 Message-ID: <353D318F.93F35E2C@netscape.com> Date: Tue, 21 Apr 1998 16:53:51 -0700 From: "John Merrells" Organization: Netscape Communications X-Mailer: Mozilla 4.05 [en]C-NSCP (WinNT; U) MIME-Version: 1.0 To: Alan Lloyd CC: "'Uppili Srinivasan'" , owner-ietf-ldup@imc.org, ietf-ldup@imc.org Subject: Re: Comments on ldup-replica-req-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk Alan Lloyd wrote: > [snip...icl anecdote] > And I shudder to think that every time an attribute is updated, > I would have to broadcast over [to] the replicated system, the DN, the > attribute type.value and its tag so that it could be verified and > possibly superceded by a clash from one or more other places. Each operation will require a different set of items to be transferredbetween servers. They'll always be a Unique Identifier for the entry, this is more likely to be a UUID than a DN. If it's a modify, as you suggest, then the attribute identifier and value must be sent. The final piece of information required will be something to aid the conflict detection and resolution policy you decide to deploy. > what about time zones, transit delays, system clock resolution. You don't have to use time in your conflict detection and resolutionpolicy. You could choose something else. Like the attribute versioning which we've just mentioned. > Distributed - high performance DSAs seem a lot less effort and > less problematic - Lovely, but customers are asking for replicated directory services. John > I wonder who can supply those :-) > > regards alan > > -Uppili Srinivasan > > ______________________________________________________________________ > > ______ > > Oracle Corporation | > > Box 659510 |Phone: (650)506-3039 Internet: > > usriniva@us.oracle.com > > > > 500 Oracle Pkwy |Fax: (650)506-7122 > > Redwood Shores |X.400: c=us; a=telemail; p=oracle; o=oragate; > > s=usriniva > > > > CA 94065 | > > ___________________|__________________________________________________ > > ______ > > > > > > > > > > << File: ATT00115.ATT >> << Message: Re: Comments on > > ldup-replica-req-00.txt >> -- John Merrells Netscape Communications Directory Server Software Engineer http://people.netscape.com/merrells From owner-ietf-ldup Tue Apr 21 18:06:22 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id SAA16545 for ietf-ldup-bks; Tue, 21 Apr 1998 18:06:22 -0700 (PDT) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id SAA16538; Tue, 21 Apr 1998 18:06:16 -0700 (PDT) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <27KGXZXC>; Wed, 22 Apr 1998 10:57:34 +1000 Message-ID: From: Alan Lloyd To: "'John Merrells'" Cc: "'Uppili Srinivasan'" , owner-ietf-ldup@imc.org, ietf-ldup@imc.org Subject: RE: Comments on ldup-replica-req-00.txt Date: Wed, 22 Apr 1998 10:57:33 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldup@imc.org Precedence: bulk Thanks john - some comments - I am sad about snipping my icl stuff - I was proud of that. :-) > -----Original Message----- > From: John Merrells [SMTP:merrells@netscape.com] > Sent: Wednesday, April 22, 1998 9:54 AM > To: Alan Lloyd > Cc: 'Uppili Srinivasan'; owner-ietf-ldup@imc.org; ietf-ldup@imc.org > Subject: Re: Comments on ldup-replica-req-00.txt > > Alan Lloyd wrote: > > > [snip...icl anecdote] > > > And I shudder to think that every time an attribute is > updated, > > I would have to broadcast over [to] the replicated system, the DN, > the > > attribute type.value and its tag so that it could be verified and > > possibly superceded by a clash from one or more other places. > > Each operation will require a different set of items to be > transferredbetween servers. They'll always be a Unique Identifier for > the entry, > this is more likely to be a UUID than a DN. If it's a modify, as you > suggest, then the attribute identifier and value must be sent. The > final piece of information required will be something to aid the > conflict detection and resolution policy you decide to deploy. > The mechanism of stating UIDs, DNs (where names are modified) and such things are easy to say and write down in an RFC - now what. operationally it will hit walls and system robustness will be demaned from high end directory systems that run banks, telephone infrastructures, CAs and online services and military applications. As said the image that a directory is a mail address book that must be replicated is still out there - and some simple tagging system may be all thats needed for these - If directories are to be a disciplined, robust infrastucture we really have to watch tagging and transaction mechanisms - If one cannot scale it and inteconnect it reliably - dont bother. > > what about time zones, transit delays, system clock > resolution. > > You don't have to use time in your conflict detection and > resolutionpolicy. You could choose something else. Like the > attribute versioning > which we've just mentioned. > and what happens if a DSA has a clock set to tomorow and its updated at the same time - differently - in the actual time + - a second, as a DSA with its clock set to today ? In the ICL system we had to update the system wide clock by 2 microseconds (over the fiber optic to all nodes ) every time a system resource was updated to ensure that one transaction could only occur at one time and be reliable - icl again - sorry. X.500 permits inconsistencies for this reason - ie clock synchronisation over the planet is hard - therefore a requirement to grab the "logical master entry" is provided in the protocol options. Can I mention here that one big issue emerging on this planet is telephone number mobility and internet QOS and dynamic service provisioning - both will need very fast operation rate distributed DSAs to work in an Intellegent Network infrastructure. In addition distributed domain based access controls will be fundamental. So the replication process really does not want to impose exponential loads on this infrastructure just trying to keep every thing consistent. regards alan > > Distributed - high performance DSAs seem a lot less effort > and > > less problematic - > > Lovely, but customers are asking for replicated directory services. > yes we know, but that IMHO is because the "directory" experts have been preaching that due to products distributed operations too well or at all (LDAP) and the LDAP theme of doing replication now. But then reality hits, as it always does - scaleability and interopration and information consistency are now comming to the fore. Its going to be an interesting world when all the "replicate hypers" suddenly realise that all they are doing is casting a system which is unscaleable by nature and when they want to eventually interconnect for distributed operations - what a mess they will be in. Distribution gets the naming and the knowledge and domain based access control policies in place (and the distributed performance issues resolved) that enable directory system scaling. Replication just provides one with a "copy" of the inteconnection and performance problems as described that have not been fixed. regards alan > John > > > > > I wonder who can supply those :-) > > > > regards alan > > > -Uppili Srinivasan > > > > ______________________________________________________________________ > > > ______ > > > Oracle Corporation | > > > Box 659510 |Phone: (650)506-3039 Internet: > > > usriniva@us.oracle.com > > > > > > 500 Oracle Pkwy |Fax: (650)506-7122 > > > Redwood Shores |X.400: c=us; a=telemail; p=oracle; o=oragate; > > > s=usriniva > > > > > > CA 94065 | > > > > ___________________|__________________________________________________ > > > ______ > > > > > > > > > > > > > > > << File: ATT00115.ATT >> << Message: Re: Comments on > > > ldup-replica-req-00.txt >> > > > > -- > John Merrells > Netscape Communications > Directory Server > Software Engineer > > http://people.netscape.com/merrells > From owner-ietf-ldup Tue Apr 21 20:26:15 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id UAA17509 for ietf-ldup-bks; Tue, 21 Apr 1998 20:26:15 -0700 (PDT) Received: from inet16.us.oracle.com (inet16.us.oracle.com [192.86.155.100]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id UAA17505 for ; Tue, 21 Apr 1998 20:26:14 -0700 (PDT) Received: from mailsun2.us.oracle.com (mailsun2.us.oracle.com [144.25.88.74]) by inet16.us.oracle.com (8.8.5/8.8.5) with SMTP id UAA10377; Tue, 21 Apr 1998 20:27:23 -0700 (PDT) Received: by mailsun2.us.oracle.com (SMI-8.6/37.8) id UAA04619; Tue, 21 Apr 1998 20:27:20 -0700 Message-Id: <199804220327.UAA04619@mailsun2.us.oracle.com> Date: 21 Apr 98 20:25:07 -0700 From: "Uppili Srinivasan" To: ietf-ldup@imc.org Subject: Re: Requirements Categorisation Cc: sganguly@novell.com X-Orcl-Application: InterOffice Version4.1.2.10.50 MIME-Version: 1.0 X-Mailer: Oracle InterOffice (version 4.1.1.3.40) content-type: multipart/alternative; boundary="=_ORCL_19927122_0r0" Sender: owner-ietf-ldup@imc.org Precedence: bulk --=_ORCL_19927122_0r0 Content-Type:text/plain; charset="us-ascii" Content-Transfer-Encoding:7bit > About the Replication agreement, if the architecture > does not nail down the different possibilities > i.e one-way/two-way, full/incremental updates and > consumer/supplier model, then where would these > standard approaches be specified. Also, I believe that the > architecture should clearly spell them out in detail. True. The architecture should spell out how the agreements should be crafted (or what agreements should exist) for the different replication scenarios. The agreement specification should in turn standardize the structures and values for defined scenarios. Right now the discussion has still not converged on requirements. -Uppili Srinivasan ____________________________________________________________________________ Oracle Corporation | Box 659510 |Phone: (650)506-3039 Internet: usriniva@us.oracle.com 500 Oracle Pkwy |Fax: (650)506-7122 Redwood Shores |X.400: c=us; a=telemail; p=oracle; o=oragate; s=usriniva CA 94065 | ___________________|________________________________________________________ --=_ORCL_19927122_0r0 Content-Type:application/x-compressed-rtf Content-Transfer-Encoding:base64 qAMAAIIGAABMWkZ1SsnMmf8ACgEPAhUCpAPkBesCgwBQEwNUAgBjaArAc2V0bjIGAAbDAoMy BEYRlzFuIAhVB7ICgzMTDxQfZiI0FUhwcnEWX2Y1OwRHFD42A8UYAxIic3R0ZW0CgH0KgAjP Cdk7+R1SMjUZcB2/CasewQKABwqBDbELYG5nMTAzwxUwCwNsaTE4DfAFEA8ikgtVFTEL8DMg PiCKQQbgdQVAdGhlB/CCZQtQaWNhdGkCIJwgYQnCB4ACMCwgBpCXJIMKwBGwaRwwY3QIcCck sAqFJBBkbweRbm/dBUBuC3ADICgQdwOgJJIaZAaQZgSQJfEgcG/5BBBpYgMQJvAIkAQgJ4cM aS4ksAIgZS13YWB5L3R3bywCJiBm8HVsbC8LgAUAJdMHQHAgdXBkJTAHkQBwZJcneAWgAIB1 B4ByLy9w7nAk8RSBBGJsJiAkkQOg/nckoCdRLGAs8C6QJJER8P8neBwgLnELESWAL/ADYADQ yTHxIGIksHNwBZAGkIkIkGQuJCBsc28mIPZJNAEwEXYksCSQJTAkgzMnhya7c2gxky8wbGW5 CsBseTQyLQAkgm0rwP8kYQuAKAASACixNNAKhQqF/FRyClA00DtQJo435Tjk/yRSN/AH4CZz JaYEIDfkCoWbNBEFAGEBgAmAICgFsUcxIDYRPn8gZXgEAHT+KSzQBbEpSwqFHWAk+ATw9wnw CsAlUHM00DvTJaY0Nm9Eljf0OdEnMW4KhTLWaXZ6NdI0IXQ7cCcjLlR2/wdAClAEIELCDbEL gEBxRQjHCocLZBlxczE3J3YLRhsXcQvyYw3gB/BpZ2jvKIE+BSmABPB1KkElYRHAPz8BJUA5 EShiL0E1wHJnx0BxJWEdYHF1aS1kTGf5CoUtVS/wKoEGAAUQAwDtSrBzA5EKhV9WH1cvWD93 WU9ZxSd2T0AwOGEaAXI3KiBAMCVDfDhACoVCb8B4IDY1OTUh0DhA2V3FfFA38CvgOkCQXWBE MCle8DYtMyHgOX1dwUkCMASREgBesC3gc7VVBEBQoC5cAThhLgWgHzlwJ3Ze8E9gW1VQa3dj OMBeIkZheGBRXsg33DEyEiAndiTQZCxgBHCPBgA38EoyXhNYLjRigKlesGM9UKA7JYA9HDDP OHAAwAMQZ3BwPWFEZ3Dab2hiZy4hZ3BzZ0FVBOFcl0NBIDlm4F1gXcfvXjFcl1nPbMB8bM9u 72//f1qEJ3ZxaDqMTP8KoxyBAAF1EA== --=_ORCL_19927122_0r0-- From owner-ietf-ldup Tue Apr 21 20:20:09 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id UAA17470 for ietf-ldup-bks; Tue, 21 Apr 1998 20:20:09 -0700 (PDT) Received: from inet16.us.oracle.com (inet16.us.oracle.com [192.86.155.100]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id UAA17466 for ; Tue, 21 Apr 1998 20:20:08 -0700 (PDT) Received: from mailsun2.us.oracle.com (mailsun2.us.oracle.com [144.25.88.74]) by inet16.us.oracle.com (8.8.5/8.8.5) with SMTP id UAA07508; Tue, 21 Apr 1998 20:21:17 -0700 (PDT) Received: by mailsun2.us.oracle.com (SMI-8.6/37.8) id UAA03520; Tue, 21 Apr 1998 20:21:17 -0700 Message-Id: <199804220321.UAA03520@mailsun2.us.oracle.com> Date: 21 Apr 98 20:08:24 -0700 From: "Uppili Srinivasan" To: alan.lloyd@OpenDirectory.com.au Subject: RE: Comments on ldup-replica-req-00.txt Cc: ietf-ldup@imc.org X-Orcl-Application: InterOffice Version4.1.2.10.50 MIME-Version: 1.0 X-Mailer: Oracle InterOffice (version 4.1.1.3.40) content-type: multipart/alternative; boundary="=_ORCL_19926856_0r0" Sender: owner-ietf-ldup@imc.org Precedence: bulk --=_ORCL_19926856_0r0 Content-Type:text/plain; charset="us-ascii" Content-Transfer-Encoding:7bit Alan wrote: > Yes I would love to but that would take years > [snip .. anecdote] > I am glad you tried nevertheless! :-) > Distributed - high performance DSAs seem a lot less effort and > less problematic - > [snip .. product pitch] You are comparing apples to oranges. It is like arguing (point to point) ftp is better than (store and forward) e-mail. This group *is* discussing directory distribution, but through *replication*. There are so many different kinds of customers and their requirements are not all the same. Many trust that replication is the most effective and reliable for their deployment needs. (Yes, I *am* talking about customers with requirements for 10000000000000000000 entries and 1000000000000 concurrent users etc. I didn't count all the zeroes :-) Could we focus on the requirements and quickly come to a resolution on what are the acceptable boundaries for discussions. Thanks! -Uppili Srinivasan ____________________________________________________________________________ Oracle Corporation | Box 659510 |Phone: (650)506-3039 Internet: usriniva@us.oracle.com 500 Oracle Pkwy |Fax: (650)506-7122 Redwood Shores |X.400: c=us; a=telemail; p=oracle; o=oragate; s=usriniva CA 94065 | ___________________|________________________________________________________ --=_ORCL_19926856_0r0 Content-Type:application/x-compressed-rtf Content-Transfer-Encoding:base64 lAQAAK4HAABMWkZ1GZhEEv8ACgEPAhUCpAPkBesCgwBQEwNUAgBjaArAc2V0bjIGAAbDAoMy BEYRlzFuIAhVB7ICgzMTDxQfZiI0FUhwcnEWX2Y1OwRHFD42A8UYAxIic3R0ZW0CgH0KgAjP Cdk7+R1SMjUZcB2/CasewQKABwqBDbELYG5nMTAzwxUwCwNsaTE4DfAFEI8ikgtVFTEL8DMg QSGR7CB3A2AcMDoKhwtkF3ErC/AS8GMN4CAKhT4gGlkHkUkkUAhgbGQgARzwdmUgdG8gYnp1 BUB0EcAFQCdUAZBrGSfgeWUR0SZYIFtzwQMAcCAuLiAAcAWQOmQkgV0mZgqFJzBhbewgZwtg J5B5CGAn8AiBjyeQKxAn0AAgaGVsB5DAcyEgOi0pCoUmZnkMgiBEBAAtYSgxLZEtgCBoaWdo IHAEkBUCEHIDgWMn4ERTQX8EIBHwHEAq8CehBUAuQiB3DcEdASrxZCZnMwMYIG/nAmAcQCiQ aWMwwSZnKncRNNFkdWMFQHBpdI8RsCuGC0YZcXMxNyZW3lktMQrAJ+AFoG0KsQuA+mcq8HAL UAeRKAEFsCGhvweQKuAnIAVABAAnoGkpQYkKwGd1OmIocG8LgOcoUSgQPSMpIAGAKrA8Eb5i EgAcMAXAKHEDoCgcIN8FsDxxM9A+EAWwdwsRPgDcZS0AwAMQO7FUMPAEIBcJwAhgKrAqBAAq IGT5BABjdQQQOmJCIB1gNyCtBbB5QhIwRGkCICwoJftBgTERKh1gC1A1YDVBAiDeKkDzBJA8 cifgcygQA4GvQ1IN0EYxPVFrC4BkBCD8b2Y58EJgKAAHgCmhP8LrLhFC4CAdYHE8wB1gB4D3 AjBI4TnRbjLRB0ADIC4R6zJALKBlO7FNRvItYEhx/yhkRSk8AksyBGBMYQ3BQwH+aSfRP8Id YCJwAaAuQD/y90k1DbALUG8GwEeSKxAJgN07oigm8UQwJzAqLKBCAP0BkGxH0TqBBuAoQUho A/D/KHBJnE/SIdBVbyZAR5EIgf9I5FVbOfExwAhwR4NCYEjCjRIAYzuyQhFkbidTMdcIYD1R SvZ6BJBvB5Eur/sIUSeBd0+yQlE7MAOgSzLHSaw/0UnBY2tsQ1A6AX8n4zKgHWBGsApATVNN cXf/KII5wksyANAx0AUwT4NTAf8z0DpBB5FP0kImAiA7oC7ce0EgAHBrLnAkzwvjJiItdlU6 sAMQaQYAOlFOwGH3S3ADoAqFX2jfae9q/2wPa2yFJlZPO1BjT6EIUHI3PSA7UE1TfCpQCoVC b8B4IDY1OTUh0CpQ8XCFfFBoAiAkoD0AcCBEMClxsDYtMyHgOf1wgUkCMASREgBxcFjhZ8Ta QEJgLjtBbkEuOgFvV8dxsCZAbhVQa3dDUHDimEZheHMRcYg3MSXw/W9XUgmAJ1AEcAYAcTBg MTFwxFguNFWAcXBjPfVCYDsq8D0cMDUSAxB6MKxwPXQEejBveyJnKJAde4FzegFnxG9XQ0Eg /jl5oHAgcIdw8W9XbI9/gP58f4+Br4K/bUQmVoQoLtwXOC8KoxyBAIfQ --=_ORCL_19926856_0r0-- From owner-ietf-ldup Tue Apr 21 21:42:12 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id VAA17906 for ietf-ldup-bks; Tue, 21 Apr 1998 21:42:12 -0700 (PDT) Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.7.3) with SMTP id VAA17902 for ; Tue, 21 Apr 1998 21:42:11 -0700 (PDT) Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Tue, 21 Apr 1998 22:42:58 -0600 Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Tue, 21 Apr 1998 22:39:30 -0600 From: "Anurag Srivastava" To: ietf-ldup@imc.org, USRINIVA@us.oracle.com Cc: SGANGULY@novell.com Subject: Re: Requirements Categorisation Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: owner-ietf-ldup@imc.org Precedence: bulk I believe that there could be a minimum set of agreement that should be = allowed to be supported by every vendor for interoperability sake. But = there should be a flexibility to add extra facility in any particular = implementation if so desired. It is proposed that this minimum set could be : Replication Agreements What type of replica is it (read only, read-write, = schema-change-allowed)=20 Whether replica is allowed to communicate its own changes to the = owner/master Multiple replication behavior (propogate its changes to other = replicas before committing to it, under conflict communicate it the latest = changes/always accept its changes,...) Synchronization Agreements Priority for change acceptance during synchronizati= on (whether requester or owner's change presides over during the conflict) Granularity of synchronization (resource/attribute/attribute value = level) Who would initiate the synchronization (whether owner initiated or = requester initiated) When the synchronization gets initiated (as soon as change = happens, periodic, # of synch. request to bundle or a combination of above = ) Thanks & regards Anurag >>> "Uppili Srinivasan" 04/22/98 08:55AM >>> > About the Replication agreement, if the architecture=20 > does not nail down the different possibilities=20 > i.e one-way/two-way, full/incremental updates and=20 > consumer/supplier model, then where would these=20 > standard approaches be specified. Also, I believe that the=20 > architecture should clearly spell them out in detail.=20 True. The architecture should spell out how the agreements should be crafted (or what agreements should exist) for the different replication scenarios. The agreement specification should in turn standardize the structures and values for defined scenarios. Right now the discussion has still not converged on requirements. -Uppili Srinivasan=20 ___________________________________________________________________________= _=20 Oracle Corporation | =20 Box 659510 |Phone: (650)506-3039 Internet: usriniva@us.oracle.co= m=20 =20 500 Oracle Pkwy |Fax: (650)506-7122 =20 Redwood Shores |X.400: c=3Dus; a=3Dtelemail; p=3Doracle; o=3Doragate; = s=3Dusriniva =20 CA 94065 | =20 ___________________|_______________________________________________________= _ =20 =20 =20 From owner-ietf-ldup Tue Apr 21 22:02:53 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id WAA17969 for ietf-ldup-bks; Tue, 21 Apr 1998 22:02:53 -0700 (PDT) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id WAA17965 for ; Tue, 21 Apr 1998 22:02:42 -0700 (PDT) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <27KGXZX8>; Wed, 22 Apr 1998 14:53:58 +1000 Message-ID: From: Alan Lloyd To: "'Uppili Srinivasan'" , Alan Lloyd Cc: ietf-ldup@imc.org Subject: RE: Comments on ldup-replica-req-00.txt Date: Wed, 22 Apr 1998 14:53:56 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldup@imc.org Precedence: bulk > -----Original Message----- > From: Uppili Srinivasan [SMTP:USRINIVA@us.oracle.com] > Sent: Wednesday, April 22, 1998 1:08 PM > To: alan.lloyd@opendirectory.com.au > Cc: ietf-ldup@imc.org > Subject: RE: Comments on ldup-replica-req-00.txt > > Alan wrote: > > > Yes I would love to but that would take years > > [snip .. anecdote] > > > I am glad you tried nevertheless! :-) > > > Distributed - high performance DSAs seem a lot less effort and > > less problematic - > > [snip .. product pitch] > > You are comparing apples to oranges. > No I am not. - sorry I do have experience with distributed and replicated systems AND there is always a requirement in online business level transaction - replicated systems, the need to get at the master entry - just in case - in most finacial and military applications some replicated inconsistencies may be accommodated, but in the real sharp end of the business they are not. > It is like arguing (point to point) > ftp is better than (store and forward) e-mail. This group *is* > discussing > directory distribution, but through *replication*. > Please dont confuse the two terms - Distribution in directory parlance is processing of transactions in a distributed namespace - distributed means there is a protocol such as DSP that does loop detection and can build fractional responses from the servers it talks to. Replication is the copying of one names space from one server to another. Quite a different meaning. X.518 is about Distribution - DSP X.525 is about Replication - DISP > There are so many > different kinds of customers and their requirements are not all the > same. > Many trust that replication is the most effective and reliable for > their > deployment needs. Agree - but given the first point above re master entry requirements - then Distribution must always be there as well particularly if WANs and batch updates are involved. > (Yes, I *am* talking about customers with requirements > for 10000000000000000000 entries and 1000000000000 concurrent users > etc. I > didn't count all the zeroes :-) > Thats good - can we have their names and contact details :-) > Could we focus on the requirements and quickly come to a resolution on > what > are the acceptable boundaries for discussions. > Agree - lets get to basics - One cannot do replication without the notion of a namespace - ie. an administrative area and possible refinements within that. Thats what replication agreements are made of. One cannot do Access Control without the notion of an administered namespace ie. an AC administrative area with overarching policies and possible refinements of that. One cannot do distribution without the notion of interconnected administrative areas. TOP LEVEL Now in replication we have master and replicated data. WE also want to identify which data is master and which is copy. We want User access protocol and services that let us select that. System level Replication agreements which are managed Protocol level Protocol for the Negotiation of agreements Protocol for the Transfer of replicas - robust - transaction based atomic - see DISP Information level - tags/uids, flags, time stamps, etc - dont standardise this - implementation dependent - unscaleable. I think that first and formost - the LDAP work should deal with administrative areas - because replication and access control will have no shape without them. X.500 defined its management model in the X.500 1993 release (operational atttrs and admin areas) just so it could solidify its replication/distribution and access control designs. Perhaps LDAP has arrived at the same point. So what do peope want to design first. regards alan > Thanks! > -Uppili Srinivasan > ______________________________________________________________________ > ______ > Oracle Corporation | > Box 659510 |Phone: (650)506-3039 Internet: > usriniva@us.oracle.com > > 500 Oracle Pkwy |Fax: (650)506-7122 > Redwood Shores |X.400: c=us; a=telemail; p=oracle; o=oragate; > s=usriniva > > CA 94065 | > ___________________|__________________________________________________ > ______ > > > > > << File: ATT00128.ATT >> From owner-ietf-ldup Wed Apr 22 09:14:36 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id JAA06398 for ietf-ldup-bks; Wed, 22 Apr 1998 09:14:36 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id JAA06394; Wed, 22 Apr 1998 09:14:36 -0700 (PDT) Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id JAA16095; Wed, 22 Apr 1998 09:15:09 -0700 (PDT) Received: from netscape.com ([208.12.63.187]) by tintin.mcom.com (Netscape Messaging Server 3.52) with ESMTP id AAA26EA; Wed, 22 Apr 1998 09:14:19 -0700 Message-ID: <353E171D.5E505CA5@netscape.com> Date: Wed, 22 Apr 1998 09:13:17 -0700 From: "John Merrells" Organization: Netscape Communications X-Mailer: Mozilla 4.05 [en]C-NSCP (WinNT; U) MIME-Version: 1.0 To: Alan Lloyd CC: "'Uppili Srinivasan'" , owner-ietf-ldup@imc.org, ietf-ldup@imc.org Subject: Re: Comments on ldup-replica-req-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk Alan Lloyd wrote: > The mechanism of stating UIDs, DNs (where names are modified) > and such things are easy to say and write down in an RFC - now what. > operationally it will hit walls and system robustness will be demaned > from high end directory systems that run banks, telephone > infrastructures, CAs and online services and military applications. How else do you replicate the change? > As said the image that a directory is a mail address book that > must be replicated is still out there - and some simple tagging system > may be all thats needed for these - We may not use tagging. > If directories are to be a disciplined, robust infrastucture we > really have to watch tagging and transaction mechanisms - If one cannot > scale it and inteconnect it reliably - dont bother. Yes, our goal is interoperability and a requirement is scalability. > and what happens if a DSA has a clock set to tomorow and its > updated at the same time - differently - in the actual time + - a > second, as a DSA with its clock set to today ? You don't have to use time for conflict resolution. > [snip... icl] > X.500 permits inconsistencies for this reason - ie clock > synchronisation over the planet is hard - therefore a requirement to > grab the "logical master entry" is provided in the protocol options. You don't have to use time for conflict resolution.There could be multiple masters, how do you know which holds theone true value. > So the replication process really does not want to impose > exponential loads on this infrastructure just trying to keep every thing > consistent. Scalable architecture is a requirement. > > Lovely, but customers are asking for replicated directory services. > > > yes we know, but that IMHO is because the "directory" experts > have been preaching that due to products distributed operations too > well or at all (LDAP) and the LDAP theme of doing replication now. But > then reality hits, as it always does - scaleability and interopration > and information consistency are now comming to the fore. > > Its going to be an interesting world when all the "replicate > hypers" suddenly realise that all they are doing is casting a system > which is unscaleable by nature and when they want to eventually > interconnect for distributed operations - what a mess they will be in. Yes, interoperability is the goal, scalability a requirement. > Distribution gets the naming and the knowledge and domain based > access control policies in place (and the distributed performance issues > resolved) that enable directory system scaling. We still need Replication and LDUP is the Replication working group. > Replication just > provides one with a "copy" of the inteconnection and performance > problems as described that have not been fixed. Customers require replicated directory services. John -- John Merrells Netscape Communications Directory Server Software Engineer http://people.netscape.com/merrells From owner-ietf-ldup Wed Apr 22 08:45:46 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id IAA06215 for ietf-ldup-bks; Wed, 22 Apr 1998 08:45:46 -0700 (PDT) Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.7.3) with SMTP id IAA06211 for ; Wed, 22 Apr 1998 08:45:44 -0700 (PDT) Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Wed, 22 Apr 1998 09:46:30 -0600 Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Wed, 22 Apr 1998 09:46:00 -0600 From: "Sukanta Ganguly" To: ietf-ldup@imc.org, SANURAG@novell.com, USRINIVA@us.oracle.com Subject: Re: Requirements Categorisation Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: owner-ietf-ldup@imc.org Precedence: bulk If all are discussions are converging to the same point, (Atleast that is = what I note from the email responses) then why don't we act on it fast. Regards Sukanta Ganguly >>> "Anurag Srivastava" 04/21 10:39 PM >>> I believe that there could be a minimum set of agreement that should be = allowed to be supported by every vendor for interoperability sake. But = there should be a flexibility to add extra facility in any particular = implementation if so desired. It is proposed that this minimum set could be : Replication Agreements What type of replica is it (read only, read-write, = schema-change-allowed)=20 Whether replica is allowed to communicate its own changes to the = owner/master Multiple replication behavior (propogate its changes to other = replicas before committing to it, under conflict communicate it the latest = changes/always accept its changes,...) Synchronization Agreements Priority for change acceptance during synchronizati= on (whether requester or owner's change presides over during the conflict) Granularity of synchronization (resource/attribute/attribute value = level) Who would initiate the synchronization (whether owner initiated or = requester initiated) When the synchronization gets initiated (as soon as change = happens, periodic, # of synch. request to bundle or a combination of above = ) Thanks & regards Anurag >>> "Uppili Srinivasan" 04/22/98 08:55AM >>> > About the Replication agreement, if the architecture=20 > does not nail down the different possibilities=20 > i.e one-way/two-way, full/incremental updates and=20 > consumer/supplier model, then where would these=20 > standard approaches be specified. Also, I believe that the=20 > architecture should clearly spell them out in detail.=20 True. The architecture should spell out how the agreements should be crafted (or what agreements should exist) for the different replication scenarios. The agreement specification should in turn standardize the structures and values for defined scenarios. Right now the discussion has still not converged on requirements. -Uppili Srinivasan=20 ___________________________________________________________________________= _=20 Oracle Corporation | =20 Box 659510 |Phone: (650)506-3039 Internet: usriniva@us.oracle.co= m=20 =20 500 Oracle Pkwy |Fax: (650)506-7122 =20 Redwood Shores |X.400: c=3Dus; a=3Dtelemail; p=3Doracle; o=3Doragate; = s=3Dusriniva =20 CA 94065 | =20 ___________________|_______________________________________________________= _ =20 =20 =20 From owner-ietf-ldup Wed Apr 22 16:17:03 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id QAA09529 for ietf-ldup-bks; Wed, 22 Apr 1998 16:17:03 -0700 (PDT) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id QAA09524; Wed, 22 Apr 1998 16:16:51 -0700 (PDT) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <27KGXZZB>; Thu, 23 Apr 1998 09:08:16 +1000 Message-ID: From: Alan Lloyd To: "'John Merrells'" Cc: "'Uppili Srinivasan'" , owner-ietf-ldup@imc.org, ietf-ldup@imc.org Subject: RE: Comments on ldup-replica-req-00.txt Date: Thu, 23 Apr 1998 09:08:15 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldup@imc.org Precedence: bulk > -----Original Message----- > From: John Merrells [SMTP:merrells@netscape.com] > Sent: Thursday, April 23, 1998 2:13 AM > To: Alan Lloyd > Cc: 'Uppili Srinivasan'; owner-ietf-ldup@imc.org; ietf-ldup@imc.org > Subject: Re: Comments on ldup-replica-req-00.txt > > Alan Lloyd wrote: > > > The mechanism of stating UIDs, DNs (where names are > modified) > > and such things are easy to say and write down in an RFC - now what. > > operationally it will hit walls and system robustness will be > demaned > > from high end directory systems that run banks, telephone > > infrastructures, CAs and online services and military applications. > > How else do you replicate the change? > As said in a managed way - that does not impose scaling issues or information management issues or clock synchronisation issues. Replication in directory product can be performed two ways - via the database tools (for those who are database focussed) and via DISP for those who (dont have RDBs) are X.500 focussed. Again the rationale for replication needs to carefully assessed. eg the requirement to get at the master entry - is that required, how many replicas are practical. Is distribution AND replication a better system if searches are generally in a local context and occasionally a wider scope is used. Every one working on directories seems to be focussed on replication and I see the need for it - but there should be a balanced view of distribution with replication - that way many of the replication issues do go away. If in a two DSA system a replication between one and the other is easy - when its between 30 DSa with 100k+ entries - its gets tough and exponentially bad (150 replication agreements). So one should split DIBs according to access/ownership "regions" and distribute these. And by all means have a few back end replicated systems as online back ups and as local access system. But never design a system as all replication (in fact if it is - it will never connect to anyone elses system efficiently.) Why do we want replication... a) Back up and redundancy b) Geographic distribution where high access rates are applied. ie. Replication does not satisfy directory interconnection with "other directories "owned and managed" by "other named" groups. ie. Replication mechanisms do not have to deal with the whole world being replicated to every where else and inconsistencies should be allowed. Because consistency in all cases in all places with earthly technology can never be guaranteed. > > As said the image that a directory is a mail address book > that > > must be replicated is still out there - and some simple tagging > system > > may be all thats needed for these - > > We may not use tagging. > We wont either :-) - great minds think alike eh :-) > > If directories are to be a disciplined, robust infrastucture > we > > really have to watch tagging and transaction mechanisms - If one > cannot > > scale it and inteconnect it reliably - dont bother. > > Yes, our goal is interoperability and a requirement is scalability. > us too - great minds again :-) > > and what happens if a DSA has a clock set to tomorow and its > > updated at the same time - differently - in the actual time + - a > > second, as a DSA with its clock set to today ? > > You don't have to use time for conflict resolution. > I think you do here. What happens if one user on one master changes a DN Bill to Fred and in the other master a user changes Bill to John or deletes Bill. Is the (real) time of the transaction not critical? > > [snip... icl] > Why do you do this - I had a great time with Icl :-) > > X.500 permits inconsistencies for this reason - ie clock > > synchronisation over the planet is hard - therefore a requirement to > > grab the "logical master entry" is provided in the protocol options. > > You don't have to use time for conflict resolution.There could be > multiple masters, how do you know which holds theone true > value. By the clock timestamp in the transation record of the last > update ........resolution = 2 microseconds and synchronised - and a > system clock can NEVER have the same time when read sequentially . been there done that - ICL .... snip - > > So the replication process really does not want to impose > > exponential loads on this infrastructure just trying to keep every > thing > > consistent. > > Scalable architecture is a requirement. yup. > > > > Lovely, but customers are asking for replicated directory > services. > > > > > yes we know, but that IMHO is because the "directory" > experts > > have been preaching that due to products distributed operations not > working the best > or at all (LDAP) and the LDAP theme of doing replication now. But > > then reality hits, as it always does - scaleability and > interopration > > and information consistency are now comming to the fore. > > > > Its going to be an interesting world when all the "replicate > > hypers" suddenly realise that all they are doing is casting a system > > which is unscaleable by nature and when they want to eventually > > interconnect for distributed operations - what a mess they will be > in. > > Yes, interoperability is the goal, scalability a requirement. > > > Distribution gets the naming and the knowledge and domain > based > > access control policies in place (and the distributed performance > issues > > resolved) that enable directory system scaling. > > We still need Replication and LDUP is the Replication working group. Yes - but if the requirement of asking for a "master" entry is adopted - then this can only be accessed in LDAP by a referral and in X.500 - seamlessly via DSP. ie X.500 access - distribution/chaining mechanisms support the replicated information environment. > > Replication just > > provides one with a "copy" of the inteconnection and performance > > problems as described that have not been fixed. > > Customers require replicated directory services. yup - we do DISP and DSP Can we agree on something. One can only get true consistency on replicated data where directory clock synchronisation is maintained to the resolution required eg 2 milliseconds, etc. If true clock synchronisation is not maintained - and updates/deletes not reconciled - then the system must accept and deal with replica inconsistencies. And what follows from this is: a) Can users get the "master" entry even if they are connected primarily to the replica system and b) what is required to reconcile DIB discrepancies. If the list wants to go down the "true replica path" - it will be a long haul. In addition we need a model for the "replication agreement" as the first step. Can we use the X.500 one. Regards alan - OpenDirectory (and ex ICL :-) ) > John > > -- > John Merrells > Netscape Communications > Directory Server > Software Engineer > > http://people.netscape.com/merrells > From owner-ietf-ldup Thu Apr 23 03:12:27 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id DAA27252 for ietf-ldup-bks; Thu, 23 Apr 1998 03:12:27 -0700 (PDT) Received: from Wind.Stanford.EDU (wind.Stanford.EDU [36.53.0.147]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id DAA27248 for ; Thu, 23 Apr 1998 03:12:26 -0700 (PDT) Received: from localhost (hodges@localhost) by Wind.Stanford.EDU (8.8.3/8.8.3) with ESMTP id DAA01709; Thu, 23 Apr 1998 03:13:49 -0700 (PDT) Message-Id: <199804231013.DAA01709@Wind.Stanford.EDU> X-Mailer: exmh version 2.0.2 2/24/98 Subject: thoughts on replication requirements To: LDAP Replication cc: Jeff.Hodges@Stanford.EDU From: Jeff.Hodges@Stanford.EDU Reply-to: LDAP Replication X-Office: Pine Hall Rm 161; +1-650-723-2452 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Apr 1998 03:13:48 -0700 Sender: owner-ietf-ldup@imc.org Precedence: bulk Here's some thoughts I have on our replication requirements and overall = approach given the present version of the reqs I-D, traffic on the ietf-l= dup & = ldup-repl lists, and some review of some papers on this topic. I feel Tim was correct in saying.. > The underlying problem here, and what's behind many of the issues John > is raising, seems to be that it's not clear what we are proposing to > standardize. = I'll second that and also assert that there are key, fundamental, overall= = characteristics inherent in replicated data storage systems that we have = not = specifically enumerated and considered. I think we need to explicitly do so in order to maximize our opportunitie= s for = designing a system (and underlying protocol) that meets our goals. Below's a summary of these characteristics along with some discussion and= = references. It's apparent from the references that there are folks, outsi= de of = the "directory" community proper, who've been considering and building sy= stems = quite similar to our envisioned one and it makes sense to look carefully = at = what they've done to see what we can leverage off of -- both in terms of = crystallizing our perspective of the overall system, but also in terms of= = utilizing specific approaches/techniques in implementing it (as Mark Wahl= is = proposing). I do have specific comments on draft-weiser-repla-01.txt and will include= them = in a separate message a bit later on. thanks, Jeff -------------------------------------------------------------------------= ---- Fundamental characteristics for replicated data stores... 1. Synchronicity Are our anticipated client applications synchronous or = asynchronous in nature? 2. Data consistency between replicas Do these client applications require weakly- or strongly-consistent = views of the data, or in-between, or all-of-the-above? 3. Operational semantics What are client applications' requirements for various aspects = of the data store's operational semantics? "Synchronous" means systems where client entities share some "thing" at t= he = same time, whereas "asynchronous" means systems where client entities sha= re = that thing at different times (or more succinctly, needn't necessarily sh= are = it at the same time). Degrees of consistency relate to whether someone looking at a piece of da= ta in = the system sees it the same as someone else looking at it. Synchronicity and consistency are often interdependent: the more synchron= ous = an application, the more strongly-consistent its views of the "thing" = typically need to be. Or, in reverse, the more strongly-consistent a data= = store can be, the more strongly-synchronous its client applications can = (typically) be. Operational semantics for replicated data stores cover the gamut of: Conflict detection - how do I know I have a data conflict? Conflict resolution - what can I do about a data conflict? Data propagation policies - when are updates propagated to other replic= as? Consistency level - how consistent is ~my~ view of the data store acros= s = replicas, and across my own utilization of it? What= = guarantees do I have, if any? Data stability - what's the possibility that the data I'm looking at on= a = given replica might change? Replica selection - May I talk to which ever replica seems appropriate = at = a given time? May I switch replicas over time? = Discussion... Our current requirements doc does not explicitly address the above = characteristics -- except for some aspects of operational semantics. Also= , in = terms of "consistency", the term isn't explicitly used, and additionally,= = requirements 5.2 and 5.7 are in direct conflict, as-written. For example, are we assuming that directory client applications (e.g. a s= imple = user-driven browser, or some network management environment) are typicall= y = synchronous or asynchronous in nature? Do we even know? I'd say we don't = know = overall, and even if we did, it'd change tomorrow anyway. If we adopt tha= t = perspective -- i.e. that we don't really know -- thus a ~requirement~ we = have = is that our replicated data store needs to support a range of client = synchronicity needs. (aside: I searched the X.500, X.501, X.518, and X.52= 5 = docs for "synch", and didn't get any hits except for in X.518 in terms of= = "asynchronous events", which are defined to be things such as "admin limi= t = exceeded", which is decidedly in a different class than the consideration= s = here) See [1] for more about how various application with various require= ments = are built upon Bayou. Similarly, are we expecting that LDAP-based directory deployments utilizi= ng = replication are always weakly-consistent or strongly-consistent? Or shoul= d the = system provide for some range of consistency behavior? Replication agreements fall into the overall area of operational semantic= s, = but our discussion of them has been only in terms of propagation scheduli= ng = and replica selection -- leaving at least four other operational semantic= s = subareas to address. I think that the pointer to the Bayou work that Mark Wahl provided in his= = proposal was quite relevant and that we should all take some time to read= = about it. The specific papers I've looked at are listed below. Much of Bayou's potential contributions to LDAP replication appear to be = in = the areas of operational semantics and anti-entropy (i.e. update propagat= ion) = algorthim and data structure design -- both of which are key enablers for= = their realizing their (and our) primary goal of efficient "anywhere/anyti= me" = access to data. Note that [2] provides experimental data on update propag= ation = performance. I've done some poking around a couple of comp sci bibliographic resources= on = the web for more info on replication, and haven't come up with anything o= ther = than Bayou, and the related work that is (notably carefully) cited in the= ir = papers. Does anyone have any references to any papers roughly equivalent to any o= f = those below ([2] especially) that deal with X.500 as the subject? I could= only = find some references to some work done at University of Ottowa, but the o= ne = paper ostensibly dealing with replication isn't presently in their reposi= tory. References... [papers below available at: http://www.parc.xerox.com/csl/projects/bayou/= ] [1] W K Edwards, E D Mynatt, Karin Petersen, Mike J. Spreitzer, Douglas B= =2E = Terry, Marvin M. Theimer. "Designing and Implementing Asynchronous = Collaborative Applications with Bayou". Proceedings of the Tenth ACM Symp= osium = on User Interface Software and Technology (UIST), Banff, Alberta, Canada,= = October, 1997. [2] Karin Petersen, Mike J. Spreitzer, Douglas B. Terry, Marvin M. Theime= r, = Alan J. Demers. "Flexible Update Propagation for Weakly Consistent = Replication". Proceedings of the 16th ACM Symposium on Operating Systems = Principles (SOSP-16), Saint Malo, France, October 5-8, 1997, pages 288-30= 1. [3] Douglas B. Terry, Alan J. Demers, Karin Petersen, Mike J. Spreitzer, = Marvin M. Theimer, Brent B. Welch. "Session Guarantees for Weakly Consist= ent = Replicated Data". Proceedings International Conference on Parallel and = Distributed Information Systems (PDIS), Austin, Texas, September 1994, pa= ges = 140-149 (IEEE Computer Society Press). From owner-ietf-ldup Thu Apr 23 09:01:14 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id JAA29167 for ietf-ldup-bks; Thu, 23 Apr 1998 09:01:14 -0700 (PDT) Received: from novell.com (prv-mail25.Provo.Novell.COM [137.65.40.3]) by mail.proper.com (8.8.8/8.7.3) with SMTP id JAA29163; Thu, 23 Apr 1998 09:01:13 -0700 (PDT) Received: from INET-PRV1-Message_Server by novell.com with Novell_GroupWise; Thu, 23 Apr 1998 10:02:07 -0600 Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Thu, 23 Apr 1998 10:01:14 -0600 From: "Russel Weiser" To: owner-ietf-ldup@imc.org, merrells@netscape.com, Alan.Lloyd@OpenDirectory.com.au Cc: ietf-ldup@imc.org, USRINIVA@us.oracle.com Subject: Re: Comments on ldup-replica-req-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: owner-ietf-ldup@imc.org Precedence: bulk >>> "John Merrells" 04/21 5:53 PM >>> Alan Lloyd wrote: > [snip...icl anecdote] > And I shudder to think that every time an attribute is updated, > I would have to broadcast over [to] the replicated system, the DN, the > attribute type.value and its tag so that it could be verified and > possibly superceded by a clash from one or more other places. Each operation will require a different set of items to be transferredbetwe= en servers. They'll always be a Unique Identifier for the entry, this is more likely to be a UUID than a DN. If it's a modify, as you suggest, then the attribute identifier and value must be sent. The final piece of information required will be something to aid the conflict detection and resolution policy you decide to deploy. > what about time zones, transit delays, system clock resolution. You don't have to use time in your conflict detection and resolutionpolicy.= You could choose something else. Like the attribute versioning which we've just mentioned. (RFW) John I may have missed something in the Email thread where = versioning has been shown to work... If I have three servers that the = replicating then on two of the servers an attribute is modified 2 = different clients differently How would you suggest versioning work and = resolve to the=20 third server????? Cheers=20 RFW > Distributed - high performance DSAs seem a lot less effort and > less problematic - Lovely, but customers are asking for replicated directory services. John > I wonder who can supply those :-) > > regards alan > > -Uppili Srinivasan > > ______________________________________________________________________ > > ______ > > Oracle Corporation | > > Box 659510 |Phone: (650)506-3039 Internet: > > usriniva@us.oracle.com=20 > > > > 500 Oracle Pkwy |Fax: (650)506-7122 > > Redwood Shores |X.400: c=3Dus; a=3Dtelemail; p=3Doracle; o=3Doragat= e; > > s=3Dusriniva > > > > CA 94065 | > > ___________________|__________________________________________________ > > ______ > > > > > > > > > > << File: ATT00115.ATT >> << Message: Re: Comments on > > ldup-replica-req-00.txt >> -- John Merrells Netscape Communications Directory Server Software Engineer http://people.netscape.com/merrells=20 From owner-ietf-ldup Thu Apr 23 08:50:43 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id IAA29074 for ietf-ldup-bks; Thu, 23 Apr 1998 08:50:43 -0700 (PDT) Received: from novell.com (prv-mail25.Provo.Novell.COM [137.65.40.3]) by mail.proper.com (8.8.8/8.7.3) with SMTP id IAA29070; Thu, 23 Apr 1998 08:50:42 -0700 (PDT) Received: from INET-PRV1-Message_Server by novell.com with Novell_GroupWise; Thu, 23 Apr 1998 09:51:31 -0600 Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Thu, 23 Apr 1998 09:48:06 -0600 From: "Russel Weiser" To: owner-ietf-ldup@imc.org, merrells@netscape.com, USRINIVA@us.oracle.com Cc: ietf-ldup@imc.org, alan.lloyd@OpenDirectory.com.au Subject: Re: Comments on ldup-replica-req-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: owner-ietf-ldup@imc.org Precedence: bulk John and Uppili=20 A couple of things here that are of interest and 'd like to ducuss = further. My comments are below=20 =20 >>> "John Merrells" 04/21 4:06 PM >>> Uppili Srinivasan wrote: > John: Why will each server maintain "its own" increasing counter for = each > attribute. This is the model I believe that the Bayou project uses. Each write is = assigned a number from a server specific counter. Each server then keeps track of the latest update it has received from every server in the set of master = servers. This is done to avoid writes being replayed to servers which don't need = them. The salability problem is that each server needs to know about every other server. I'd hope there was a solution which did away with this. The below is not actually what I meant. I guess I must have stumbled on an overloaded term. It is interesting though, as I believe this is the = conflict resolution policy used by Exchange, and was proposed by Chris Weiser & John Strassner in their multi-master draft. I think this mechanism is = opposed be those who believe 'most-written-wins' isn't a desirable policy. (RFW) John it was Chris Weider and John Strassner that did the multi- = master draft.=20 I'm also confused by the most-written-wins statement above can you = clarify this=20 point please. John > If you mean the attribute version numbers, then there ought to > be a systemwide version number for each attribute. The job of the = conflict > resolution policy should be to ensure systemwide convergence towards the > same image of all items (attributes). A potential picture is: (RFW) Above the resoloution policy should ensure systemwide convergence=20 toward a same image of all attributes (in a deterministic manner).. = This is the most=20 important thing about the convergence I think. > - When an entry is created all attributes start with version 1 > - If the same entry (DN being the same) is created in multiple places, = only > one of the entries (in its entirety) would win based on the enterprise = CR > policy (could be time stamp). So all attributes will start with version = 1 > on all servers > - If two servers update the same attribute from version n to version n+1 > then again CR policy would have to ensure that only one of the updates = win > (again possibly based on timestamps). So the system would converge to > version n+1 for this attribute to value associated with the winner = above.=20 (RFW)=20 The how of the CR Policy is something that I believe must happen in a = particualar=20 manner to achieve the proper behavior of the convergence. Something that = hasn't=20 been discussed yet it the TIME Synchronization between servers participatin= g in a replication. =20 This is something that should be addressed in the requirements I guess.=20 cheers=20 RFW > > can you explain the scalability problem here? > > -Uppili Srinivasan > _________________________________________________________________________= ___ > Oracle Corporation | > Box 659510 |Phone: (650)506-3039 Internet: usriniva@us.oracle.= com=20 > > 500 Oracle Pkwy |Fax: (650)506-7122 > Redwood Shores |X.400: c=3Dus; a=3Dtelemail; p=3Doracle; o=3Doragate;= s=3Dusriniva > > CA 94065 | > ___________________|_____________________________________________________= ___ > > > > > -----------------------------------------------------------------------= --------------------------------------------------------- > > Subject: Re: Comments on ldup-replica-req-00.txt > Date: 21 Apr 98 11:56:00 > From: "John Merrells" > Organization: Netscape Communications > To: Alan Lloyd > CC: ietf-ldup@imc.org=20 > References: > > Alan Lloyd wrote: > > > Of course - its just that these servers just become "normal" > > users of the directory that must be authenticated and if one changes = the > > credentials of a server in one server - how does that get into the > > second - unless servers need to use their old credentials depending if > > they have replicated them or not... is this chicken and egg stuff. > > That hasn't been raised as a requirement either. An administrator's > intention may indeed be to permanently or temporarily deny access to > some other server. In any case, the administrators should sort it out. > > > > > Does this mean changes to the LDAP RFC? > > > > > > Probably, in the form of new controls, and possibly extended > > > operations. > > > > > > > You see replication needs to be initated by either server > > > and > > > > replicas transferred in either direction so its either a > > > bi-directional > > > > LDAP server to server with transaction control and server based > > > > management and a lot of Gods help (this is not a religious = statement > > > > ;-)) > > > > > > It could be a session in each direction. > > With God in most cases it seems to be simplex - but I realise = it > > is bothways with LDAP :-) see above. > > Alan, you've lost me with the God acronym. > > An LDAP Replication session could be implemented as one bi-directional > session, or two uni-directional sessions. > > > Protocol fields are easy to > > write down . eg ip6 address is just 16 bytes - now try and deploy it = and > > make it work as a global network. > > Um, LDAP Replication might require some extra controls to definethe = start > and end of a replcation session. > > > Want to ask Oracle, Ingres or Sybase about transaction locking > > systems and deadlock issues? > > No, I've got a book all about it. > > An LDAP Replication protocol specifiction could mandate the use of > transactions, but it's probably not essential that it does. > > > If they stay like DISP there is a chance of success - : -) .. > > existance proof is good. > > Is that documented in X.525? > > Are there any documents that address using DISP for multi-master > directory topologies? > > > > So far, no one's suggested this as a requirement. > > > > > May I suggest a feature which......................... > > Are you suggesting identifying an entry as a master/shadow as arequiremen= t > then? > > > > I'd wonder though... that if your application has real-time > > > constraints then > > > you probably don't want to store your data in some loosly consistent > > > store. > > X.500 permits inconsistencies - but leaves the ops people to > > sort that out- but X.500 provides the services to always get the = master > > entry just in case the ops people dont make it. > > Who are ops people? > > 'One of the master copies', seems no better than 'One of the replica = copies'. > > > > Also... if an entry is mastered by many servers... then you won't = know > > > which server holds the 'correct' value anyway. So it doesn't sound > > > like > > > this buys you much. > > > > > In X.500 one does via the information being tagged as copies > > (internally in the DSA because it arrived via DISP) - and with the > > knowledge information in the replication agreements the replica DSA > > knows of the master - and the via DSP (distribution again - an LDAP > > deficiency) I can request of the replica I am connected to to go to = the > > master via DSP to get it by specifying Dont Use Copy - all seamlessly = to > > the user - you see replication and distribution in X.500 work = together. > > In LDAP land all the parts arn't there yet. So replication on its own = is > > very limited.... > > I think you're missing my point. Which of the master copies is the = onetrue > correct copy? You'll just never know. > > > through replication agreements and using op attrs. > > > > The replication scaling problem is reduced with distributed > > directories in the first place. > > Reduced, but not elliminated. Say you have a set of N masters for an > entry.Each server maintains an increasing counter which is > used to tag attribute > values as they're updated. These tags are then used to determine which > values are communicated to each of its peers. The question is: 'How do > you avoid each server having to know the highest tag value sent from > each other server?' This seems to be the big scalability problem for > multi-master directories. How does X.500 solve this? > > John > > -- > John Merrells > Netscape Communications > Directory Server > Software Engineer > > http://people.netscape.com/merrells=20 -- John Merrells Netscape Communications Directory Server Software Engineer http://people.netscape.com/merrells=20 From owner-ietf-ldup Thu Apr 23 13:24:46 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id NAA01419 for ietf-ldup-bks; Thu, 23 Apr 1998 13:24:46 -0700 (PDT) Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.7.3) with SMTP id NAA01414 for ; Thu, 23 Apr 1998 13:24:45 -0700 (PDT) Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Thu, 23 Apr 1998 14:11:38 -0600 Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Thu, 23 Apr 1998 10:47:19 -0600 From: "Ed Reed" To: merrells@netscape.com, Alan.Lloyd@OpenDirectory.com.au Cc: ldup-repl@external.cicso.com, ietf-ldup@imc.org Subject: Re: Comments w/r/t data mastered in many places... Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: owner-ietf-ldup@imc.org Precedence: bulk John Merriells wrote... >Alan Lloyd wrote: > > >> But then how will I get the master entry if I need it. I may be >> connected to a replica server for my address book details, but would >> really like the military target information from the master in case its >> been updated in the last ten minutes and has not been propagated yet. >> Users must have the mechansims to get to master info - in case >> of inconsistencies caused by latent replica updates - >> See X.500 - Dont Use Copy, Copy Shall Do, its defined, it works >> and its useful. > >So far, no one's suggested this as a requirement. Actually, I think it is, for the reason you raise... > >I'd wonder though... that if your application has real-time constraints = then >you probably don't want to store your data in some loosly consistent = store. > That's one of the reasons I've not been comfortable calling any writeable = replica a master of the data...it's not, it's just an updateable replica. The master replica needs to be a = designated replica to which special operations can be directed, for instance when an application wants high confidence = that tight consistency is being enforced... this is most easily done by directing all such tight-consistency operations= against the designated master replica. Another use of the master replica is to treat it as the transaction = coordinator for directory information (distributed knowledge) operations which require tight consistency, such as adding or = removing a replica from the known set of replicas for a particular partition of the namespace, or to merge = two partitions into a single partition, or to create a new partition of the namespace. High confidence has value in several scenarios and probably needs to be = re-introduced into LDAP, perhaps as a new control (which is really what it is...a control on the resolve = name/get referral operation embedded in the high level LDAP operation being performed (read, modify, create, = whatever). It would, of course, be dependent on the available knowledge in the directory itself with regard = to replicas and their types of the particular partition holding the objects being so operated upon. >Also... if an entry is mastered by many servers... then you won't know >which server holds the 'correct' value anyway. So it doesn't sound like >this buys you much. > ------------------- Ed Reed, Technologist Group Technology Office Novell, Inc. +1 801 861 3320 From owner-ietf-ldup Thu Apr 23 15:06:43 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id PAA02322 for ietf-ldup-bks; Thu, 23 Apr 1998 15:06:43 -0700 (PDT) Received: from Wind.Stanford.EDU (wind.Stanford.EDU [36.53.0.147]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id PAA02318 for ; Thu, 23 Apr 1998 15:06:43 -0700 (PDT) Received: from localhost (hodges@localhost) by Wind.Stanford.EDU (8.8.3/8.8.3) with ESMTP id PAA02579; Thu, 23 Apr 1998 15:08:08 -0700 (PDT) Message-Id: <199804232208.PAA02579@Wind.Stanford.EDU> X-Mailer: exmh version 2.0.2 2/24/98 Subject: proposals on the table? To: LDAP Replication cc: Steven Legg From: Jeff.Hodges@Stanford.EDU Reply-to: Jeff.Hodges@Stanford.EDU X-Office: Pine Hall Rm 161; +1-650-723-2452 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 23 Apr 1998 15:08:08 -0700 Sender: owner-ietf-ldup@imc.org Precedence: bulk A question just raised on the conf call was "what are all the proposals on the table"? Here's what I see in my mail folder... Replication between LDAP Servers Mark Wahl, M.Wahl@innosoft.com Netscape Abstract John Merrells Joint Novell - IBM Abstract Ed Reed, Ellen Stokes Oracle Abstract Uppili Srinivasan Telstra Replication Proposal Steven Legg We should note, I think, that there's also this current I-D.. LDAP Multi-Master Replication Protocol expires May 20, 1998. ftp://ftp.ietf.org/internet-drafts/draft-ietf-asid-ldap-mult-mast-rep-02.txt Jeff From owner-ietf-ldup Thu Apr 23 15:14:39 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id PAA02413 for ietf-ldup-bks; Thu, 23 Apr 1998 15:14:39 -0700 (PDT) Received: from Wind.Stanford.EDU (wind.Stanford.EDU [36.53.0.147]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id PAA02409 for ; Thu, 23 Apr 1998 15:14:39 -0700 (PDT) Received: from localhost (hodges@localhost) by Wind.Stanford.EDU (8.8.3/8.8.3) with ESMTP id PAA03053; Thu, 23 Apr 1998 15:16:05 -0700 (PDT) Message-Id: <199804232216.PAA03053@Wind.Stanford.EDU> X-Mailer: exmh version 2.0.2 2/24/98 Subject: Microsoft's participation? To: LDAP Replication cc: Steven Legg From: Jeff.Hodges@Stanford.EDU Reply-to: Jeff.Hodges@Stanford.EDU X-Office: Pine Hall Rm 161; +1-650-723-2452 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 23 Apr 1998 15:16:04 -0700 Sender: owner-ietf-ldup@imc.org Precedence: bulk As noted just now on the conf call, there is no Microsoft representative on the ldup-repl list. Does this mean that they are not participating? RLBob & I find this a tad odd given that in our experience they will claim that they (will) have way-cool (LDAP?) directory replication in NT 5.0. Should we be considering draft-ietf-asid-ldap-mult-mast-rep-02.txt as their proposal? Should we perhaps ask them directly? Has anyone asked Paul Leach or his counterpart (Mark, Scott, ?) Brown what their intentions are? The understanding Brown gave RLBob at the NAC conference earlier this week was that Paul L. would be covering the IETF directory work for Microsoft now that Chris W. is off doing other stuff. Jeff From owner-ietf-ldup Thu Apr 23 16:12:49 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id QAA02789 for ietf-ldup-bks; Thu, 23 Apr 1998 16:12:49 -0700 (PDT) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id QAA02785 for ; Thu, 23 Apr 1998 16:12:45 -0700 (PDT) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <27KGXZ6Q>; Fri, 24 Apr 1998 09:04:15 +1000 Message-ID: From: Alan Lloyd To: "'LDAP Replication'" Subject: RE: thoughts on replication requirements Date: Fri, 24 Apr 1998 09:04:13 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ietf-ldup@imc.org Precedence: bulk > -----Original Message----- > From: Jeff.Hodges@Stanford.EDU [SMTP:Jeff.Hodges@Stanford.EDU] > Sent: Thursday, April 23, 1998 8:14 PM > To: LDAP Replication > Cc: Jeff.Hodges@Stanford.EDU > Subject: thoughts on replication requirements > > Here's some thoughts I have on our replication requirements and > overall > approach given the present version of the reqs I-D, traffic on the > ietf-ldup & > ldup-repl lists, and some review of some papers on this topic. > > I feel Tim was correct in saying.. > > > The underlying problem here, and what's behind many of the issues > John > > is raising, seems to be that it's not clear what we are proposing to > > standardize. > snip to save transmission Lots of good thoughts and references. A couple of mine. I like to think that X.500 directories did not mention "synchronisation" because the implementation and resolution of that is a lower level data implementation issue that should be serviced by realtime clocks, maybe database tools or just lots of glass fibre between the DSAs. X.500 defines the object oriented abstract model for directories with its high level protocols - No sync was not an omission - its just things like performance, integrity, attribute index issues and sync are usually left to the implementor so that competitive advanatges can be obtained. So while many people can study this distributed integrity thing - it really does come down to mechanisms - which may or may not scale universally - do have a cost and a failure point. For our part - very high replication consistency and reliability can be obtained via the database - database replicator which because it is out of the RDB (sub X.500 object level) its fast and direct. In addition we can DISP and the X.500 level - and that could be equally as fast if the computational and transmission resources are applied correctly. - Fast and Consistency do depend on value judgement and product mechanisms. Standardising these will be (as said) a long haul. Because what is good and what is bad? Directory level replication mechanims and the delivery of services around master and replica data is a better problem to address - regards alan From owner-ietf-ldup Thu Apr 23 16:22:14 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id QAA02841 for ietf-ldup-bks; Thu, 23 Apr 1998 16:22:14 -0700 (PDT) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id QAA02836; Thu, 23 Apr 1998 16:22:06 -0700 (PDT) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <27KGXZ6S>; Fri, 24 Apr 1998 09:13:37 +1000 Message-ID: From: Alan Lloyd To: "'Russel Weiser'" , owner-ietf-ldup@imc.org, merrells@netscape.com, Alan Lloyd Cc: ietf-ldup@imc.org, USRINIVA@us.oracle.com Subject: RE: Comments on ldup-replica-req-00.txt Date: Fri, 24 Apr 1998 09:13:35 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ietf-ldup@imc.org Precedence: bulk > -----Original Message----- > From: Russel Weiser [SMTP:RWEISER@novell.com] > Sent: Friday, April 24, 1998 2:01 AM > To: owner-ietf-ldup@imc.org; merrells@netscape.com; > Alan.Lloyd@OpenDirectory.com.au > Cc: ietf-ldup@imc.org; USRINIVA@us.oracle.com > Subject: Re: Comments on ldup-replica-req-00.txt > > > > >>> "John Merrells" 04/21 5:53 PM >>> > Alan Lloyd wrote: > > > [snip...icl anecdote] > > > And I shudder to think that every time an attribute is > updated, > > I would have to broadcast over [to] the replicated system, the DN, > the > > attribute type.value and its tag so that it could be verified and > > possibly superceded by a clash from one or more other places. > > Each operation will require a different set of items to be > transferredbetween servers. They'll always be a Unique Identifier for > the entry, > this is more likely to be a UUID than a DN. If it's a modify, as you > suggest, then the attribute identifier and value must be sent. The > final piece of information required will be something to aid the > conflict detection and resolution policy you decide to deploy. > > > what about time zones, transit delays, system clock > resolution. > > You don't have to use time in your conflict detection and > resolutionpolicy. You could choose something else. Like the > attribute versioning > which we've just mentioned. > (RFW) John I may have missed something in the Email thread where > versioning has been shown to work... If I have three servers that the > replicating then on two of the servers an attribute is modified 2 > different clients differently How would you suggest versioning work > and resolve to the > third server????? > As said - how do deletes and renames work with versions - as said been there done that - a good clock source is needed - trust me - ex ICL :-) regards alan > Cheers > RFW > > Distributed - high performance DSAs seem a lot less effort > and > > less problematic - > > Lovely, but customers are asking for replicated directory services. > > John > > > > > I wonder who can supply those :-) > > > > regards alan > > > -Uppili Srinivasan > > > > ______________________________________________________________________ > > > ______ > > > Oracle Corporation | > > > Box 659510 |Phone: (650)506-3039 Internet: > > > usriniva@us.oracle.com > > > > > > 500 Oracle Pkwy |Fax: (650)506-7122 > > > Redwood Shores |X.400: c=us; a=telemail; p=oracle; o=oragate; > > > s=usriniva > > > > > > CA 94065 | > > > > ___________________|__________________________________________________ > > > ______ > > > > > > > > > > > > > > > << File: ATT00115.ATT >> << Message: Re: Comments on > > > ldup-replica-req-00.txt >> > > > > -- > John Merrells > Netscape Communications > Directory Server > Software Engineer > > http://people.netscape.com/merrells > > From owner-ietf-ldup Thu Apr 23 16:19:19 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id QAA02819 for ietf-ldup-bks; Thu, 23 Apr 1998 16:19:19 -0700 (PDT) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id QAA02814; Thu, 23 Apr 1998 16:19:03 -0700 (PDT) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <27KGXZ6R>; Fri, 24 Apr 1998 09:10:37 +1000 Message-ID: From: Alan Lloyd To: "'Russel Weiser'" , owner-ietf-ldup@imc.org, merrells@netscape.com, USRINIVA@us.oracle.com Cc: ietf-ldup@imc.org, Alan Lloyd Subject: RE: Comments on ldup-replica-req-00.txt Date: Fri, 24 Apr 1998 09:10:35 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldup@imc.org Precedence: bulk > -----Original Message----- > From: Russel Weiser [SMTP:RWEISER@novell.com] > Sent: Friday, April 24, 1998 1:48 AM > To: owner-ietf-ldup@imc.org; merrells@netscape.com; > USRINIVA@us.oracle.com > Cc: ietf-ldup@imc.org; alan.lloyd@OpenDirectory.com.au > Subject: Re: Comments on ldup-replica-req-00.txt > > John and Uppili > > A couple of things here that are of interest and 'd like to ducuss > further. > My comments are below > snip - > Something that hasn't > been discussed yet it the TIME Synchronization between servers > participating in a replication. > This is something that should be addressed in the requirements I > guess. > Yes its a requirement - in X.500 the time limit for searches when provided by users is "seconds" when propagated in DSP its UTC time + seconds for obvious reasons - this means that DSAs when performing distributed searches need some synchronised time source if time limit is to be honoured. ditto goes with replication, if trying to maintain integrity of deletes and renames in multimaster mode - see previous mail re value judgment. regards alan > cheers > RFW > > > > can you explain the scalability problem here? > > > > -Uppili Srinivasan > > > ______________________________________________________________________ > ______ > > Oracle Corporation | > > Box 659510 |Phone: (650)506-3039 Internet: > usriniva@us.oracle.com > > > > 500 Oracle Pkwy |Fax: (650)506-7122 > > Redwood Shores |X.400: c=us; a=telemail; p=oracle; o=oragate; > s=usriniva > > > > CA 94065 | > > > ___________________|__________________________________________________ > ______ > > > > > > > > > > > ---------------------------------------------------------------------- > ---------------------------------------------------------- > > > > Subject: Re: Comments on ldup-replica-req-00.txt > > Date: 21 Apr 98 11:56:00 > > From: "John Merrells" > > Organization: Netscape Communications > > To: Alan Lloyd > > CC: ietf-ldup@imc.org > > References: > > > > Alan Lloyd wrote: > > > > > Of course - its just that these servers just become > "normal" > > > users of the directory that must be authenticated and if one > changes the > > > credentials of a server in one server - how does that get into the > > > second - unless servers need to use their old credentials > depending if > > > they have replicated them or not... is this chicken and egg stuff. > > > > That hasn't been raised as a requirement either. An administrator's > > intention may indeed be to permanently or temporarily deny access to > > some other server. In any case, the administrators should sort it > out. > > > > > > > Does this mean changes to the LDAP RFC? > > > > > > > > Probably, in the form of new controls, and possibly extended > > > > operations. > > > > > > > > > You see replication needs to be initated by either > server > > > > and > > > > > replicas transferred in either direction so its either a > > > > bi-directional > > > > > LDAP server to server with transaction control and server > based > > > > > management and a lot of Gods help (this is not a religious > statement > > > > > ;-)) > > > > > > > > It could be a session in each direction. > > > With God in most cases it seems to be simplex - but I > realise it > > > is bothways with LDAP :-) see above. > > > > Alan, you've lost me with the God acronym. > > > > An LDAP Replication session could be implemented as one > bi-directional > > session, or two uni-directional sessions. > > > > > Protocol fields are easy to > > > write down . eg ip6 address is just 16 bytes - now try and deploy > it and > > > make it work as a global network. > > > > Um, LDAP Replication might require some extra controls to definethe > start > > and end of a replcation session. > > > > > Want to ask Oracle, Ingres or Sybase about transaction > locking > > > systems and deadlock issues? > > > > No, I've got a book all about it. > > > > An LDAP Replication protocol specifiction could mandate the use of > > transactions, but it's probably not essential that it does. > > > > > If they stay like DISP there is a chance of success - : -) > .. > > > existance proof is good. > > > > Is that documented in X.525? > > > > Are there any documents that address using DISP for multi-master > > directory topologies? > > > > > > So far, no one's suggested this as a requirement. > > > > > > > May I suggest a feature which......................... > > > > Are you suggesting identifying an entry as a master/shadow as > arequirement > > then? > > > > > > I'd wonder though... that if your application has real-time > > > > constraints then > > > > you probably don't want to store your data in some loosly > consistent > > > > store. > > > X.500 permits inconsistencies - but leaves the ops people > to > > > sort that out- but X.500 provides the services to always get the > master > > > entry just in case the ops people dont make it. > > > > Who are ops people? > > > > 'One of the master copies', seems no better than 'One of the replica > copies'. > > > > > > Also... if an entry is mastered by many servers... then you > won't know > > > > which server holds the 'correct' value anyway. So it doesn't > sound > > > > like > > > > this buys you much. > > > > > > > In X.500 one does via the information being tagged as > copies > > > (internally in the DSA because it arrived via DISP) - and with the > > > knowledge information in the replication agreements the replica > DSA > > > knows of the master - and the via DSP (distribution again - an > LDAP > > > deficiency) I can request of the replica I am connected to to go > to the > > > master via DSP to get it by specifying Dont Use Copy - all > seamlessly to > > > the user - you see replication and distribution in X.500 work > together. > > > In LDAP land all the parts arn't there yet. So replication on its > own is > > > very limited.... > > > > I think you're missing my point. Which of the master copies is the > onetrue > > correct copy? You'll just never know. > > > > > through replication agreements and using op attrs. > > > > > > The replication scaling problem is reduced with > distributed > > > directories in the first place. > > > > Reduced, but not elliminated. Say you have a set of N masters for an > > entry.Each server maintains an increasing counter which is > > used to tag attribute > > values as they're updated. These tags are then used to determine > which > > values are communicated to each of its peers. The question is: 'How > do > > you avoid each server having to know the highest tag value sent from > > each other server?' This seems to be the big scalability problem > for > > multi-master directories. How does X.500 solve this? > > > > John > > > > -- > > John Merrells > > Netscape Communications > > Directory Server > > Software Engineer > > > > http://people.netscape.com/merrells > > > > -- > John Merrells > Netscape Communications > Directory Server > Software Engineer > > http://people.netscape.com/merrells > From owner-ietf-ldup Thu Apr 23 17:24:10 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id RAA03371 for ietf-ldup-bks; Thu, 23 Apr 1998 17:24:10 -0700 (PDT) Received: from inet16.us.oracle.com (inet16.us.oracle.com [192.86.155.100]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id RAA03367 for ; Thu, 23 Apr 1998 17:24:08 -0700 (PDT) Received: from mailsun2.us.oracle.com (mailsun2.us.oracle.com [144.25.88.74]) by inet16.us.oracle.com (8.8.5/8.8.5) with SMTP id RAA15395; Thu, 23 Apr 1998 17:25:28 -0700 (PDT) Received: by mailsun2.us.oracle.com (SMI-8.6/37.8) id RAA18998; Thu, 23 Apr 1998 17:25:27 -0700 Message-Id: <199804240025.RAA18998@mailsun2.us.oracle.com> Date: 23 Apr 98 15:37:20 -0700 From: "Uppili Srinivasan" To: ietf-ldup@imc.org, jeff.hodges@Stanford.EDU Subject: Re: proposals on the table? Cc: sanjay@software.com, ggood@netscape.com, s.legg@trl.telstra.com.au X-Orcl-Application: InterOffice Version4.1.2.10.50 MIME-Version: 1.0 X-Mailer: Oracle InterOffice (version 4.1.1.3.40) content-type: multipart/mixed; boundary="=_ORCL_19993906_0r0" Sender: owner-ietf-ldup@imc.org Precedence: bulk --=_ORCL_19993906_0r0 content-type:multipart/alternative; boundary="=_ORCL_19993906_0r1" --=_ORCL_19993906_0r1 Content-Type:text/plain; charset="us-ascii" Content-Transfer-Encoding:7bit There is one more I-D that defines a framework for defining and using replication agreements Schema for Replication Information http://www.ietf.org/internet-drafts/draft-ietf-asid-ldap-repl-info-01.txt I just noticed that it has gone past the expiry date (02/98). I will find out from the chair how to reset/resubmit and do the needful. I beleive this draft captures the core ideas. As our discussion progresses we plan on working on it to reflect the group consensus. Thanks! -Uppili Srinivasan ____________________________________________________________________________ Oracle Corporation | Box 659510 |Phone: (650)506-3039 Internet: usriniva@us.oracle.com 500 Oracle Pkwy |Fax: (650)506-7122 Redwood Shores |X.400: c=us; a=telemail; p=oracle; o=oragate; s=usriniva CA 94065 | ___________________|________________________________________________________ --=_ORCL_19993906_0r1 Content-Type:application/x-compressed-rtf Content-Transfer-Encoding:base64 VQMAAI4FAABMWkZ1mo3HlP8ACgEPAhUCpAPkBesCgwBQEwNUAgBjaArAc2V07jIGAAbDAoMy BEcIVQeyrQKDMwRGEZcxE480FKjIcHJxFb9mNRSvF78cZjYDxRdjEiJzdGW6bQKAfQqACM8J 2TsdUnwyNRjQHbscgQ2iC2BuMGcxMDMUkAsDbGl8MTgN8AUQIUILVRLxcyAxNyBUaASQZSA9 BAAgAiAjAARgIvFJLfhEIHQRwAVADbELgAeRVGEgA1BhB4B3BbBrLyUABbEkcwuAZyTgbmQ8 IHUAkCZRHWALUGljfSRAaQIgJOAJwgeAAjBzewqFCoVTEbAcQCTxBbFSeSc5SW4lsQDAJ5IK hWhBAkBwOi8vdyxgLssIkAAwLgWwZy8LgBwwMwSgEgAtZCUgAYBzLyUtwy0soi1hAJBkLeBs ZGFwLSciLoAq4VAtMDEuDNB0KIxJTCBqJsAFQG5vJ5BjuwmAJBRpBUARwAQgZyNSDwqwMaEk ICMAZXhwaRxyeSRgJEAjACgwMsAvOTgpLiAxUQPw/mwDICSRJqAIYAVAA1Izo5cRsTQgK+Bv B+B0bycRxRHxLzexdWJtMqEmgh5kN5AzsiNgCYBmdWyBNSNiZWxlaXYjAN8kICMhLcM20C9Q dAhwB5G3NqMjoi8AZS7gNSFBIzH3CHAkYAQAYybAAJAnsReA7m8JwQQQB5F3M0EgQSNB/zVg JXEmQiexMqE3gyAwBZD3M5QJwAhgcDwBAIAJ8DgwjzygKIwiwABwa3MhKOYXC0YW0QvyYw3g IC1VvnA0ECEgBgAFEAMAdi7g+wORCoVfRt9H70j/Sg9KhTUo5k8lIGM6MBoBcnAbBbAnhHw1 MAqFQm944CA2NTk1IIA1ME6FbHxQN0AjYDo0oE4gMKIpT7A2LTMgkDlOgd8q0C1UT3AmsUXE QEIBTMH9TEEuBaA2gCjmT7BFEEwVGFBrdzRATuJGYXjjURFPiDcxMhIgKOYqEH5kJWAEcAYA N0A7kk7TWEwuNFNAT3BjPSbAO30k4D0cMDowAMADEFgwcNY9UgRYMG9ZImc0cVgwDnNYAUXE TVdDQSA5f1egTiBOh07xTVdKj12AfP9dj1+vYL9LRCjmYigojCHdCwqFHIEAZdA= --=_ORCL_19993906_0r1-- --=_ORCL_19993906_0r0 content-type:message/rfc822 Date: 23 Apr 98 15:08:08 From:Jeff.Hodges@Stanford.EDU To:LDAP Replication Subject:proposals on the table? Cc:Steven Legg Reply-to:UNX11.US.ORACLE.COM:Jeff.Hodges@Stanford.EDU Return-Path: Received:from mailsun2.us.oracle.com by mailsun3 with SMTP (SMI-8.6/37.9) id PAA25226; Thu, 23 Apr 1998 15:16:40 -0700 Received:from inet16.us.oracle.com by mailsun2.us.oracle.com with ESMTP (SMI-8.6/37.8) id PAA10584; Thu, 23 Apr 1998 15:16:36 -0700 Received:from mail.proper.com (mail.proper.com [206.86.127.224]) by inet16.us.oracle.com (8.8.5/8.8.5) with ESMTP id PAA18894 for ; Thu, 23 Apr 1998 15:16:31 -0700 (PDT) Received:(from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id PAA02322 for ietf-ldup-bks; Thu, 23 Apr 1998 15:06:43 -0700 (PDT) Received:from Wind.Stanford.EDU (wind.Stanford.EDU [36.53.0.147]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id PAA02318 for ; Thu, 23 Apr 1998 15:06:43 -0700 (PDT) Received:from localhost (hodges@localhost) by Wind.Stanford.EDU (8.8.3/8.8.3) with ESMTP id PAA02579; Thu, 23 Apr 1998 15:08:08 -0700 (PDT) Message-Id:<199804232208.PAA02579@Wind.Stanford.EDU> X-Office:Pine Hall Rm 161; +1-650-723-2452 Sender:owner-ietf-ldup@imc.org Precedence: bulk MIME-Version: 1.0 Content-Type:text/plain; charset=us-ascii Content-Transfer-Encoding:7bit A question just raised on the conf call was "what are all the proposals on the table"? Here's what I see in my mail folder... Replication between LDAP Servers Mark Wahl, M.Wahl@innosoft.com Netscape Abstract John Merrells Joint Novell - IBM Abstract Ed Reed, Ellen Stokes Oracle Abstract Uppili Srinivasan Telstra Replication Proposal Steven Legg We should note, I think, that there's also this current I-D.. LDAP Multi-Master Replication Protocol expires May 20, 1998. ftp://ftp.ietf.org/internet-drafts/draft-ietf-asid-ldap-mult-mast-rep-02.txt Jeff --=_ORCL_19993906_0r0-- From owner-ietf-ldup Thu Apr 23 21:02:13 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id VAA04402 for ietf-ldup-bks; Thu, 23 Apr 1998 21:02:13 -0700 (PDT) Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.7.3) with SMTP id VAA04398; Thu, 23 Apr 1998 21:02:12 -0700 (PDT) Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Thu, 23 Apr 1998 22:03:08 -0600 Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Thu, 23 Apr 1998 22:01:51 -0600 From: "Anurag Srivastava" To: owner-ietf-ldup@imc.org, merrells@netscape.com, RWEISER@novell.com, USRINIVA@us.oracle.com Cc: ietf-ldup@imc.org, Alan.Lloyd@OpenDirectory.com.au Subject: Re: RE: Comments on ldup-replica-req-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: owner-ietf-ldup@imc.org Precedence: bulk Alan wrote : > Yes its a requirement - in X.500 the time limit for searches > when provided by users is "seconds" when propagated in DSP > its UTC = time + seconds for obvious reasons - this means that=20 > DSAs when performing distributed searches need some=20 > synchronised time source if time limit is to be honoured. > ditto goes with replication, if trying to maintain integrity of = deletes and renames in multimaster mode - see previous mail re value = judgment. I agree with the comments and would like to generalize the=20 requirement to capture the notion of QoS in general with the=20 directory operations, besides time synchronization, specially, wrt=20 searches, replication and synchronizations it is important. This=20 would then possibly raise other issues, like notification support,=20 etc. beside the time-synchronization.=20 For e.g., the replication requirement can state, atomic guaranteed =20 delivery to various replicas to ensure consistency and for that we=20 may require DSAs to support time-synchronization as well as some=20 sort of notification support. Would appreciate inputs.=20 Thanks & regards Anurag Architect, Novell India >>> Alan Lloyd 04/24/98 04:40AM >>> > -----Original Message----- > From: Russel Weiser [SMTP:RWEISER@novell.com]=20 > Sent: Friday, April 24, 1998 1:48 AM > To: owner-ietf-ldup@imc.org; merrells@netscape.com; > USRINIVA@us.oracle.com=20 > Cc: ietf-ldup@imc.org; alan.lloyd@OpenDirectory.com.au=20 > Subject: Re: Comments on ldup-replica-req-00.txt >=20 > John and Uppili=20 >=20 > A couple of things here that are of interest and 'd like to ducuss > further. > My comments are below=20 > =20 snip -=20 > Something that hasn't=20 > been discussed yet it the TIME Synchronization between servers > participating in a replication. =20 > This is something that should be addressed in the requirements I > guess.=20 >=20 Yes its a requirement - in X.500 the time limit for searches when provided by users is "seconds" when propagated in DSP its UTC time + seconds for obvious reasons - this means that DSAs when performing distributed searches need some synchronised time source if time limit is to be honoured. ditto goes with replication, if trying to maintain integrity of deletes and renames in multimaster mode - see previous mail re value judgment. regards alan > cheers=20 > RFW > > > > can you explain the scalability problem here? > > > > -Uppili Srinivasan > > > ______________________________________________________________________ > ______ > > Oracle Corporation | > > Box 659510 |Phone: (650)506-3039 Internet: > usriniva@us.oracle.com=20 > > > > 500 Oracle Pkwy |Fax: (650)506-7122 > > Redwood Shores |X.400: c=3Dus; a=3Dtelemail; p=3Doracle; o=3Doragat= e; > s=3Dusriniva > > > > CA 94065 | > > > ___________________|__________________________________________________ > ______ > > > > > > > > > > > ---------------------------------------------------------------------- > ---------------------------------------------------------- > > > > Subject: Re: Comments on ldup-replica-req-00.txt > > Date: 21 Apr 98 11:56:00 > > From: "John Merrells" > > Organization: Netscape Communications > > To: Alan Lloyd > > CC: ietf-ldup@imc.org=20 > > References: > > > > Alan Lloyd wrote: > > > > > Of course - its just that these servers just become > "normal" > > > users of the directory that must be authenticated and if one > changes the > > > credentials of a server in one server - how does that get into the > > > second - unless servers need to use their old credentials > depending if > > > they have replicated them or not... is this chicken and egg stuff. > > > > That hasn't been raised as a requirement either. An administrator's > > intention may indeed be to permanently or temporarily deny access to > > some other server. In any case, the administrators should sort it > out. > > > > > > > Does this mean changes to the LDAP RFC? > > > > > > > > Probably, in the form of new controls, and possibly extended > > > > operations. > > > > > > > > > You see replication needs to be initated by either > server > > > > and > > > > > replicas transferred in either direction so its either a > > > > bi-directional > > > > > LDAP server to server with transaction control and server > based > > > > > management and a lot of Gods help (this is not a religious > statement > > > > > ;-)) > > > > > > > > It could be a session in each direction. > > > With God in most cases it seems to be simplex - but I > realise it > > > is bothways with LDAP :-) see above. > > > > Alan, you've lost me with the God acronym. > > > > An LDAP Replication session could be implemented as one > bi-directional > > session, or two uni-directional sessions. > > > > > Protocol fields are easy to > > > write down . eg ip6 address is just 16 bytes - now try and deploy > it and > > > make it work as a global network. > > > > Um, LDAP Replication might require some extra controls to definethe > start > > and end of a replcation session. > > > > > Want to ask Oracle, Ingres or Sybase about transaction > locking > > > systems and deadlock issues? > > > > No, I've got a book all about it. > > > > An LDAP Replication protocol specifiction could mandate the use of > > transactions, but it's probably not essential that it does. > > > > > If they stay like DISP there is a chance of success - : -) > .. > > > existance proof is good. > > > > Is that documented in X.525? > > > > Are there any documents that address using DISP for multi-master > > directory topologies? > > > > > > So far, no one's suggested this as a requirement. > > > > > > > May I suggest a feature which......................... > > > > Are you suggesting identifying an entry as a master/shadow as > arequirement > > then? > > > > > > I'd wonder though... that if your application has real-time > > > > constraints then > > > > you probably don't want to store your data in some loosly > consistent > > > > store. > > > X.500 permits inconsistencies - but leaves the ops people > to > > > sort that out- but X.500 provides the services to always get the > master > > > entry just in case the ops people dont make it. > > > > Who are ops people? > > > > 'One of the master copies', seems no better than 'One of the replica > copies'. > > > > > > Also... if an entry is mastered by many servers... then you > won't know > > > > which server holds the 'correct' value anyway. So it doesn't > sound > > > > like > > > > this buys you much. > > > > > > > In X.500 one does via the information being tagged as > copies > > > (internally in the DSA because it arrived via DISP) - and with the > > > knowledge information in the replication agreements the replica > DSA > > > knows of the master - and the via DSP (distribution again - an > LDAP > > > deficiency) I can request of the replica I am connected to to go > to the > > > master via DSP to get it by specifying Dont Use Copy - all > seamlessly to > > > the user - you see replication and distribution in X.500 work > together. > > > In LDAP land all the parts arn't there yet. So replication on its > own is > > > very limited.... > > > > I think you're missing my point. Which of the master copies is the > onetrue > > correct copy? You'll just never know. > > > > > through replication agreements and using op attrs. > > > > > > The replication scaling problem is reduced with > distributed > > > directories in the first place. > > > > Reduced, but not elliminated. Say you have a set of N masters for an > > entry.Each server maintains an increasing counter which is > > used to tag attribute > > values as they're updated. These tags are then used to determine > which > > values are communicated to each of its peers. The question is: 'How > do > > you avoid each server having to know the highest tag value sent from > > each other server?' This seems to be the big scalability problem > for > > multi-master directories. How does X.500 solve this? > > > > John > > > > -- > > John Merrells > > Netscape Communications > > Directory Server > > Software Engineer > > > > http://people.netscape.com/merrells=20 >=20 >=20 >=20 > -- > John Merrells > Netscape Communications > Directory Server > Software Engineer >=20 > http://people.netscape.com/merrells=20 >=20 From owner-ietf-ldup Thu Apr 23 23:08:20 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id XAA10561 for ietf-ldup-bks; Thu, 23 Apr 1998 23:08:20 -0700 (PDT) Received: from att.com (cagw1.att.com [192.128.52.89]) by mail.proper.com (8.8.8/8.7.3) with SMTP id XAA10550 for ; Thu, 23 Apr 1998 23:08:17 -0700 (PDT) Received: by cagw1.att.com; Fri Apr 24 02:02 EDT 1998 Received: from i.control.att.com (root@i.control.att.com [135.205.52.126]) by caig1.att.att.com (AT&T/GW-1.0) with ESMTP id CAA06258 for ; Fri, 24 Apr 1998 02:09:32 -0400 (EDT) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Fri, 24 Apr 1998 02:09:31 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for ietf-ldup@imc.org; Fri, 24 Apr 1998 02:09:30 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Fri, 24 Apr 1998 02:09:30 -0400 (EDT) From: capple@master.control.att.com (Christopher W Apple) To: Jeff.Hodges@Stanford.EDU, LDAP Replication Subject: Re: Microsoft's participation? Sender: owner-ietf-ldup@imc.org Precedence: bulk I spoke with Paul Leach today. He was not included on the ldup-repl list for some reason. I've asked John Strassner to add him. ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Service Internet Directory Group http://www.anywho.com AT&T Labs capple@master.control.att.com +1 908 582 2409 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ From owner-ietf-ldup Fri Apr 24 01:14:22 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id BAA18454 for ietf-ldup-bks; Fri, 24 Apr 1998 01:14:22 -0700 (PDT) Received: from lancaster.nexor.co.uk (lancaster.nexor.co.uk [128.243.9.1]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id BAA18450 for ; Fri, 24 Apr 1998 01:14:19 -0700 (PDT) Received: from crusader.nexor.co.uk by lancaster.nexor.co.uk with SMTP (NEXOR MMTA 2.2); Fri, 24 Apr 1998 09:15:12 +0100 Received: by crusader.nexor.co.uk with Microsoft Mail id <01BD6F61.75E93310@crusader.nexor.co.uk>; Fri, 24 Apr 1998 09:15:01 +0100 Message-ID: <01BD6F61.75E93310@crusader.nexor.co.uk> From: Colin Robbins To: "'Russel Weiser'" , "merrells@netscape.com" , "USRINIVA@us.oracle.com" , "'Alan Lloyd'" Cc: "ietf-ldup@imc.org" Subject: RE: Comments on ldup-replica-req-00.txt Date: Fri, 24 Apr 1998 09:15:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sender: owner-ietf-ldup@imc.org Precedence: bulk > Yes its a requirement - in X.500 the time limit for searches > when provided by users is "seconds" when propagated in DSP its UTC = time > + seconds for obvious reasons - this means that DSAs when performing > distributed searches need some synchronised time source if time limit = is > to be honoured. X.500 does not need time synchronisation to perform DSP operations. =20 The UTC component in DSP is an optional parameter. If it is absent, a = directory should fall back to the relative time limit specified by the = user. This is how the NameFLOW-Paradise project operates, with over = 700 servers connected globally via DSP, a no time synchronisation. Other projects I have been involved in, for example the EMA Directory = Challenge, required the use of synchronised time servers. as the = absolute UTC time component was used. This cause no end of operation = problems, due to unexpected results when the time on a remote server = drifted out of synchronisation. Replication has a different issues and requirements, but can and does = work without synchronised time sources. I would recommend, from = practical experience, that replication should not require synchronised = time sources. (Note: This time limit in DSP is a UTC time i.e., 2 year date code - = Make sure your X.500 product has been millennium tested if you plan to = use synchronised DSP time!)=20 Colin From owner-ietf-ldup Sun Apr 26 19:04:16 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id TAA08734 for ietf-ldup-bks; Sun, 26 Apr 1998 19:04:16 -0700 (PDT) Received: from Wind.Stanford.EDU (wind.Stanford.EDU [36.53.0.147]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id TAA08730 for ; Sun, 26 Apr 1998 19:04:15 -0700 (PDT) Received: from localhost (hodges@localhost) by Wind.Stanford.EDU (8.8.3/8.8.3) with ESMTP id TAA11382; Sun, 26 Apr 1998 19:05:57 -0700 (PDT) Message-Id: <199804270205.TAA11382@Wind.Stanford.EDU> X-Mailer: exmh version 2.0.2 2/24/98 Subject: overall meta-requirements for LDAP replication To: ietf-ldup@imc.org cc: Jeff.Hodges@Stanford.EDU From: Jeff.Hodges@Stanford.EDU Reply-to: ietf-ldup@imc.org X-Office: Pine Hall Rm 161; +1-650-723-2452 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 26 Apr 1998 19:05:57 -0700 Sender: owner-ietf-ldup@imc.org Precedence: bulk Here's my shot at writing down the overall meta-requirements I called out in my review of draft-weiser-replica-req-01.txt. Yes, all the references are to the Bayou papers -- the intent, though, is to ~leverage~ their work, rather than strictly copy it. The Bayou papers provide a good amount of discussion of related & prior work, as well as extensive references, and careful analysis of pretty much the exact problem space we're discussing -- so we can use them as a starting point to investigate other possible approaches, if any seem particularly interesting. Also, they are a good guide to overall meta-requirements such as those below. Are there also similar papers citing actual useability and performance of the X.500 replication approach? I took a quick look thru the X.500 docs and the only place where I could find clear claims about replica consistency is in sections 11.3 & 11.4 of X.500(97,Rev0). It doesn't make any precise claims about whether the replication model provides weak or strong or in-between data consistency. Also, it doesn't indicate whether the update propagation paradigm is lazy or diligent or whatever. In [1] (section 7), the authors note that information about other weakly consistent replication systems is difficult to obtain. I queried Doug Terry directly to see if he has since learned of additional such references, but he said he hasn't. Also, I think that the reqs doc (and any resulting protocol docs) needs to make a clear delineation between "replication" and "distribution" (aka knowledge references), as does the referral doc(s), to help keep the distinction clear to readers. thanks, Jeff ---------------------------------------------------------------------------- 1. Client application synchronicity requirements "Synchronous" apps are where objects are shared at the same time [2]. Typically requires "strong" consistency between participant's views of the data at time of sharing. "Asynchronous" apps are where objects may be shared at various times, typically different times but perhaps the same. "Weak" data consistency is typically sufficient. Anticipated clients for LDAP-based directory services range from asynchronous (e.g. whitepages directories) to synchronous (e.g. network infrastructure services e.g. a DHCP backing-store). The LDAP replication architecture MUST accommodate asynchronous client applications and SHOULD accommodate synchronous applications. I.e. assume asynchronous apps as the general default and synchronous apps as somewhat special cases with more stringent requirements for data consistency. [aside: Note that the notion of synchronicity is a relative one. What level of latent time interval defines the line between "the same time" and "different times"? At what level of tight synchronicity requirements does the LDAP protocol and its informational and functional models become an inappropriate solution? In other words is an LDAP-based data store a reasonable choice in an environment having stringent requirements of sub-centi/millisecond consistency between replicas along with perhaps formal transactional semantics? In our experience at Stanford, we currently have a very lazy (read: downright slothful) level of consistency between the source "systems of record" (e.g. personnel's system & the registrar's system) and our current whitepages directory -- on the order of days. If we reduce the latency to 10s of minutes or perhaps a few hours, it'd seem "strong" to many folks. In fact, given our reasonably high-bandwidth network infrastructure, modern RDBMSs, and event-driven middleware, we'll easily get the latency down to a few minutes (targeted for this summer) and regard that as "acceptably strong" for our current applications. Latency on the order of some seconds would be quite "strong". Though, in the future we might well be regarding "a few minutes" as "pretty weak", as our expectations and perhaps legitimate requirements, are raised. Plus, it is entirely reasonable, and possible, to be concurrently using an LDAP-based directory in a non-witepages context (network management for instance) where latency on the order of some number of seconds might be regarded as pretty weak and something faster is needed. ] 2. Data consistency between replicas Given the requirement of supporting asynchronous applications across networks with arbitary characteristics in the general case, then lazily-propagated, weakly-consistent views of the data are sufficient [1][2][5][6][8]. It is simply required that all replicas move towards convergence in the default case. However, the anti-entropy process SHOULD have provisions for providing stronger data consistency to applications willing to incur the higher costs [4][8]. 3. Scalability LDAP replication must yield replicated directories that scale from a single autonomous server to many replicas operating over a network having indeterminant bandwidth, latency, and connectivity properties (e.g. the Internet). Thus it is important for these aspects of a replicated directory to be as independent as possible of the number of replicas [4][6].. cost of performing ops at a replica, where ops include.. reading data, writing data, propagating updates, creating/destroying replicas. amount of storage required at a replica 4. Availability LDAP replication MUST maximize availability in the default case. Nominally, a read-anywhere/write-anywhere (i.e. multi-master) architecture satisfies this requirement. The primary cost of this is the client's need to handle weakly-consistent data and the possibility of conflicting updates [4]. Again, client applications willing to incur the cost SHOULD(MUST?) be able to specify their needs for stronger data consistency and in return accept less availability [8]. E.g. they may not be able to make updates at any server, rather they may have to direct their writes to a "primary" or "authoritative" server(s). 5. Extensibility Client applications MUST(SHOULD?) be able to specify data consistency checks and conflict resolution procedures [1][2][4][5][6]. This facilitates the directory's functionality to evolve along with client applications. Additionally, the replicated directory SHOULD provide client applications the capability to request a range of "session guarantees" [8]. Session guarantees work to provide individual client applications views of the replicated directory that are consistent with their own actions, even if they read and write from various, potentially inconsistent servers. 6. Adaptability The replication process and the resultant replicated directory MUST be "adaptable" to varying client application requirements [1][4][5][6][7]. Examples of adaptability include.. having the concept of "wandering" authoritative replica(s) within an overall replicated directory. Authoritative replicas can provide stronger consistency guarantees and/or access to guaranteed "stable" data [1][5][7] (note: this type of replica is referred to as "primary" in the references); being able to dynamically create and destroy replicas over the life of a replicated directory [1][4][6]; being able to disconnect and reconnect replicas at will, including writing the replica while it is disconnected [1][5][6][7]; 7. Policy Flexibility The anti-entropy "update propagation" protocol and algorithm MUST allow for flexible policies for choosing reconciliation partners [1]. Another way to say this is the anti-entropy design must allow for arbitrary replicated directory topologies. Although, some topologies MAY have a higher "cost" associated with them in terms of update propagation latency and storage requirements. The system MUST provide for flexibility in deployment topologies (see 6 above). The system MUST(SHOULD?) provide for flexibility in terms of consistency and availability policies (see 4 & 5 above). 8. Security [3] presents an analysis of the security issues inherent in a replicated data store where replicas may be on arbitrary machines, including portable ones. Essentially, we not only have to worry about security of the anti-entropy sessions themselves, but also whether a replica may have been compromised and whether it is injecting poisoned (meta-)data into the overall replicated directory. We need to make the typical tradeoff of security vs. cost and inconvenience. 9. Replication Transport Requirements The replication system MUST be robust enough to run across a wide network link bandwidth range, e.g. dialup lines to gigabit, and over various transport protocols (e.g. TCP, TLS, etc) (is bulk transport via sneakernet a requirement? Can be a nice feature if it simply "falls out" in the design). [1] Anti-entropy sessions MUST be robust in the face of transport disconnection. Robust connotes no data corruption, replicas are still individually functional, etc -- i.e. their reconciliation simply didn't complete, and any writes fully communicated prior to the interruption hold. [1] --------------------------- References: [1] Karin Petersen, Mike J. Spreitzer, Douglas B. Terry, Marvin M. Theimer, Alan J. Demers. "Flexible Update Propagation for Weakly Consistent Replication". Proceedings of the 16th ACM Symposium on Operating Systems Principles (SOSP-16), Saint Malo, France, October 5-8, 1997, pages 288-301. [2] W K Edwards, E D Mynatt, Karin Petersen, Mike J. Spreitzer, Douglas B. Terry, Marvin M. Theimer. "Designing and Implementing Asynchronous Collaborative Applications with Bayou". Proceedings of the Tenth ACM Symposium on User Interface Software and Technology (UIST), Banff, Alberta, Canada, October, 1997. [3] Mike J. Spreitzer, Mike J. Spreitzer, Karin Petersen, Alan J. Demers, and Douglas B. Terry. "Dealing with Server Corruption in Weakly Consistent, Replicated Data System". Proceedings of the Third Annual ACM/IEEE International Conference on Mobile Computing and Networking (MobiCom '97), Budapest, Hungary, September 1997. [4] Karin Petersen, Mike J. Spreitzer, Douglas B. Terry, and Marvin M. Theimer. "Bayou: Replicated Database Services for World-wide Applications". Proceedings of the Seventh ACM SIGOPS European Workshop -- Systems Support for Worldwide Applications, 9-11 September 1996 - Connemara, Ireland. [5] Douglas B. Terry, Marvin M. Theimer, Karin Petersen, Alan J. Demers, Mike J. Spreitzer, and Carl H. Hauser. "Managing Update Conflicts in Bayou, a Weakly Connected Replicated Storage System". Proceedings of the 15th ACM Symposium on Operating Systems Principles (SOSP-15), Copper Mountain Resort, Colorado, December 3--6, 1995. [6] Alan J. Demers, Karin Petersen, Mike J. Spreitzer, Douglas B. Terry, Marvin M. Theimer, Brent B. Welch. "The Bayou Architecture: Support for Data Sharing among Mobile Users". Proceedings of the Workshop on Mobile Computing Systems and Applications, Santa Cruz, California, December 1994, pages 2--7 (IEEE Computer Society Press). [7] Marvin M. Theimer, Alan J. Demers, Karin Petersen, Mike J. Spreitzer, Douglas B. Terry, Brent B. Welch. "Dealing with Tentative Data Values in Disconnected Work Groups". Proceedings of the Workshop on Mobile Computing Systems and Applications, Santa Cruz, California, December 1994, pages 192--195 (IEEE Computer Society Press). [8] Douglas B. Terry, Alan J. Demers, Karin Petersen, Mike J. Spreitzer, Marvin M. Theimer, Brent B. Welch. "Session Guarantees for Weakly Consistent Replicated Data". Proceedings International Conference on Parallel and Distributed Information Systems (PDIS), Austin, Texas, September 1994, pages 140-149 (IEEE Computer Society Press). From owner-ietf-ldup Sun Apr 26 18:59:22 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id SAA08700 for ietf-ldup-bks; Sun, 26 Apr 1998 18:59:22 -0700 (PDT) Received: from Wind.Stanford.EDU (wind.Stanford.EDU [36.53.0.147]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id SAA08696 for ; Sun, 26 Apr 1998 18:59:21 -0700 (PDT) Received: from localhost (hodges@localhost) by Wind.Stanford.EDU (8.8.3/8.8.3) with ESMTP id TAA11354; Sun, 26 Apr 1998 19:00:59 -0700 (PDT) Message-Id: <199804270200.TAA11354@Wind.Stanford.EDU> X-Mailer: exmh version 2.0.2 2/24/98 Subject: Re: draft-weiser-replica-req-01.txt To: ietf-ldup@imc.org cc: Jeff.Hodges@Stanford.EDU From: Jeff.Hodges@Stanford.EDU Reply-to: ietf-ldup@imc.org X-Office: Pine Hall Rm 161; +1-650-723-2452 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 26 Apr 1998 19:00:58 -0700 Sender: owner-ietf-ldup@imc.org Precedence: bulk Here's my detailed comments on draft-weiser-replica-req-01.txt. Thanks to Russel & Ellen for all their work on it. Jeff some of my mark-up terminology... req = requirement "s/b" = "should be" ----------------------------------------------------------------------------- Overall comments: 1. John Merrells' restating of the reqs in his msg entitled "Requirements Categorisation" of Wed, 15 Apr 1998 17:30:01 -0700 has nice, concise reqs statements. I suggest that the doc utilize those, or statements like them, for titles for the reqs, and then provide additional text where necessary for explanation. 2. High level, overall system reqs are assumed or implied rather than stated. These are.. a. level of synchronicity of anticipated client apps? b. required level of data consistency between replicas? c. operational semantic requirements The first two perhaps should be addressed in a separate section before the "replication model" one, and the third should be addressed in the replication model section. 3. We should also state and assign requirement levels to the overall meta-requirements of.. scalability availability extensibility adaptability flexibility security replication transport protocols This should be in a very early section of the doc, perhaps in the same one or prior to the one with items from #2 above. ----------------------------------------------------------------------------- INTERNET-DRAFT Russel Weiser Informational Draft Novell, Inc. Expires 13 October 1998 Ellen Stokes IBM 13 April 1998 LDAP Replication Requirements Status of this Memo This document is an Internet-Draft. 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 entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document discusses the fundamental requirements for replication of data accessible via the LDAPv3 [RFC2251] protocol. It is intended to be a gathering place for general replication requirements needed to provide interoperability between informational directories. The key words MUST MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. It's a nit, but I don't think this rfc2119 stuff belongs in the abstract -- the abstract gets copied out to different places and such, and such document conventions stuff isn't meaningful unless you're reading the doc as a whole. Weiser & Stokes 13 October 1998 [Page 1] INTERNET-DRAFT LDAP V3 Replication Requirements 13 April 1998 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Applicability Statement . . . . . . . . . . . . . . . . . . . . . 5 5. Replication Model . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Replication Protocol . . . . . . . . . . . . . . . . . . . . . . . 7 7. Replication Predetermined Agreements . . . . . . . . . . . . . . . 8 8. Administration and Management Considerations . . . . . . . . . . . 8 9. Other for furhter discussion or the garbage heap . . . . . . . . . 9 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 12. Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 Weiser & Stokes 13 October 1998 [Page 2] INTERNET-DRAFT LDAP V3 Replication Requirements 13 April 1998 1. Introduction The ability to distribute directory information throughout the network provides a two fold benefit to the network: (1) increasing the reliabililty of the directory through fault tolerance, and (2) brings the directory content closer to the clients using the data. LDAPs acceptance as a access protocol for directory information is driving the need to distribute LDAP directory content among servers within enterprise and Internet. Currently LDAP does not define a replication mechanism and only generally mentions LDAP shadow servers (see [RFC2251] and [Changelog]) in passing. The requirements for replication are critical to the successful deployment and acceptance of LDAP in the market place. 2. Terminology For the purposes of this document, the following definitions are used: Replication - The process of copying portions of naming context ^^^^^^^^^^^^^^ What's a "naming context" (rhetorical question)? We should either define it in this doc or provide a ref to where it is defined. Perhaps the former if we're trying to minimize references to X.500 docs. information and content, between multiple LDAP servers, such that certain, predefined portions of the information are available from many geographic locations. that which is done between either ^^^^^^^^^^^^^^^^^^^^^^^^^ Nit: perhaps should be "different servers", or "topologically different locations". homogeneous implementations across heterogeneous platforms (operating systems) or heterogeneous implementations supporting identical replication across heterogeneous platforms (operating systems). No mapping mechanisms are required here. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The key seems to be the latter stmt. Synchronization - The process whereby LDAP servers participating in the replication, are brought into a state where copies of the information they make accessible are consistent with the other. that which happens between heterogeneous directory servers onheterogeneous platforms (operating systems). The different directory server implementations do not have to provide an LDAP interface. One could certainly define a wire protocol. The mapping of data means mapping of attributes. For example, in one system, the attribute is full name, in the other it is common name We agreed during the conf call to not utilize or define the term "synchronization". (conf call: there was a conference call on Thur 16-Apr among those proposing specific replication approaches, and the reqs doc was discussed in fair detail). Incremental Update - The process of updating a replica, or copy, of a naming context, by updating only those fields or objects which have changed. Master Replica - A writeable copy of the replicated information. Slave Replica - A read-only copy of the replicated information. We agreed during the conf call to come up with another set of names for various replica flavors. Multi-Master Replication - A replication model where entries can be written and updated on any of several replica copies, without requiring communication with other masters before the write or update is performed. Another term for this is "read-anywhere/write-anywhere". Weiser & Stokes 13 October 1998 [Page 3] INTERNET-DRAFT LDAP V3 Replication Requirements 13 April 1998 Master Slave, or Single Master Replication - Replication model that assumes only one server, the master, allows write access to the replicated data. Note that Master-Slave replication can be considered a proper subset of multi-master replication. One-way Directory Synchronization - The process of synchronization ^^^^^^^^^^^^^^^ s/b replication (change throughout doc) in a single direction where the authoritative source information is provided to a replica. Two-way Directory Synchronization - The process of synchronization where change information may flow bidirectionally between two replicas. Need to add definitions for (and/or agree to equivalent terms for).. anti-entropy, update propagation, etc. -- are names and/or descriptions for the algorithmic, protocol-based process by which directory replicas are reconciled. Authoritative replica -- a replica containing complete replicated areas which contain complete entries. fractional replication -- The capability to replicate a subset of attributes of any given entry. partial (sparse?) replication -- The capability to replicate one or more subsets of a given DIT. These subsets are synonymous with "replicated areas" in X.525. replica -- an instance of a replicated directory. partial | sparse | fractional replica -- a replica that receives fractional and/or partial(sparse?) data. replicated directory -- a directory whose DIT is, or portions thereof are, replicated across more than one server. Sometimes referred to as simply "directory" in this doc. topology - as in "the replicated directory's topology". Refers to the shape of the directed graph describing the relationships between replicas. Note: section 2.1 of draft-ietf-asid-ldap-mult-mast-rep-02.txt should be merged into this section. 3. Objective The major objective is to provide an interoperable LDAP V3 directory synchronization protocol which is simple, highly efficient and flexible enough to support both Multi-master and Master-slave replication operations to meet the needs of both the Internet and enterprise environments. Are you referring to the overall goal of the ldap replication design & specification effort, or of this doc? The statement is ok if you mean the former, but not really if you mean the latter. It seems to me that the goal statement for this doc is something like.. "The goal of this document is to enumerate and organize the overall set of requirements for LDAP replication." 4. Applicability Statement TBD 5. Replication Model 5.1 LDAP Replication MUST be allowed to span different vendors directory services in order to provide interoperability. This is "by definition" of an IETF protocol spec. Doesn't seem to be a req to me. 5.2 All replicas MUST eventually be updated with the changed information, specified by the replication policy. This seems to be in direct conflict with 5.7. I'd say that this req is the correct one -- but I'm going to raise the topic of what level of consistency we're designing for in a separate msg. 5.3 Replication schedules MUST be dynamic to allow for periodic replication, with the replication period determined by administrator of the replicated system. perhaps "MUST facilitate administrator-specified replication schedules"? 5.4 Replication Model SHALL enable replication cycle to initiated based in the number of pending changes. perhaps "count of pending changes" should be added to a required list of various metrics for replication scheduling policy. 5.5 The replication model SHOULD allow for initiation of replication cycle for any replica that may have just come back online or was unavailable previously. perhaps "MUST support intermittent replica connection", or "MUST support replica disconnection and subsequent reconnection". Note that disconnection might be voluntary, as in the case of a replica hosted on a mobile system (laptop, palmtop, wristband (did you see the Seiko wristwatch-computer announcement?)), or it might be involuntary as in the case of any networked system. 5.6 The replication model MUST support the both master-slave and multi-master replication topologies. ^^^^^^^^^^ I don't think these are properly topologies -- rather they connote the relationship between a pair of replicas. Weiser & Stokes 13 October 1998 [Page 4] INTERNET-DRAFT LDAP V3 Replication Requirements 13 April 1998 5.7 All replicated information between the master database and its replica databases SHALL be identical including all no user modify operational attributes such as time stamps. Note this does not imply that the entire database is identical from replica to replica, but that the subset of data, chosen to replicate is identical from replica to replica. This is in direct conflict with 5.2. It seems to be a requirement for strong consistency within relatively short time frames. 5.8 Distributed multi-vendor environment, LDAP replication SHALL NOT ensure all copies of the replicated information be ^^^^^^ require complete copies of the replicated object. Perhaps "Fractional replication MUST be supported." 5.9 Replication MUST allow Definition content of replicated information. I'm not sure what this means or is for. 5.10 LDAP replication SHALL encompass common schema objects and attributes, access control and name spaces. Perhaps "All non-directory-system-specific data contained in a directory MUST be a candidate for replication". We probably need to define terms that'll allow us to succinctly describe "non-directory-system-specific data" (everything other than the root DSE?) and "directory-system-meta-data" (this intersects with the root DSE (correct?), but is it necessarily congruent?) 5.11 Sub tree Replication SHALL be defined to allow for greater flexibility replication topologies of the DIT as discussed in X.525 section 7.2 [X.525]. Axe as discussed in conf call. 5.12 A propagation schedule SHALL be defined and SHOULD be tunable within Predetermined replication agreement. This should be combined with 5.3. 5.13 Replication of critical values SHALL be synchronized with priority over non critical values, an example of a critical value might be a password and or certificate value which maybe considered critical. What defines "critcal values"? The ldap protocol presently doesn't support such a concept, so it needs to defined in this doc. Perhaps the desired req is "replication algorithm MUST assign a higher replication priority to critical data" and then we'd need a definition of critical data and a req for being able to denote data as critical (I note that X.525(97) sec 9.2.4.1 makes a similar claim in regards to ACI info, is that essentially where this req came from?) I'm not convinced that this req is a MUST or is needed in terms of having such a distinction among data ~in general~. I have a hunch that the needs this would be satisfying would probably be better satisfied by being able to provide relatively strong consistency among replicas to applications desiring it. However, I can see where it ~might~ work out to be desirable for system meta-data as the X.525 ref above states. Something to think carefully about. 5.14 Currently X.525 DISP [X.525] discusses this as a shadowing agreement including such information as unit of replication, update mode, and access point defining many of the policies between the master and a replica. The use of predetermined replication agreements between the directory replicas MUST be addressed to provide proper knowledge of access requirements and credentials between the synchronizing directories. Not clear what this is addressing. Please restate more clearly. Is it here because something akin is in X.525? 5.15 Due to the acceptance and usage of the Internet, and the requirement that LDAP replication be available across disparate vendors directory services, LDAP replication MUST provide scalability for both enterprise and internet environments. This is a meta-requirement of scalability. should be addressed early in the doc with other meta-reqs. 5.16 The replication model MUST define deterministic policy such that replication cycle startup time conflicts between two or more competing master replicas may be resolved programmatically. An Example might be automatic submission and rescheduling by one of the masters. In such a case, these replication "conflicts" SHALL be resolved by the replication policy. Not clear to me what this is requiring. Perhaps "there MUST be the capability to specify conflict resolution policies for replication agreements themselves."? Weiser & Stokes 13 October 1998 [Page 5] INTERNET-DRAFT LDAP V3 Replication Requirements 13 April 1998 5.17 Replication SHALL be allowed to any LDAP server available on the network; provided appropriate security authorization is granted. Lots of complexities to this, and am not sure what this is necessarily implying. Is it something akin to "any two servers (impl'd to satisfy these reqs), which are able to communicate via LDAP across a network of indeterminate scale, SHALL be capable of carrying out an anti-entropy session, subject to administrative controls in place at either or both server."? 6. Replication Protocol 6.1 The act of replication MUST have minimal impact on both the system and network performance. This is a meta-requirement or overall design goal. 6.2 The replica synchronization MUST be handled in such a manner as to not saturate network with repetitive entry replication from multiple synchronization providers points. This is a meta-requirement or overall design goal. 6.3 Replication SHALL only be allowed after the authentication and verification of authorization of both the replica and the source directory. Perhaps "Establishment of replication (anti-entropy) sessions is subject to auth and authz requirements specified in subsection ?.?" We need to specify that subsection and those reqs. 6.4 The transport for LDAP synchronization MUST allow for the integrity and confidentiality of each replicated server. This is one. 6.5 Replicated data MUST be transferred in a secure manner. This is another. 6.6 Replication protocol MUST provide for recovery and rescheduling of a replication cycle due to update conflict and or loss of conncetion These are two separate reqs as update conflict and connection loss are orthogonal. Loss of connection is already covered by 5.5. Thus perhaps "the repl protocol MUST provide for update conflict resolution". I'd lobby to enhance it to: "the repl protocol MUST provide for application-specificed conflict resolution procedures." 6.7 LDAP replication MUST allow for full update to facilitate replica initialization and reset loading utilizing a standardized LDIF [LDIF] format. This is two separate reqs. One is "the means of conveying writes among replicas is LDIF-based (and standardized)", the other is "one must be able to create new replicas". 6.8 The normal means of synchronizing replicas SHALL be performed through incremental synchronization and in accordance with the scheduling policies. Is this implying that there are abnormal means? Should talk about them if so. Otherwise this item is stating the obvious. Unless we are going to define/require different classes of replication, e.g. "incremental", we shouldn't use such terms. 6.9 The replication Standard SHOULD NOT limit the size of a replica. Ok. The unit of replication is defined to be the naming context. -> terminology as discussed in conf call. Incremental replication SHOULD be allowed to attempt to keep the amount of data replicated to a minimum. What is incremental repl? Is the concern bandwidth requirements? We should figure out what this is or it should probably go away. 6.10 Must allow updates to multiple replicas Does this mean that a given replica MAY be paired with more than one other replicas? 6.11 The replication protocol MUST allow either a master or replica to initiate the replication process. 6.12 Additionally the initiator MUST be allowed to determine whether it will become a consumer or supplier during the synchronization startup process. This would allow a replica to be periodically connected and synchronized from remote sites at the local administrator's discretion. If there are no practical reasons to differentiate between consumers and suppliers in the replication process then this req goes away. It may well turn out that having an identifiable "supplier" and a "consumer" in a given pair-wise replication process is a special case of a more general one (which is a mutual, pair-wise update between peers). Weiser & Stokes 13 October 1998 [Page 6] INTERNET-DRAFT LDAP V3 Replication Requirements 13 April 1998 6.13 Multiple LDAP changes, to a single server, SHOULD be allowed to be treated as single atomic unit of work propagated during replication. Is this really a potential implementation approach for satisfying the more general requirement to "not waste bandwidth"? Perhaps should be restated if so. 6.14 An LDAP Replication Standard SHOULD NOT limit the transaction rate of a replication session. Of course. Perhaps this is a non-req we shouldn't mention. 6.15 Entry change information SHALL be purged upon completion of a synchronization cycle where all replica members have been synchronized with the master(s). This depends on how the anti-entropy (nee replication) algorithm is developed. It may be that replicas decide on their own when to trim their change log. 7. Replication Predetermined Agreements Russel noted this is being renamed "..schema.." 7.1 The Replication Protocol documents MUST define a standard schema for representing replication agreements, and MUST define the semantics associated with modifying the attributes of replication agreements. The documents MUST also define a standard method for determining the location of these agreements. 7.2 The Replication Protocol documents MUST define a standard schema for publishing state information about a given replica, and MUST define a standard method for determining the location of this information. This state information MUST include the ID of the last update propagated to the replica. The format of this ID is to be determined. 7.3 Location independent management point SHALL be defined to provide authorized administrators with well known access to the replication policies, regardless of network location. 7.4 Policies for the LDAP replication shall be defined in such a manner as to allow programmatic representation; these policies SHALL be kept as replica attributes or as entries of the predetermined agreement and propagated during replication. 7.5 Replication agreements SHALL be accessible, via LDAP, to all servers containing replicated information. The above stuff looks ok..have to think more about it. 8. Administration and Management Considerations 8.1 Replication policies SHALL allow replication of changed information to be postponed to a more convenient period , 8.2 Allowance for non scheduled replication of a replica SHALL be provided upon request such that the replica server has been down or unconnected for a period of time. Perhaps "There needs to be some way to initiate updating a replica that has been disconnected. There might be a range of ways: automatic, admin initiation, etc." 8.3 Each copy of a replica MUST maintain audit history of who it has replicated with and who has replicated with it. Architecture/implementation feature. Perhaps should be a "SHOULD". Weiser & Stokes 13 October 1998 [Page 7] INTERNET-DRAFT LDAP V3 Replication Requirements 13 April 1998 8.4 A replica MAY store the conflicted versions of the replicated object to allow optional human review and intervention. Architecture/implementation feature. 8.5 Access to replication predetermined agreements, topologies, and policies attributes MUST be provided through LDAP access. 8.6 The capability to check the differences between two replicas be of the same information SHOULD be provided for. Architecture/implementation feature. 8.7 The capability to view the current state and replication history of each replicated copy in the replication topology, from a single server in the topology. An architecture/impl feature that may easily materialize depending on how the overall replication algorithm/protocol works. Perhaps another way to state it: "capability to assess the current state and replication history of each directory replica from a (any?) other given replica in the replicated directory. 8.8 The ability to view replication conflicts, and override the resolution derived by the replication policy SHALL be provided. Architecture/implementation feature. 9. Other for furhter discussion or the garbage heap 9.1 It is not realistic to assume that all vendors have cooperating schemas, but it is required that different vendors schemas allow replication from diverse schemas. and MAY define a model whereby divergent schemas can replicate non-common or extended attributes for common LDAP objects. Are we trying to encourage or discourage schema (di|con)vergence? 9.2 Propagation behavior defines the general behavior of the actual synchronization process between a consumer and a provider of replication information. MOve to definitions. 9.3 Entry Identifiers SHALL be defined Ref Christopher Apple. 9.4 Replica convergence and resurections of attributes and objects; since( tombestones, Obituaries, deathwarrants, graveyards) are used I?ll add one more ZOMMBIES. RFW 9.3 & 9.4 discussed during conf call. 10. Acknowledgement This document is based on input from IETF members interested in LDAP replication 11. References [RFC2251] M. Wahl, T. Howes, S. Kille "Lightweight Directory Access Protocol (v3), Standards Track , December 1997 . Availiable as RFC2251 [RFC2119] S.Bradner, " Key words for use in RFCs to indicate Requirement Levels", RFC 2119. [LDIF] Gordon Good, "The LDAP Data Interchange Format (LDIF)", Internet draft, draft-ietf-asid-ldif-00.txt, November 1996. Weiser & Stokes 13 October 1998 [Page 8] INTERNET-DRAFT LDAP V3 Replication Requirements 13 April 1998 [Changelog] Gordon Good, "Definitions of an Object Class to Hold LDAP Change records", Internet Draft, draft-ietf-asid-changelog-00.txt, November 1996. [X.525] "Information Technology - Open Systems Interconnection- The Directory: Replication", ITU-T Recommendation X.525 and ISO/IEC International Standard 9594-9, November 1993. 12. Author's Address Russel F. Weiser Novell Inc. 122 East 1700 South Provo, Utah 84606 USA E-mail: Rweiser@novell.com Telephone: +1-801-861-7808 Fax +1-801-861-2292 Ellen J. Stokes IBM 11400 Burnet Rd. Austin, Texas 78758 USA E-mail: stokes@austin.ibm.com Telephone: +1-512-838-3725 Fax: +1-512-838-0156 Weiser & Stokes 13 October 1998 [Page 9] From owner-ietf-ldup Tue Apr 28 13:14:58 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id NAA24914 for ietf-ldup-bks; Tue, 28 Apr 1998 13:14:58 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.23]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id NAA24910 for ; Tue, 28 Apr 1998 13:14:58 -0700 (PDT) Received: by INET-03-IMC with Internet Mail Service (5.5.1960.3) id ; Tue, 28 Apr 1998 13:16:49 -0700 Message-ID: <5CEA8663F24DD111A96100805FFE6587031E3EEA@red-msg-51.dns.microsoft.com> From: Paul Leach To: LDAP Replication Subject: Repl requirments comments Date: Tue, 28 Apr 1998 13:16:39 -0700 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ietf-ldup@imc.org Precedence: bulk So, I'm now here, and I've managed to catch up a bit (so forgive me if I accidently tread trodden ground). I don't see anywhere in the requirements spec what I thought the number one customer requirement would be -- that replicas be _able_ to be 100% completely faithful totally functional clones of one another (although perhaps out of date) (An aside -- being customers they would really rather have it completely consistent and always available for updates too, even though that's impossible). Let me call this the "perfect copy" model, for short. The reason for their desire is simple: what customers always say they want is to be able to have an environment where they've got all their DS replicas from Vendor A, and when Vendor A's prices or performance or whatever starts to annoy them, go out and buy a DS from vendor B and plug it in, and it just works exactly like those from vendor A -- even when all of vendor A's replicas happen to be down or inaccessible. The "perfect copy" model is what I think customers mean by "replication", and the multivendor interop and interchangability is what I think they expect from a replication "standard". I know for a fact that if Vendor A happens to be Microsoft and we say we support the replication standard, and the customer can't bring in vendor B as above, we'll take 20 tons of sh*t. And, these days, they'll write their Senator in addition. So, if there is no intent to provide the perfect copy model, then I strongly suggest we don't call it "replication". Comments? Paul From owner-ietf-ldup Tue Apr 28 13:38:18 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id NAA25104 for ietf-ldup-bks; Tue, 28 Apr 1998 13:38:18 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.29]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id NAA25100 for ; Tue, 28 Apr 1998 13:38:17 -0700 (PDT) Received: by INET-04-IMC with Internet Mail Service (5.5.1960.3) id ; Tue, 28 Apr 1998 13:40:08 -0700 Message-ID: <5CEA8663F24DD111A96100805FFE6587031E3EEB@red-msg-51.dns.microsoft.com> From: Paul Leach To: "'ietf-ldup@imc.org'" Subject: LDAP replication requirements [virtual attributes] Date: Tue, 28 Apr 1998 13:40:04 -0700 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ietf-ldup@imc.org Precedence: bulk Let me be so bold as to assume that we agree that customers want what I called "perfect copy" replication. (After some reflection I think I'll change the name, though -- "perfection" implies too much and be misleading -- how about I call it "total replication".) To do total replication, we would need a bunch of things from the replication protocol. I'm going to put each item in a separate message, to make commenting easier. Support for "virtual attributes" Example: we have user objects in the directory, and we have group objects. User objects have a "member-of" property. That property is _not_ stored -- for any user object, it is computed dynamically by searching all the group objects for ones that contain that user object. Thus, updating a group object will cause a side effect of changing the values on some user object. There are lots of other instances if the utility of this kind of bahavior: the "reports-to" and "manager-of" properties of managers and the employess that report to them, for example. The knowledge of the relationship between these properties is not captured or capturable with the current schema mechanism. It has to be understood "a-priori" by each replica. So, the representation of schema would need to be enhanced to support replication of virtual attributes. Paul From owner-ietf-ldup Tue Apr 28 14:49:28 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id OAA25654 for ietf-ldup-bks; Tue, 28 Apr 1998 14:49:28 -0700 (PDT) Received: from inet16.us.oracle.com (inet16.us.oracle.com [192.86.155.100]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id OAA25650 for ; Tue, 28 Apr 1998 14:49:27 -0700 (PDT) Received: from mailsun3 (mailsun3-fddi.us.oracle.com [144.25.88.135]) by inet16.us.oracle.com (8.8.5/8.8.5) with SMTP id OAA27638 for ; Tue, 28 Apr 1998 14:50:09 -0700 (PDT) Received: by mailsun3 (SMI-8.6/37.9) id OAA04577; Tue, 28 Apr 1998 14:50:10 -0700 Message-Id: <199804282150.OAA04577@mailsun3> Date: 28 Apr 98 14:49:10 -0700 From: "Uppili Srinivasan" To: ietf-ldup@imc.org Subject: Re: LDAP replication requirements [virtual attributes] X-Orcl-Application: InterOffice Version4.1.2.10.50 MIME-Version: 1.0 X-Mailer: Oracle InterOffice (version 4.1.2.12.0) content-type: multipart/mixed; boundary="=_ORCL_7874122_0r0" Sender: owner-ietf-ldup@imc.org Precedence: bulk --=_ORCL_7874122_0r0 content-type:multipart/alternative; boundary="=_ORCL_7874122_0r1" --=_ORCL_7874122_0r1 Content-Type:text/plain; charset="iso-8859-1" Content-Transfer-Encoding:quoted-printable Paul: I would like to see this notion standardized. We refer to them as "dynamically evaluated attributes" or "computed operational attributes". Another example is the "leaf level members" of groups where the groups can be nested. But, I would think that "total replication" cannot be assumed. So even if the semantics is supported on all nodes, these attributes are not guaranteed to compute to the same value. We should probably try to agree on a schema representation such that it has no bearing on replication. -Uppili Srinivasan ____________________________________________________________________________= Oracle Corporation | Box 659510 |Phone: (650)506-3039 Internet: usriniva@us.oracle.com 500 Oracle Pkwy |Fax: (650)506-7122 Redwood Shores |X.400: c=3Dus; a=3Dtelemail; p=3Doracle; o=3Doragate; s= =3Dusriniva CA 94065 | ___________________|________________________________________________________ --=_ORCL_7874122_0r1 Content-Type:application/x-compressed-rtf Content-Transfer-Encoding:base64 VwMAALYFAABMWkZ1eG7cWv8ACgEPAhUCpAPkBesCgwBQEwNUAgBjaArAc2V0bjIGAAbDAoMy BEYRlzFuIAhVB7ICgzMTDxQfZhY0BEcUPjUVSHBycTkWX2Y2A8UZoxIic3R0ZW0CgH0KgAjP Cdk7+R1SMjUZEB27HIENogtgYG5nMTAzFTALA2z4aTE4DfAFECFCC1UXcQBzMTcgUGF1bBg6 ICAKhQqFSSB3EQhgbGQgISBrZSBYdG8gEfAkwWgEACBwbm90aQIgJQABkG5SZAsRaXoJgC4j EFd7JMAdYGYUgSThJVAcQCACYQQgImR5bmFtBGljB0BseSBldrkHQHVhHDAkcClgdAUQRGJ1 HDBzIiAFsSKZBaBtcCoRJHBvcASQ3ylgJdEHQCmqJtFBJaEn0PkFwGV4KIALUCTAJXEnwbMo MC2wYWYkgCkQZQMgfweABtAEkCpCLpAJwAhgcP0EIHctISUyJMAv1SiwA6CvL0AlkAeQKXEu IzxCKhDmLCQHJVFuayVBKWAoMP8k4AGQAyAdYAtQKKElwipQzzFRJaExgigQc3UHgCbC/lMk 8C7BA6AGkC4DEfADgZ0lwGMEICVxNpBwcB0B3ysSA6AowSWRDbBzM0Anwd8R8CmpKAAwcTYC ZylQK3D/AjAJ4DPBJPAqtSeFJQAogJskwCkiZTItJwFzaCRD+RnAb2IBoCjhKdBAUSTw/mEJ wjljJQARsDgRNPIdYL8R8AIwK4M4wRGwNDRpBUDfEcAlgjGBCsALgGc5YjUJLzItC0YZEQvy Yw3gIC22VTjwAxBpBgBEYWkpIPc9sAOgCoVfSV9Kb0t/TI9rTQUjJk8rcGMtsQhQcgs5AUKU fCMXQm94IHA2NTk1IIAjEFEFfC5QP4AxwCMAKFCgMClRUjA2LTMgkDlRAUlPPDEEoBIAIwF1 c0hEQO1TwC5PQU7BLiqxIxdSMGNHkE6VUGt3KPBRYkaMYXgjAVIINzEyEiD9IyZSCYAkMARw BgA/gEIxMVFEWC40VcAjAGM99VPAOygAPRwwLbAAwAMQWVqwcD1UhFqwb1uiZzspYVqwc1qB SEQjF0NB/CA5WiBQoFEHUXEjF00P/WAAfGAPYi9jP03EIyZkqC9FryIKCoUcgQBoUA== --=_ORCL_7874122_0r1-- --=_ORCL_7874122_0r0 content-type:message/rfc822 Date: 28 Apr 98 13:40:04 From:Paul Leach To:"'ietf-ldup@imc.org'" Subject:LDAP replication requirements [virtual attributes] Return-Path: Received:from inet16.us.oracle.com by mailsun3 with ESMTP (SMI-8.6/37.9) id NAA28700; Tue, 28 Apr 1998 13:51:47 -0700 Received:from mail.proper.com (mail.proper.com [206.86.127.224]) by inet16.us.oracle.com (8.8.5/8.8.5) with ESMTP id NAA09767 for ; Tue, 28 Apr 1998 13:51:41 -0700 (PDT) Received:(from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id NAA25104 for ietf-ldup-bks; Tue, 28 Apr 1998 13:38:18 -0700 (PDT) Received:from mail4.microsoft.com (mail4.microsoft.com [131.107.3.29]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id NAA25100 for ; Tue, 28 Apr 1998 13:38:17 -0700 (PDT) Received:by INET-04-IMC with Internet Mail Service (5.5.1960.3) id ; Tue, 28 Apr 1998 13:40:08 -0700 Message-ID:<5CEA8663F24DD111A96100805FFE6587031E3EEB@red-msg-51.dns.microsoft.com> Sender:owner-ietf-ldup@imc.org Precedence: bulk MIME-Version: 1.0 Content-Transfer-Encoding:quoted-printable Content-Type:text/plain; charset="iso-8859-1" Let me be so bold as to assume that we agree that customers want what I called "perfect copy" replication. (After some reflection I think I'll change the name, though -- "perfection" implies too much and be misleading -- how about I call it "total replication".) To do total replication, we would need a bunch of things from the replication protocol. I'm going to put each item in a separate message, to make commenting easier. Support for "virtual attributes" Example: we have user objects in the directory, and we have group objects. User objects have a "member-of" property. That property is _not_ stored -- for any user object, it is computed dynamically by searching all the group objects for ones that contain that user object. Thus, updating a group object will cause a side effect of changing the values on some user object. There are lots of other instances if the utility of this kind of bahavior: the "reports-to" and "manager-of" properties of managers and the employess that report to them, for example. The knowledge of the relationship between these properties is not captured or capturable with the current schema mechanism. It has to be understood "a-priori" by each replica. So, the representation of schema would need to be enhanced to support replication of virtual attributes. Paul --=_ORCL_7874122_0r0-- From owner-ietf-ldup Tue Apr 28 15:56:03 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id PAA26133 for ietf-ldup-bks; Tue, 28 Apr 1998 15:56:03 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id PAA26129 for ; Tue, 28 Apr 1998 15:56:02 -0700 (PDT) Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id PAA21712 for ; Tue, 28 Apr 1998 15:57:17 -0700 (PDT) Received: from netscape.com ([208.12.63.187]) by tintin.mcom.com (Netscape Messaging Server 3.52) with ESMTP id AAA65D9; Tue, 28 Apr 1998 15:57:17 -0700 Message-ID: <35465E79.AAA5FA85@netscape.com> Date: Tue, 28 Apr 1998 15:55:53 -0700 From: "John Merrells" Organization: Netscape Communications X-Mailer: Mozilla 4.05 [en]C-NSCP (WinNT; U) MIME-Version: 1.0 To: Uppili Srinivasan CC: ietf-ldup@imc.org Subject: Re: LDAP replication requirements [virtual attributes] References: <199804282150.OAA04577@mailsun3> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk Uppili Srinivasan wrote: > We should probably try to agree on a schema representation such that it has > no bearing on replication. This is also true for referrals. We (Netscape) replicate the referral by using the ManageDSAIT control. I should think that these 'dynamic attributes' would be replicated in much the same way. Generally , I think we should keep all of the various LDAP twiddles in mind, but not get too bogged down in them. John -- John Merrells Netscape Communications Directory Server Software Engineer http://people.netscape.com/merrells From owner-ietf-ldup Tue Apr 28 19:04:41 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id TAA27325 for ietf-ldup-bks; Tue, 28 Apr 1998 19:04:41 -0700 (PDT) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id TAA27315; Tue, 28 Apr 1998 19:04:30 -0700 (PDT) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id ; Wed, 29 Apr 1998 11:55:01 +1000 Message-ID: From: Alan Lloyd To: "'Anurag Srivastava'" , owner-ietf-ldup@imc.org, merrells@netscape.com, RWEISER@novell.com, USRINIVA@us.oracle.com Cc: ietf-ldup@imc.org, Alan Lloyd Subject: RE: RE: Comments on ldup-replica-req-00.txt Date: Tue, 28 Apr 1998 08:22:20 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldup@imc.org Precedence: bulk The general principles of X.500 protocols is that they are atomic - and that they operate on one or more objects which are atomic information elements. Below the directory level, X.500 as a distributed application - in reality uses things and does not define these because they are beyond scope or are implementation issues. Such mechanisms are time sync, presentation layer, session layer and in product terms or X.530 - apply management and notifications. I agree with everey effort to have standards which support distributed applications - I just think its very bad to add these to the LDAP - other wise a mess will result. thoughts are welcome re LDAP boundaries and support services please regards alan > -----Original Message----- > From: Anurag Srivastava [SMTP:SANURAG@novell.com] > Sent: Friday, April 24, 1998 2:02 PM > To: owner-ietf-ldup@imc.org; merrells@netscape.com; > RWEISER@novell.com; USRINIVA@us.oracle.com > Cc: ietf-ldup@imc.org; Alan.Lloyd@OpenDirectory.com.au > Subject: Re: RE: Comments on ldup-replica-req-00.txt > > Alan wrote : > > Yes its a requirement - in X.500 the time limit for searches > > when provided by users is "seconds" when propagated in DSP > its UTC > time + seconds for obvious reasons - this means that > > DSAs when performing distributed searches need some > > synchronised time source if time limit is to be honoured. > > > ditto goes with replication, if trying to maintain integrity of > deletes and renames in multimaster mode - see previous mail re value > judgment. > > I agree with the comments and would like to generalize the > requirement to capture the notion of QoS in general with the > directory operations, besides time synchronization, specially, wrt > searches, replication and synchronizations it is important. This > would then possibly raise other issues, like notification support, > etc. beside the time-synchronization. > > For e.g., the replication requirement can state, atomic guaranteed > delivery to various replicas to ensure consistency and for that we > may require DSAs to support time-synchronization as well as some > sort of notification support. > > Would appreciate inputs. > > Thanks & regards > Anurag > Architect, Novell India > > >>> Alan Lloyd 04/24/98 04:40AM >>> > > > > -----Original Message----- > > From: Russel Weiser [SMTP:RWEISER@novell.com] > > Sent: Friday, April 24, 1998 1:48 AM > > To: owner-ietf-ldup@imc.org; merrells@netscape.com; > > USRINIVA@us.oracle.com > > Cc: ietf-ldup@imc.org; alan.lloyd@OpenDirectory.com.au > > Subject: Re: Comments on ldup-replica-req-00.txt > > > > John and Uppili > > > > A couple of things here that are of interest and 'd like to ducuss > > further. > > My comments are below > > > snip - > > Something that hasn't > > been discussed yet it the TIME Synchronization between servers > > participating in a replication. > > This is something that should be addressed in the requirements I > > guess. > > > Yes its a requirement - in X.500 the time limit for searches > when provided by users is "seconds" when propagated in DSP its UTC > time > + seconds for obvious reasons - this means that DSAs when performing > distributed searches need some synchronised time source if time limit > is > to be honoured. > ditto goes with replication, if trying to maintain integrity of > deletes and renames in multimaster mode - see previous mail re value > judgment. > regards alan > > cheers > > RFW > > > > > > can you explain the scalability problem here? > > > > > > -Uppili Srinivasan > > > > > > ______________________________________________________________________ > > ______ > > > Oracle Corporation | > > > Box 659510 |Phone: (650)506-3039 Internet: > > usriniva@us.oracle.com > > > > > > 500 Oracle Pkwy |Fax: (650)506-7122 > > > Redwood Shores |X.400: c=us; a=telemail; p=oracle; o=oragate; > > s=usriniva > > > > > > CA 94065 | > > > > > > ___________________|__________________________________________________ > > ______ > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------- > > > > > > Subject: Re: Comments on ldup-replica-req-00.txt > > > Date: 21 Apr 98 11:56:00 > > > From: "John Merrells" > > > Organization: Netscape Communications > > > To: Alan Lloyd > > > CC: ietf-ldup@imc.org > > > References: > > > > > > Alan Lloyd wrote: > > > > > > > Of course - its just that these servers just become > > "normal" > > > > users of the directory that must be authenticated and if one > > changes the > > > > credentials of a server in one server - how does that get into > the > > > > second - unless servers need to use their old credentials > > depending if > > > > they have replicated them or not... is this chicken and egg > stuff. > > > > > > That hasn't been raised as a requirement either. An > administrator's > > > intention may indeed be to permanently or temporarily deny access > to > > > some other server. In any case, the administrators should sort it > > out. > > > > > > > > > Does this mean changes to the LDAP RFC? > > > > > > > > > > Probably, in the form of new controls, and possibly extended > > > > > operations. > > > > > > > > > > > You see replication needs to be initated by either > > server > > > > > and > > > > > > replicas transferred in either direction so its either a > > > > > bi-directional > > > > > > LDAP server to server with transaction control and server > > based > > > > > > management and a lot of Gods help (this is not a religious > > statement > > > > > > ;-)) > > > > > > > > > > It could be a session in each direction. > > > > With God in most cases it seems to be simplex - but I > > realise it > > > > is bothways with LDAP :-) see above. > > > > > > Alan, you've lost me with the God acronym. > > > > > > An LDAP Replication session could be implemented as one > > bi-directional > > > session, or two uni-directional sessions. > > > > > > > Protocol fields are easy to > > > > write down . eg ip6 address is just 16 bytes - now try and > deploy > > it and > > > > make it work as a global network. > > > > > > Um, LDAP Replication might require some extra controls to > definethe > > start > > > and end of a replcation session. > > > > > > > Want to ask Oracle, Ingres or Sybase about transaction > > locking > > > > systems and deadlock issues? > > > > > > No, I've got a book all about it. > > > > > > An LDAP Replication protocol specifiction could mandate the use of > > > transactions, but it's probably not essential that it does. > > > > > > > If they stay like DISP there is a chance of success - : > -) > > .. > > > > existance proof is good. > > > > > > Is that documented in X.525? > > > > > > Are there any documents that address using DISP for multi-master > > > directory topologies? > > > > > > > > So far, no one's suggested this as a requirement. > > > > > > > > > May I suggest a feature which......................... > > > > > > Are you suggesting identifying an entry as a master/shadow as > > arequirement > > > then? > > > > > > > > I'd wonder though... that if your application has real-time > > > > > constraints then > > > > > you probably don't want to store your data in some loosly > > consistent > > > > > store. > > > > X.500 permits inconsistencies - but leaves the ops > people > > to > > > > sort that out- but X.500 provides the services to always get the > > master > > > > entry just in case the ops people dont make it. > > > > > > Who are ops people? > > > > > > 'One of the master copies', seems no better than 'One of the > replica > > copies'. > > > > > > > > Also... if an entry is mastered by many servers... then you > > won't know > > > > > which server holds the 'correct' value anyway. So it doesn't > > sound > > > > > like > > > > > this buys you much. > > > > > > > > > In X.500 one does via the information being tagged as > > copies > > > > (internally in the DSA because it arrived via DISP) - and with > the > > > > knowledge information in the replication agreements the replica > > DSA > > > > knows of the master - and the via DSP (distribution again - an > > LDAP > > > > deficiency) I can request of the replica I am connected to to go > > to the > > > > master via DSP to get it by specifying Dont Use Copy - all > > seamlessly to > > > > the user - you see replication and distribution in X.500 work > > together. > > > > In LDAP land all the parts arn't there yet. So replication on > its > > own is > > > > very limited.... > > > > > > I think you're missing my point. Which of the master copies is the > > onetrue > > > correct copy? You'll just never know. > > > > > > > through replication agreements and using op attrs. > > > > > > > > The replication scaling problem is reduced with > > distributed > > > > directories in the first place. > > > > > > Reduced, but not elliminated. Say you have a set of N masters for > an > > > entry.Each server maintains an increasing counter which is > > > used to tag attribute > > > values as they're updated. These tags are then used to determine > > which > > > values are communicated to each of its peers. The question is: > 'How > > do > > > you avoid each server having to know the highest tag value sent > from > > > each other server?' This seems to be the big scalability problem > > for > > > multi-master directories. How does X.500 solve this? > > > > > > John > > > > > > -- > > > John Merrells > > > Netscape Communications > > > Directory Server > > > Software Engineer > > > > > > http://people.netscape.com/merrells > > > > > > > > -- > > John Merrells > > Netscape Communications > > Directory Server > > Software Engineer > > > > http://people.netscape.com/merrells > > From owner-ietf-ldup Tue Apr 28 19:04:41 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id TAA27324 for ietf-ldup-bks; Tue, 28 Apr 1998 19:04:41 -0700 (PDT) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id TAA27316 for ; Tue, 28 Apr 1998 19:04:33 -0700 (PDT) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id ; Wed, 29 Apr 1998 11:55:03 +1000 Message-ID: From: Alan Lloyd To: "'Colin Robbins'" , "'Russel Weiser'" , merrells@netscape.com, USRINIVA@us.oracle.com Cc: ietf-ldup@imc.org Subject: RE: Comments on ldup-replica-req-00.txt Date: Tue, 28 Apr 1998 08:36:58 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ietf-ldup@imc.org Precedence: bulk Thanks colin - I do imply that hence the words " "if time limit is to be honoured" - :-) Naturally if time limit is not honoured ie time limit = DSP transit delay + time limit .. then that works too... maybe. And totally agree that the replication work should not get embroyled in time sync issues but have mechanisms to permit users to deal with master/copy replicas regards alan > -----Original Message----- > From: Colin Robbins [SMTP:Colin.Robbins@nexor.co.uk] > Sent: Friday, April 24, 1998 6:15 PM > To: 'Russel Weiser'; merrells@netscape.com; USRINIVA@us.oracle.com; > 'Alan Lloyd' > Cc: ietf-ldup@imc.org > Subject: RE: Comments on ldup-replica-req-00.txt > > > > Yes its a requirement - in X.500 the time limit for searches > > when provided by users is "seconds" when propagated in DSP its UTC > time > > + seconds for obvious reasons - this means that DSAs when performing > > distributed searches need some synchronised time source if time > limit is > > to be honoured. > > X.500 does not need time synchronisation to perform DSP operations. > > The UTC component in DSP is an optional parameter. If it is absent, a > directory should fall back to the relative time limit specified by the > user. This is how the NameFLOW-Paradise project operates, with over > 700 servers connected globally via DSP, a no time synchronisation. > > Other projects I have been involved in, for example the EMA Directory > Challenge, required the use of synchronised time servers. as the > absolute UTC time component was used. This cause no end of operation > problems, due to unexpected results when the time on a remote server > drifted out of synchronisation. > > Replication has a different issues and requirements, but can and does > work without synchronised time sources. I would recommend, from > practical experience, that replication should not require synchronised > time sources. > > (Note: This time limit in DSP is a UTC time i.e., 2 year date code - > Make sure your X.500 product has been millennium tested if you plan to > use synchronised DSP time!) > > Colin From owner-ietf-ldup Tue Apr 28 22:49:39 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id WAA28342 for ietf-ldup-bks; Tue, 28 Apr 1998 22:49:39 -0700 (PDT) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id WAA28338 for ; Tue, 28 Apr 1998 22:49:32 -0700 (PDT) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id ; Wed, 29 Apr 1998 15:40:12 +1000 Received: by DSG1 with Internet Mail Service (5.0.1458.49) id ; Wed, 29 Apr 1998 14:18:37 +1000 Received: by DSG1 with Internet Mail Service (5.0.1458.49) id ; Wed, 29 Apr 1998 14:11:02 +1000 Message-ID: From: Alan Lloyd To: "'Paul Leach'" , "'ietf-ldup@imc.org'" Subject: RE: LDAP replication requirements [virtual attributes] Date: Wed, 29 Apr 1998 14:10:59 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ietf-ldup@imc.org Precedence: bulk > -----Original Message----- > From: Paul Leach [SMTP:paulle@microsoft.com] > Sent: Wednesday, April 29, 1998 6:40 AM > To: 'ietf-ldup@imc.org' > Subject: LDAP replication requirements [virtual attributes] > snip The text below again highlights a few of the referential issues and the major weaknesses in LDAP - ie. no distribution - no domain based access capabilities. The "virtual" attributes below which can be created by the server itself or by an admin utility, builds name based inter object references. Nothing wrong with that - its just very restricted if one can only do that within one server with the objects within that server. X.500 provides a common naming context "cloud" of distributed directories in which each directory can perform in a distributed way or contain replica information. X.500 permits See Also, Role Occupant, Group of Names (DN) type attributes that can point from one directory to any other. Ditto with certificate path processing in terms of having a distributed name path which is resolved within the directory system. ie. one can build references for use accross the whole directory context. All of these above attributes are impossible to deal with in a disjointed naming context as provided by (non X.500) LDAP servers. It also follows where users are members of other objects that reside in other LDAP only servers, then referential knowledge must also be obtained. In the replication process what happens re these many references. Does this mean that any non X.500 LDAP server that uses externally pointing DN attributes has to be preconfigured external references (referrals), and these MUST- must be replicated to the replica server ? What hapens if a replica server is required to reference another replica of another master server. ie. A replicates to Ar and B replicates to Br. and the system admin now wants the B references as used in A' attributes which are replicated in Ar to point to Br. Given large servers of 100,000 to mmms of entries with: See Also's Groups, Members, Mail Lists and Certficates, Alias,etc. Isnt this LDAP approach to name based directories, with name based references (attributes) that can exist as a master or a replica that can reference a master or a replica some where else in the system, somewhat frought with scaling and configuration management issues . A mechanism that defines which attributes to replicate (be they real or "virtual") between a single server is easy - what happens re references and dealing with distribution? regards alan > Support for "virtual attributes" > > Example: we have user objects in the directory, and we have group > objects. > User objects have a "member-of" property. That property is _not_ > stored -- > for any user object, it is computed dynamically by searching all the > group > objects for ones that contain that user object. Thus, updating a group > object will cause a side effect of changing the values on some user > object. > > There are lots of other instances if the utility of this kind of > bahavior: > the "reports-to" and "manager-of" properties of managers and the > employess > that report to them, for example. > > The knowledge of the relationship between these properties is not > captured > or capturable with the current schema mechanism. It has to be > understood > "a-priori" by each replica. So, the representation of schema would > need to > be enhanced to support replication of virtual attributes. > > Paul From owner-ietf-ldup Tue Apr 28 23:54:14 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id XAA00439 for ietf-ldup-bks; Tue, 28 Apr 1998 23:54:14 -0700 (PDT) Received: from tide03.microsoft.com (firewall-user@tide03.microsoft.com [131.107.3.13]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id XAA00432 for ; Tue, 28 Apr 1998 23:54:13 -0700 (PDT) Received: by tide03.microsoft.com; id XAA29690; Tue, 28 Apr 1998 23:54:59 -0700 (PDT) Received: from unknown(157.54.17.74) by tide03.microsoft.com via smap (V3.1) id xma029688; Tue, 28 Apr 98 23:54:47 -0700 Received: from red-01-imc.dns.microsoft.com ([157.54.1.197]) by imail2.microsoft.com (8.7.3/8.7.1) with ESMTP id AAA17820; Wed, 29 Apr 1998 00:03:29 -0700 (PDT) Received: from paulle-home3 (157.54.21.66 [157.54.21.66]) by red-01-imc.dns.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id JZN7X3FH; Tue, 28 Apr 1998 23:54:48 -0700 Message-ID: <008601bd733c$3218a5b0$0d00000c@paulle-home3> From: "Paul Leach" To: "Uppili Srinivasan" , Subject: Re: LDAP replication requirements [virtual attributes] Date: Tue, 28 Apr 1998 23:58:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ietf-ldup@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I forget to mention something in the original message on virtual attributes -- it is interesting to note that the problem only arises with mult-master replication. With (e.g.) master-slave replication, the slaves would be read-only, so the fact the virtual attributes didn't update properly would never be noticed. You example of nested groups is a good one, too: we need to do the same thing, actually. I didn't mean to say that total replication had to be implemented or configured everywhere, only that the protocol had to support it, and that admins had to be able to configure it and rely on it when needed and appropriate. I do not believe that it is possible to enhance the schema to represent virutal attributes, unless the enhancement includes a turing complete programming language, because the computation of the virtual attributes from the concrete ones can be totally arbitrary. - ---------------------------------- Paul J. Leach PGP Key ID: 0x978829DD Fingerprint: 9EFA A405 39B4 F91F DE6F 8939 6FE9 F5D8 Key Servers: http://pgpkeys.mit.edu:11371 ldap://certserver.pgp.com - -----Original Message----- From: Uppili Srinivasan To: ietf-ldup@imc.org Date: Tuesday, April 28, 1998 2:51 PM Subject: Re: LDAP replication requirements [virtual attributes] >Paul: > >I would like to see this notion standardized. We refer to them as >"dynamically evaluated attributes" or "computed operational attributes". > >Another example is the "leaf level members" of groups where the groups >can be nested. > >But, I would think that "total replication" cannot be assumed. So even >if the semantics is supported on all nodes, these attributes are not >guaranteed to compute to the same value. > >We should probably try to agree on a schema representation such that it >has no bearing on replication. > >-Uppili Srinivasan >_______________________________________________________________________ _ >____ >Oracle Corporation | >Box 659510 |Phone: (650)506-3039 Internet: >usriniva@us.oracle.com > >500 Oracle Pkwy |Fax: (650)506-7122 >Redwood Shores |X.400: c=us; a=telemail; p=oracle; o=oragate; >s=usriniva > >CA 94065 | >___________________|___________________________________________________ _ >____ > > > > > > > -----BEGIN PGP SIGNATURE----- Version: PGP 5.5.5 iQCVAwUBNUbPgsqlCdSXiCndAQEZdQP/Zq4wH/Nz+cUv9B5mRRYFdZ61GAvRL87b mMyfScIvfGpxdt7Gj/ugSn55gYf+WG1mTtkqsV8ddUq26G9r1eSilaTgEvm3O5ZQ JhRkImNctdFkUyATnxxTOpgMFBTb+64MsmjK9h8ju/7YPKdtt5uopvRxPbX6nzIm 7e3PvvbRCvY= =sKGo -----END PGP SIGNATURE----- From owner-ietf-ldup Mon Jun 8 05:23:41 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA02892 for ietf-ldup-bks; Mon, 8 Jun 1998 05:23:41 -0700 (PDT) Received: from fl.dk (ns.fl.dk [193.88.152.146]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA02887 for ; Mon, 8 Jun 1998 05:23:30 -0700 (PDT) Received: by gw.fl.dk id <26885-3>; Mon, 8 Jun 1998 14:26:27 +0100 Message-Id: <98Jun8.142627gmt+0100.26885-3@gw.fl.dk> From: Erik Andersen To: "'LDUP'" Cc: "'ISSS-WS-DIR'" Subject: Extended LDIF draft Date: Mon, 8 Jun 1998 13:29:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BD92D9.21E55B30" Sender: owner-ietf-ldup@imc.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_000_01BD92D9.21E55B30 Content-Type: text/plain I have today sent a new document to be published as an Internet Draft. Please find the draft as an attached file. The purpose of this draft is to fill a gap in the synchronisation in a multi-master/multi-namespace environment. It reflects some ideas I earlier have presented on this list without much response. On the advice of Gordon Good, I am sending it as separate draft and not as a new version of LDIF. The immediate need is a requirement from the Danish government that telephone operators shall exchange numbering information. The matter has been dormant for a while but is now back to life. I will appreciate any comments, also comment whether you feel this work fits into the ldup mandate. Erik Andersen, Consultant, Direct Tel. (+45) 3945 0736, Mobile: (+45) 2097 1490 E-mail: era@fl.dk FISCHER & LORENZ A/S Tuborg Parkvej 10, DK-2900 Hellerup, Copenhagen, Denmark Tel. (+45) 3945 0700, Fax (+45) 3945 0777, E-mail: fl@fl.dk, Internet: http://www.fl.dk CEN/ISSS Directory Workshop chairman, Internet: http://www.cenorm.be/isss/workshop/dir/welcome.htm <> ------ =_NextPart_000_01BD92D9.21E55B30 Content-Type: text/plain; name="LDIFEXT.TXT" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="LDIFEXT.TXT" Extended LDAP Data Interchange Format (LDIFext) = CEN/ISSS/WS-DIR INTERNET-DRAFT Editor: Erik = Andersen Fischer & Lorenz = A/S 8 June, = 1998 The Extended LDAP Data Interchange Format (LDIFext) Technical Specification Filename: draft-isss-ws-dir-ldifext-00.txt Status of this Memo This document is an Internet-Draft. 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 learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). This Internet Draft expires 13 December, 1998. Abstract This document describes a file format known as Extended LDAP Data Interchange Format (LDIFext) that builds on the LDAP Data = Interchange Format (LDIF). LDIFext is backward compatible with LDIF. Based on = the LDIFext specification it is possible to build either a basic LDIF file or an LDIFext file. LDIFext is in particular applicable in situation where several participating systems are masters of pieces of information about the same object and where the participating systems do not necessarily use the same name space. LDIFext also allows for more efficient bulk transfer. ISSS/WS-DIR June 8, 1998 [Page 1] =0C INTERNET-DRAFT Extended LDAP Data Interchange Format 9 June = 1998 Background and Intended Usage The LDIF format was originally developed and used in the University of Michigan LDAP implementation. The first use of LDIF was in describing directory entries. Later, the format was expanded to allow representation of changes to directory entries. LDIFext = further extends the LDAP capabilities by providing means for more efficient transfer of large amount of data in a heterogeneous, multi-master environment. There are a number of situations where a common interchange format = is desirable. For example, one might wish to export a copy of the contents of a directory server to a file, move that file to a different machine, and import the contents into a second directory server. Additionally, by using a well-defined interchange format, = development of data import tools from legacy systems is facilitated. A fairly simple set of tools written in awk or perl can, for example, convert a database of personnel information into an LDIF file, which can = then be imported into a directory server, regardless of the internal database representation the target directory server uses. The LDIFext is a multi-master synchronization format. In contrast to basic LDIF, it does not assume that a single system is the master of all the information about a given object, but that different systems maintain their own part of this information. The purpose of LDIFext is to allow such systems to synchronize with each other resulting in entries that potentially have both master and shadowing information. In contrast to basic LDIF, LDIFext does not assume that = participating systems share a common name space. It can be used to synchronize systems having different naming structures. The LDIFext specification allows an implementation to operate in either LDIF mode, where files are generated according to the specifications given in [10]; or in LDIFext mode utilizing the added capabilities of LDIFext. While the LDIFext is primarily developed with synchronization of LDAP/X.500 servers in mind, it can also be used for synchronization among directories and/or databases of different technologies. Although the LDIFext specification relates to LDAP/X.500 concepts, the way such concepts have been applied should make it easy to map them to other types of directories, e.g. to private mail = directories, and to databases. ISSS/WS-DIR June 8, 1998 [Page 2] =0C INTERNET-DRAFT Extended LDAP Data Interchange Format 9 June = 1998 Relationship to the application/directory MIME content-type: The application/directory MIME content-type [1] is a general framework and format for conveying directory information, and is independent of any particular directory service. It is preferred, = in most cases, to LDIF/LDIFext, for conveying directory information. The LDIF/LDIFext format is a simpler format which is perhaps easier to create, and also may be used, as noted, to describe a set of changes to be applied to a directory. The key words "MUST", "MAY", and "SHOULD" used in this document are to be interpreted as described in [7]. Definition of the Extended LDAP Data Interchange Format The LDIF/LDIFext format is used to convey directory information, or = a description of a set of changes made to directory entries. An LDIF/LDIFext file consists of a series of records separated by at least two line separators. A record consists of a sequence of lines separated by a single line separator. A record describes a directory entry or a set of changes to a single directory entry. An LDIF/LDIFext file specifies a set of directory entries, or a set of changes to be applied to directory entries, but not both. There is a one-to-one correlation between LDAP operations that = modify the directory (add, delete, modify, and modrdn), and the types of changerecords described below ("add", "delete", "modify", and "modrdn" or "moddn"). This correspondence is intentional, and permits a straightforward translation from LDIF changerecords to protocol operations. ISSS/WS-DIR June 8, 1998 [Page 3] =0C INTERNET-DRAFT Extended LDAP Data Interchange Format 9 June = 1998 Formal Syntax Definition of LDIF The following definition uses the augmented Backus-Naur Form specified in RFC 822 [2]. ldif-file =3D ldif-content / ldif-changes ldif-content =3D ["total" 1*SEP] heading ldif-attrval-record *(1*SEP ldif-attrval-record) ldif-changes =3D ["incremental" 1*SEP] heading ldif-change-record *(1*SEP ldif-change-record) heading =3D 0,1*(version-spec 1*SEP) ["agreement-id:" *SPACE agreement-id 1*SEP] [charset: *SPACE charset-name 1*SEP] agreement-id =3D 1*safe-initval charset-name =3D a character set name, as registered with IANA [9] ldif-attrval-record =3D dn-spec SEP 1*(attrval-spec SEP) ["key" SEP 1*(attrval-spec SEP)] ldif-change-record =3D dn-spec SEP 1*(changerecord SEP) ["key" SEP 1*(attrval-spec SEP)] version-spec =3D "version:" *SPACE version-number version-number =3D 1*DIGIT ; version-number MUST be "1" for the ; LDIFext format described in this ; document if operating in LDIF mode. dn-spec =3D ("dn:" *SPACE dn) / ("dn::" *SPACE base64-dn) / ("dn:" *SPACE 1*DIGIT rdn *(("," / ";") *SPACE rdn)) / ("dn::" *SPACE 1*DIGIT base64-rdn *(("," / ";") *SPACE base64-rdn )) / ("s:" [*SPACE dn]) / ("s::" *SPACE base64-dn) dn =3D base64-dn =3D rdn =3D base64-rdn =3D attrval-spec =3D attribute-description ((":") / (":" *SPACE value *(*SPACE "\" *SPACE value)) = / ("::" *SPACE base64-value *(*SPACE "\" *SPACE base64-value)) / (":<" *SPACE url*(*SPACE "\" *SPACE url))) url =3D ; (See Note 6, below) ISSS/WS-DIR June 8, 1998 [Page 4] =0C INTERNET-DRAFT Extended LDAP Data Interchange Format 9 June = 1998 attribute-description =3D value =3D 1*safe-initval *safe safe =3D safe-initval =3D base64-value =3D changerecord =3D change-add / change-delete / change-modify / change-moddn change-add =3D ["changetype:" *SPACE "add" SEP] = attrval-spec *(SEP attrval-spec) change-delete =3D "changetype:" *SPACE "delete" change-moddn =3D "changetype:" *SPACE ("modrdn" / "moddn") = SEP ("newrdn:" *SPACE rdn / "newrdn::" *SPACE base-64-rdn) SEP "deleteoldrdn:" *SPACE ("0" / "1") 0,1*(SEP (("newsuperior:" *SPACE dn) / ("newsuperior:: *SPACE base-64-dn))) change-modify =3D "changetype:" *SPACE "modify" 1*(SEP = mod-spec) mod-spec =3D mod-add-spec / mod-delete-spec / mod-replace-spec mod-add-spec =3D "add:" *(*SPACE attribute-description) 1*(SEP attrval-spec) SEP "-" mod-delete-spec =3D "delete:" *(*SPACE attribute-description) *(SEP attrval-spec) SEP "-" mod-replace-spec =3D "replace:" *(*SPACE attribute-description) *(SEP attrval-spec) SEP "-" SPACE =3D SEP =3D (CR LF / LF) CR =3D LF =3D DIGIT =3D Notes on LDIFext Syntax 1) All fields in the in the above Backus-Naur notation that are mandatory are mandatory in both LDIF and LDIFext mode. Some of the optional fields in the notation are mandatory in LDIF mode, while other such fields are mandatory in LDIFext mode 2) LDIFext mode is signalled by including the agreement-id specification. If agreement-id is not included, LDIF mode MUST be used. If the agreement-id is included, LDIFext mode MUST be used. 3) ldif-content records and ldif-changes records cannot be included ISSS/WS-DIR June 8, 1998 [Page 5] =0C INTERNET-DRAFT Extended LDAP Data Interchange Format 9 June = 1998 in the same LDIF/LDIFext file. In LDIFext mode, a file MUST have the "total" or the "incremental" specification, as appropriate, in the heading section. In LDIF mode, such a specification MUST NOT be included. 4) In LDIF mode an ldif-content record is assumed to represent a complete entry at the sender side to be copied as a complete entry into the recipient system. In LDIFext mode this assumption is relaxed. An ldif-content record may only represent part of an entry at the sender's side. It may only contain the information relevant for the recipient system. Also at the recipient system, there may already be a corresponding entry representing the same object. The ldif-content record may then be merged with such an existing record. 5) In situations where a recipient system merges ldif-content records, possibly from several systems, with own information, it = MUST tag each piece of information with agreement id. In an X.500 environment, tagging can be done using the contexts feature. 6) The version number is optional. If absent, version 0 is assumed. This corresponds to either using LDIF mode according to the version of LDIF supported by the University of Michigan ldap-3.3 reference implementation [8]; or to using LDIFext mode according to the specification in this document. For use of LDIF mode as specified = in this document, the version number MUST be "1". 7) Any line in an LDIF/LDIFext file MAY be wrapped by inserting a line separator (SEP) and a SPACE. Any line that begins with a single space MUST be treated as a continuation of the previous line. The LDIFext specification does not put any restriction on the line length. 8) Any line which begins with a pound-sign ("#", ASCII 35) is a comment line, and MUST be ignored when parsing an LDIF/LDIFext file. 9) In LDIF mode the UTF-8 character set MUST be used and the charset-name in the heading specification MUST NOT be included. In LDIFext mode the UTF-8 character set SHOULD be used. However, in closed communities as part an agreement, other named character sets can be specified to be used for all attribute values in attributes and RDNs. As an example, ISO_8859-1:1987 could be specified to be used within many European countries. This will allow special = national characters to be encoded in a single octet, which could be of significance when millions of records are to be transferred. 10) Any dn or value which contains characters other than those defined as "safe," or begins with a character other than those defined as "safe-initval", above, MUST be base-64 encoded. Other values MAY be base-64 encoded. ISSS/WS-DIR June 8, 1998 [Page 6] =0C INTERNET-DRAFT Extended LDAP Data Interchange Format 9 June = 1998 11) It is possible in the dn-spec field to use either the "dn:" or the "s:" specification. The "s:" specification MUST NOT be used in LDIF mode. In LDIF mode, the "dn:" specification MUST include a complete distinguished name. In LDIFext mode it is possible to use a truncated form where some implied RDNs are not included. 12) The "dn:" specification SHOULD only be used in LDIFext mode if the complete distinguished name is understood by both parties to denote the same object. As an example, the name of a reasonable seized company is assumed to be unique within a certain geographical area. This specification MUST be used in a directory environment if the record refers to an entry that has subordinate entries. 13) An abbreviated form of distinguished name MAY be used in LDIFext in addition to the truncated form. This abbreviated form MUST NOT be used unless the preceding record has a "dn:" specification. The = first item in the abbreviated specification is a level indication telling how large a part of the distinguished name of the preceding record that is inherited. This item MUST include the defaulted part of the distinguished name. As an example, if the country name is implied, the country name component is still counted. The remaining items are one or more RDNs that when prefixed the inherited part comprise a complete distinguished name. 14) The "s:" specification can be used if it is not possible to establish distinguished names that are globally recognized. It MUST NOT be used in LDIF mode. In a directory environment it SHOULD include the distinguished name of the superior entry. This field can then only be used for leaf entries, e.g. residential persons. When this field is present, it is assumed that the recipient from other included information, e.g. name, telephone number, postal address, etc., can determine the entity of a possible corresponding local entry. If an existing entry is not found, the receiver can generate an RDN based on local algorithms to produce a complete distinguished name for its own use. 15) In a non-directory environment, the "s:" specification MAY be empty. It is outside the scope of this specification how a directory system handles an LDIFext file from a non-directory system having an empty "s:" specification. In a mixed environment with both directory systems and non-directory systems a non-system SHOULD generate a valid "s:" specification. 16) If there is no "s:" or "dn:" specification, an "s:" = specification field is implied having the same value as in the previous record. = The absence of both the "dn:" and the "s:" specification is only allowed if the previous record had an explicit or implicit "s:" specification. ISSS/WS-DIR June 8, 1998 [Page 7] =0C INTERNET-DRAFT Extended LDAP Data Interchange Format 9 June = 1998 17) In LDIF mode, the attrval-spec MUST NOT hold several attribute values. In LDIFext mode, the attrval-spec MAY hold several attribute values separated by back-slashes ("\"). In LDIFext mode, any back-slash within an attribute value MUST be replace by a double back-slash. 18) To represent a zero-length attribute value, use an attrval-spec of "attribute-description:". For example, "seeAlso:" represents a zero-length "seeAlso" attribute value. 19) When a URL is specified in an attrval-spec, the following conventions apply: a) Implementations SHOULD support the file:// URL format. The contents of the referenced file are to be included verbatim in the interpreted output of the LDIF file. b) Implementations MAY support other URL formats. The semantics associated with each supported URL will be documented in an associated Applicability Statement. 20) While it is permissible for character values larger than 126 to be contained in an attribute value, implementations SHOULD base-64 encode any value which contains such characters when generating an LDIF/LDIFext file. However, implementations MAY leave the values unencoded. This relaxation is designed to allow editing of LDIF/LDIFext files containing, for example, Latin-1 content, with existing tools. 21) In LDIFext mode, some of the information in a record is owned by the sender, i.e. the sender is master for that information. This information is located just after the "dn:" or the "s:" specification, and it may be the only information in a record. Additional information (see below) may be supplied in a record to allow the recipient to uniquely identify a corresponding local = entry, if any. 22) The optional "key" specification starts a block of information, which is not to be considered master information owned by the = sender. Such information is intended for identifying a possible already existing entry at the recipient. As an example, a mobile operator = may supply the fixed telephone number in a record, although the fixed telephone is subscribed from another operator. If there is information in these blocks that is currently not present at the recipient, it a local option for the recipient whether to store it = or dispose of it in any other way. The "key" specification MUST NOT be used in LDIF mode. 23) In the change-add field the "changetype:" specification is optional. However, it MUST be present in LDIF mode. ISSS/WS-DIR June 8, 1998 [Page 8] =0C INTERNET-DRAFT Extended LDAP Data Interchange Format 9 June = 1998 24) When doing total update in LDIFext mode: a) All information related to the agreement SHOULD be purged and replaced by the information in the current transfer. This does = not necessarily mean that current entries are completely deleted during the first part of this process, as there may be local information or information from other agreements within those entries. b) Information following the "key" specification is only intended for entry identification. Such information SHOULD be included if the "s:" specification is used. c) If the object class attribute is not included for a record, = the value(s) is the same as for the previous record. 25) When doing incremental update in LDIFext mode: a) Only information owned by the sender can be changed. = Additional information may be transmitted to allow identification of the entries to be changed. If the "dn:" specification is used, only the distinguished name SHOULD be supplied in addition to change = or delete specifications to ensure compatibility with earlier versions. For records starting with an implicit or explicit "s:" specification, additional information MUST be supplied for entry identification. b) Records without any "changetype" specification are to be considered as new entries to be added. For records starting with an implicit or explicit "s:" specification, a "key" part MUST be supplied for entry identification. c) A record with "changetype" equal to "delete" only applies to the part of the entry holding information owned by the sender according to the current agreement. Records starting with an implicit or explicit "s:" specification MUST besides the delete specification have a "key" part for entry identification. d) A record with "changetype" equal to "modify" and which starts with an implicit or explicit "s:" specification MUST besides the change specifications have a "key" part for entry identification. 26) In some cases it may not be possible to denote some pieces of information belonging to anyone. As an example, object class specification, postal address, etc. may be considered general information maintained independently by each system. If such information is not consistent across systems, correlation may not be possible. Such general information should be in the "key" block. It is recommended to establish an authoritative source for such information. ISSS/WS-DIR June 8, 1998 [Page 9] =0C INTERNET-DRAFT Extended LDAP Data Interchange Format 9 June = 1998 Agreements An agreement ID MUST be in the first part of an LDIFext file. This agreement specification is used to give a unique identification of the scope of an information exchange. The concept of agreement is = not relevant in LDIF mode although some implicit understanding is probably required. An agreement can include such things as: 1) What information has to be transferred and possibly kept updated by the sender. 2) The attribute types and object classes that are part of the transport including what textual representations that are going to = be used. In case of high-volume exchanges, the two parties can agree on an abbreviated form of textual representation. As an example "tel" could be an abbreviated form of TelephoneNumber. Textual representations of attribute types MUST be unique within an agreement. Likewise for textual representation of object classes. 3) An understanding of what information is necessary to transfer in the "key" block to ensure the correlation process, i.e. locating an existing entry, if any, at the recipient. 4) How much of a distinguished name that needs to be transferred. As an example, the country name could be implied. 5) Maximum line length. If a file is to be displayed on a screen, it may be useful to limit the line length accordingly. For high volume bulk transfer, it saves overhead to have unlimited line length. 6) How much information that is needed for the objectClass = attribute. If the object class for the entry information is, say, residentialPerson, it may not be necessary also to specify the = super- classes person and top. They could be implied. Also auxiliary object classes can be implied. It MUST be completely understood by both parties what set of object classes is behind a single object class textual specification. 7) Agreement on not to use spaces where they are optional. 8) Agreement not to use any unnecessary SEPs, i.e. consider the = 1*SEP specification equals to just SEP. 9) Agreement on only using LF for SEP. 10) Update frequency. Establishment of an agreement is an off-line activity not directly reflected in the protocol. ISSS/WS-DIR June 8, 1998 [Page = 10] =0C INTERNET-DRAFT Extended LDAP Data Interchange Format 9 June = 1998 Differences from Version 1 of LDIF 1) It is possible in a header besides giving version information to indicate whether an LDIF file is a complete transfer of all information or whether is an updating file 2) It is possible in the header to indicate an agreement ID 3) It is possible for each record to include information that is not intended for storage by the receiver, but is aiding the recipient in identifying a particular entry. 4) It is possible to only transfer the distinguished name of the superior of an entry in case the receiver is expected to generate = the complete distinguished following local algorithms. 5) Several values for a multi-valued attribute can be on the same, possibly folded line. The separator between values is a back-slash ("\") Example 1: An simple LDIF file with two entries dn: cn=3DBarbara Jensen, ou=3DProduct Development, o=3DAce Industry, = c=3DUS objectclass: top objectclass: person objectclass: organizationalPerson cn: Barbara Jensen cn: Barbara J Jensen cn: Babs Jensen sn: Jensen uid: bjensen telephonenumber: +1 408 555 1212 description: A big sailing fan. dn: cn=3DBjorn Jensen, ou=3DAccounting, o=3DAce Industry, c=3DUS objectclass: top objectclass: person objectclass: organizationalPerson cn: Bjorn Jensen sn: Jensen telephonenumber: +1 408 555 1212 Example 2: An LDIF file containing an entry with a folded attribute value dn:cn=3DBarbara Jensen, ou=3DProduct Development, o=3DAce Industry, = c=3DUS objectclass:top ISSS/WS-DIR June 8, 1998 [Page = 11] =0C INTERNET-DRAFT Extended LDAP Data Interchange Format 9 June = 1998 objectclass:person objectclass:organizationalPerson cn:Barbara Jensen cn:Barbara J Jensen cn:Babs Jensen sn:Jensen uid:bjensen telephonenumber:+1 408 555 1212 description:Babs is a big sailing fan, and travels extensively in search of perfect sailing conditions. title:Product Manager, Rod and Reel Division Example 3: An LDIF file containing a base-64-encoded value dn: cn=3DGern Jensen, ou=3DProduct Testing, o=3DAce Industry, c=3DUS objectclass: top objectclass: person objectclass: organizationalPerson cn: Gern Jensen cn: Gern O Jensen sn: Jensen uid: gernj telephonenumber: +1 408 555 1212 description:: V2hhdCBhIGNhcmVmdWwgcmVhZGVyIHlvdSBhcmUhICBUaGlzIHZhbHVlIGlzIGJ hc2UtNjQtZW5jb2RlZCBiZWNhdXNlIGl0IGhhcyBhIGNvbnRyb2wgY2hhcmFjdGVyIGluIGl= 0ICh hIENSKS4NICBCeSB0aGUgd2F5LCB5b3Ugc2hvdWxkIHJlYWxseSBnZXQgb3V0IG1vcmUu Example 4: A file containing an entries with UTF-8-encoded attribute values, including language tags. Comments indicate the contents of UTF-8-encoded attributes and distinguished names. dn:: b3U95Za25qWt6YOoLG89QWlyaXVz # dn:: ou=3D,o=3DAirius objectclass: top objectclass: organizationalUnit ou:: 5Za25qWt6YOo # ou:: ou;lang-ja:: 5Za25qWt6YOo # ou;lang-ja:: ou;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2 # ou;lang-ja:: ou;lang-en: Sales description: Japanese office ISSS/WS-DIR June 8, 1998 [Page = 12] =0C INTERNET-DRAFT Extended LDAP Data Interchange Format 9 June = 1998 dn:: dWlkPXJvZ2FzYXdhcmEsb3U95Za25qWt6YOoLG89QWlyaXVz # dn:: uid=3D,ou=3D,o=3DAirius userpassword: {SHA}O3HSv1MusyL4kTjP+HKI5uxuNoM=3D objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson uid: rogasawara mail: rogasawara@airius.co.jp givenname;lang-ja:: 44Ot44OJ44OL44O8 # givenname;lang-ja:: sn;lang-ja:: 5bCP56yg5Y6f # sn;lang-ja:: cn;lang-ja:: 5bCP56yg5Y6fIOODreODieODi+ODvA=3D=3D # cn;lang-ja:: title;lang-ja:: 5Za25qWt6YOoIOmDqOmVtw=3D=3D # title;lang-ja:: preferredlanguage: ja givenname:: 44Ot44OJ44OL44O8 # givenname:: sn:: 5bCP56yg5Y6f # sn:: cn:: 5bCP56yg5Y6fIOODreODieODi+ODvA=3D=3D # cn:: title:: 5Za25qWt6YOoIOmDqOmVtw=3D=3D # title:: givenname;lang-ja;phonetic:: 44KN44Gp44Gr44O8 # givenname;lang-ja;phonetic:: sn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJ # sn;lang-ja;phonetic:: cn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJIOOCjeOBqeOBq+ODvA=3D=3D # cn;lang-ja;phonetic:: title;lang-ja;phonetic:: = 44GI44GE44GO44KH44GG44G2IOOBtuOBoeOCh+OBhg=3D=3D # title;lang-ja;phonetic:: = givenname;lang-en: Rodney sn;lang-en: Ogasawara cn;lang-en: Rodney Ogasawara title;lang-en: Sales, Director Example 5: An LDIF file containing a reference to an external file dn: cn=3DHoratio Jensen, ou=3DProduct Testing, o=3DAce Industry, = c=3DUS objectclass: top objectclass: person objectclass: organizationalPerson ISSS/WS-DIR June 8, 1998 [Page = 13] =0C INTERNET-DRAFT Extended LDAP Data Interchange Format 9 June = 1998 cn: Horatio Jensen cn: Horatio N Jensen sn: Jensen uid: hjensen telephonenumber: +1 408 555 1212 jpegphoto:< file:///usr/local/directory/photos/hjensen.jpg Example 6: An LDIF file containing a series of change records and comments # Add a new entry dn: cn=3DFiona Jensen, ou=3DMarketing, o=3DAce Industry, c=3DUS changetype: add objectclass: top objectclass: person objectclass: organizationalPerson cn: Fiona Jensen sn: Jensen uid: fiona telephonenumber: +1 408 555 1212 jpegphoto:< file:///usr/local/directory/photos/fiona.jpg # Delete an existing entry dn: cn=3DRobert Jensen, ou=3DMarketing, o=3DAce Industry, c=3DUS changetype: delete # Modify an entry's relative distinguished name dn: cn=3DPaul Jensen, ou=3DProduct Development, o=3DAce Industry, = c=3DUS changetype: modrdn newrdn: cn=3DPaula Jensen deleteoldrdn: 1 # Rename an entry and move all of its children to a new location in # the directory tree (only implemented by LDAPv3 servers). dn: ou=3DPD Accountants, ou=3DProduct Development, o=3DAce Industry, = c=3DUS changetype: modrdn newrdn: ou=3DProduct Development Accountants deleteoldrdn: 0 newsuperior: ou=3DAccounting, o=3DAce Industry, c=3DUS # Modify an entry: add an additional value to the postaladdress = attribute, # completely delete the description attribute, replace the = telephonenumber # attribute with two values, and delete a specific value from the # facsimiletelephonenumber attribute dn: cn=3DPaula Jensen, ou=3DProduct Development, o=3DAce Industry, = c=3DUS changetype: modify ISSS/WS-DIR June 8, 1998 [Page = 14] =0C INTERNET-DRAFT Extended LDAP Data Interchange Format 9 June = 1998 add: postaladdress postaladdress: 123 Anystreet $ Sunnyvale, CA $ 94086 - delete: description - replace: telephonenumber telephonenumber: +1 408 555 1234 telephonenumber: +1 408 555 5678 - delete: facsimiletelephonenumber facsimiletelephonenumber: +1 408 555 9876 - Example 7: A simple LDIFext file with a few records sent from a mobile telephone operator to some central information service total version 0 agreement-id: op1-to-op2, ver.1 dn:o=3DF&L,c=3DDK mobile:+4533333333\+4544444444 other tel:+4539450700 fax:+4539450777 dn:2 cn=3DTom Finkelstein mobile:+4512345678 key objcl:orgPers sn:Finkdelstein gn:Tom tel:+4539450999 822:tfs@fl.dk dn:2 cn=3DPer Futtesen mobile:+4587654321 key sn:Futtesen gn:Per tel:+4539450998 822:tfs@fl.dk s:L=3DFrederiksberg C,ST=3DCopenhagen mobile:+4520971490 key objcl:resPers sn:Andersen ISSS/WS-DIR June 8, 1998 [Page = 15] =0C INTERNET-DRAFT Extended LDAP Data Interchange Format 9 June = 1998 gn:Erik street:Paludan Mullersvej num:3 floor:2 floorentity:tv tel:+4531230490 mobile:+4587654321 key sn:Petersen gn:Peter street:Paludan Mullersvej num:114 floor:3 tel:+4523456789 Example 8: A simple LDIF file with a few update records sent from a mobile telephone operator to some central information service incremental version 0 agreement-id: op1-to-op2, ver.1 # Delete an entry. The mobile number and the name is considered # sufficient information for locating the right entry s:L=3D1815,ST=3DCopenhagen changetype:delete mobile:+4520971490 key sn:Andersen gn:Erik # Update existing entry replace: mobile:+4587654321 mobile:+4598765432 - key sn:Petersen gn:Peter # Add new entry s:L=3DHellerup,ST=3DCopenhagen mobile:+4534567890 key objcl:resPers sn:Frederiksen ISSS/WS-DIR June 8, 1998 [Page = 16] =0C INTERNET-DRAFT Extended LDAP Data Interchange Format 9 June = 1998 gn:John street:Grundtvigsvej num:245 floor:5 floorentity:tv tel:+4531230490 Security Considerations Given typical directory applications, an LDIF/LDIFext file is likely to contain sensitive personal data. Appropriate measures should be taken to protect the privacy of those persons whose data is = contained in an LDIF/LDIFext file. Since ":<" directives can cause external content to be included when processing an LDIF/LDIFext file, one should be cautious of accepting LDIF/LDIFext files from external sources. A "trojan" LDIF/LDIFext file could name a file with sensitive contents and cause it to be included in a directory entry, which a hostile entity could read via LDAP. LDIF/LDIFext does not provide any method for carrying authentication information with an LDIF/LDIFext file. Users of LDIF/LDIFext files must take care to verify the integrity of an LDIF file received from an external source. Acknowledgements The extensions to LDAP Data Interchange Format presented in this document has been considered too extensive to reflect a new version of LDIF. As suggested by the LDIF editor, Gordon Good, Netscape Communications Corp., the extensions are issued as a separate Internet Draft to be progressed in parallel with the basic LDIF specifications. This document has benefited greatly from the work done on LDIF and has re-used considerable amount of the text. References [1] Howes, T., Smith, M., "A MIME Content-Type for Directory Infor- mation", INTERNET-DRAFT draft-ietf-asid-mime-direct-06.txt, Netscape Communications Corp., [2] Crocker, D.H., "Standard for the Format of ARPA Internet Text Messages", RFC 822, University of Delaware, August 1982, ISSS/WS-DIR June 8, 1998 [Page = 17] =0C INTERNET-DRAFT Extended LDAP Data Interchange Format 9 June = 1998 [3] Kille, S., "A String Representation of Distinguished Names", = RFC 1779, ISODE Consortium, March 1995, [4] Wahl, M., Howes, T., Kille, S., "Lightweight Directory Access Protocol (v3)", RFC 2251, Critical Angle, Inc., ISODE Consor- tium, Netscape Communications Corp., July, 1997, [5] Borenstein, N., Freed, N., "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", section 5.2, "Base64 Content-Transfer-Encoding", RFC 1521, Bellcore, Innosoft, December 1993, [6] T. Berners-Lee, L. Masinter, M. McCahill, "Uniform Resource Locators (URL)", CERN, Xerox Corporation, University of Min- nesota, Request for Comment (RFC) 1738, December 1994, [7] S. Bradner, "Key Words for use in RFCs to Indicate Requirement Levels", Harvard University, RFC 2119, March 1997, [8] The SLAPD and SLURPD Administrators Guide. University of = Michi- gan, April 1996. [9] Internet Assigned Numbers Authority, "CHARACTER SETS", = [10] Good, G, " The LDAP Data Interchange Format (LDIF) - Technical Specification", INTERNET-DRAFT draft-good-ldap-ldif-00.txt, Netscape Communications Corp., Author's Address Erik Andersen Fischer & Lorenz A/S Tuborgvej 10 DK-2900 Hellerup Denmark Phone: +45 20 97 14 90 EMail: era@fl.dk This Internet Draft expires 13 December, 1998. ISSS/WS-DIR June 8, 1998 [Page = 18] ------ =_NextPart_000_01BD92D9.21E55B30-- From owner-ietf-ldup Tue Jun 9 04:06:11 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA27356 for ietf-ldup-bks; Tue, 9 Jun 1998 04:06:11 -0700 (PDT) Received: from fl.dk (ns.fl.dk [193.88.152.146]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA27351 for ; Tue, 9 Jun 1998 04:06:09 -0700 (PDT) Received: by gw.fl.dk id <26885-4>; Tue, 9 Jun 1998 13:09:26 +0100 Message-Id: <98Jun9.130926gmt+0100.26885-4@gw.fl.dk> From: Erik Andersen To: "'LDUP'" , "'ISSS-WS-DIR'" Cc: Allan Fischer-Madsen Subject: FW: Date: Tue, 9 Jun 1998 12:12:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-ietf-ldup@imc.org Precedence: bulk I did check. It is there. Note the new name. The Extended LDIF format is on the 15th of this month going to be presented to Danish Telephone operators and other parties entitled to receive telephone number information. Comments before then are most welcome. Erik Andersen, Consultant, Direct Tel. (+45) 3945 0736, Mobile: (+45) 2097 1490 E-mail: era@fl.dk FISCHER & LORENZ A/S Tuborg Parkvej 10, DK-2900 Hellerup, Copenhagen, Denmark Tel. (+45) 3945 0700, Fax (+45) 3945 0777, E-mail: fl@fl.dk, Internet: http://www.fl.dk CEN/ISSS Directory Workshop chairman, Internet: http://www.cenorm.be/isss/workshop/dir/welcome.htm > -----Original Message----- > From: Cynthia Clark [SMTP:cclark@CNRI.Reston.VA.US] > Sent: 8. juni 1998 17:29 > To: Erik Andersen > Cc: Cynthia Clark > Subject: > > > Erik, > > I'm going to send the announcement on your > new Internet-Draft > and please note the minor filename change > as a normal procedure in order to include > an initial author's last name in the > filename. > > I've just made a minor editorial change > by replacing the third paragraph of the Status of this Memo section: > > To view the entire list of current Internet-Drafts, please check > the "1id-abstracts.txt" listing contained in the Internet-Drafts > Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net > (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au > (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu > (US West Coast). > > Please use this one for the future reference. Please note that > I've removed "ds.internic.net" from this paragraph mainly due to > the fact it's no longer in service. > > Any questions (or concerns) about any drafts should be directed > to me at directly > > Thanks, > > Cynthia > ------------------------------------------------------ > Cynthia Clark, IETF Internet-Drafts Publisher > E-mail: From owner-ietf-ldup Wed Jun 10 17:50:44 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA28503 for ietf-ldup-bks; Wed, 10 Jun 1998 17:50:44 -0700 (PDT) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA28489 for ; Wed, 10 Jun 1998 17:49:08 -0700 (PDT) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id ; Thu, 11 Jun 1998 10:52:28 +1000 Message-ID: From: Alan Lloyd To: "'Erik Andersen'" , "'LDUP'" , "'ISSS-WS-DIR'" Cc: Allan Fischer-Madsen Subject: RE: Date: Thu, 11 Jun 1998 10:52:27 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ietf-ldup@imc.org Precedence: bulk A couple of issues with this doc in that it defines update types and agreements IDs - I am not sure how this is managed or represented in the LDAP protocol. These are fields from X.500 DISP and DOP which manages the replication process. regards alan > -----Original Message----- > From: Erik Andersen [SMTP:ERA@FL.DK] > Sent: Tuesday, June 09, 1998 9:13 PM > To: 'LDUP'; 'ISSS-WS-DIR' > Cc: Allan Fischer-Madsen > Subject: FW: > > I did check. It is there. Note the new name. The Extended LDIF format > is on > the 15th of this month going to be presented to Danish Telephone > operators > and other parties entitled to receive telephone number information. > Comments > before then are most welcome. > > Erik Andersen, Consultant, Direct Tel. (+45) 3945 0736, Mobile: (+45) > 2097 > 1490 > E-mail: era@fl.dk > > FISCHER & LORENZ A/S > Tuborg Parkvej 10, DK-2900 Hellerup, Copenhagen, Denmark > Tel. (+45) 3945 0700, Fax (+45) 3945 0777, E-mail: fl@fl.dk, Internet: > http://www.fl.dk > > CEN/ISSS Directory Workshop chairman, Internet: > http://www.cenorm.be/isss/workshop/dir/welcome.htm > > > -----Original Message----- > > From: Cynthia Clark [SMTP:cclark@CNRI.Reston.VA.US] > > Sent: 8. juni 1998 17:29 > > To: Erik Andersen > > Cc: Cynthia Clark > > Subject: > > > > > > Erik, > > > > I'm going to send the announcement on your > > new Internet-Draft > > and please note the minor filename change > > as a normal procedure in order to include > > an initial author's last name in the > > filename. > > > > I've just made a minor editorial change > > by replacing the third paragraph of the Status of this Memo section: > > > > To view the entire list of current Internet-Drafts, please check > > the "1id-abstracts.txt" listing contained in the Internet-Drafts > > Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net > > (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au > > (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu > > (US West Coast). > > > > Please use this one for the future reference. Please note that > > I've removed "ds.internic.net" from this paragraph mainly due to > > the fact it's no longer in service. > > > > Any questions (or concerns) about any drafts should be directed > > to me at directly > > > > Thanks, > > > > Cynthia > > ------------------------------------------------------ > > Cynthia Clark, IETF Internet-Drafts Publisher > > E-mail: From owner-ietf-ldup Tue Jun 16 04:32:39 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA19748 for ietf-ldup-bks; Tue, 16 Jun 1998 04:32:39 -0700 (PDT) Received: from fl.dk (ns.fl.dk [193.88.152.146]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA19743 for ; Tue, 16 Jun 1998 04:32:36 -0700 (PDT) Received: by gw.fl.dk id <26892-4>; Tue, 16 Jun 1998 13:36:12 +0100 Message-Id: <98Jun16.133612gmt+0100.26892-4@gw.fl.dk> From: Erik Andersen To: "'ISSS-WS-DIR'" , "'LDUP'" Subject: Extended LDIF format approved Date: Tue, 16 Jun 1998 12:38:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-ietf-ldup@imc.org Precedence: bulk The suggested Extended LDIF format was yesterday presented to the interested parties, i.e., all Danish telephone/mobile operators and other publisher of telephone information. The meeting was called by the Danish Ministry of Research and Information Technology. Although these parties have very conflicting requirement and wishes, they unanimously agreed that the Extended LDIF format as suggested by me is the best possible solution. It will be part of an attachment to a Danish law on mandatory exchange of telephone number information. It is my intention to progress the Extended LDIF specification to a formal status. I am still looking for comments on how the proposal fits into LDUP work and also possible suggestion to improvement. The Extended LDIF specification is on the Internet Drafts repository (draft-andersen-isss-ws-dir-ldifext-00.txt). Kind regards, Erik Andersen, Consultant, Direct Tel. (+45) 3945 0736, Mobile: (+45) 2097 1490 E-mail: era@fl.dk FISCHER & LORENZ A/S Tuborg Parkvej 10, DK-2900 Hellerup, Copenhagen, Denmark Tel. (+45) 3945 0700, Fax (+45) 3945 0777, E-mail: fl@fl.dk, Internet: http://www.fl.dk CEN/ISSS Directory Workshop chairman, Internet: http://www.cenorm.be/isss/workshop/dir/welcome.htm From owner-ietf-ldup Sat Jul 25 18:11:30 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA02291 for ietf-ldup-bks; Sat, 25 Jul 1998 18:11:30 -0700 (PDT) Received: from i.control.att.com (H-135-205-52-126.control.att.com [135.205.52.126] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA02287 for ; Sat, 25 Jul 1998 18:11:27 -0700 (PDT) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Sat, 25 Jul 1998 21:02:56 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for paf@swip.net; Sat, 25 Jul 1998 21:02:55 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Sat, 25 Jul 1998 21:02:55 -0400 (EDT) From: capple@master.control.att.com (Christopher W Apple) To: ietf-ldup@imc.org Cc: johns@cisco.com, capple@control.att.com, paf@swip.net Subject: LDUP WG Charter Sender: owner-ietf-ldup@imc.org Precedence: bulk The charter John Strassner and I would like to send up for IESG review follows. We'd like to limit the comment period to two (2) calendar weeks. This period starts now, 7/25/1998, and ends on 8/11/1998. Please post comments on the list. After the comment period, we will incorporate changes as concensus indicates and send to the Apps Co-ADs with a request for IESG review and approval to create the LDUP WG. John Strassner Chris Apple IETF LDUP Proposed WG Co-Chairs Charter LDAP Duplication/Replication/Update Protocol(ldup) Chair(s): Chris Apple John Strassner Applications Area Director(s): Keith Moore Patrik Faltstrom Operations and Management Area Advisor: Patrik Faltstrom Mailing lists: General Discussion: ietf-ldup@imc.org To Subscribe: ietf-ldup-request@imc.org In Body: subscribe Archive: http://www.imc.org/ietf-ldup/ Description of Working Group: As LDAP becomes more widely deployed, replication of data across servers running different implementations becomes an important part of providing a distributed directory service. However, the LDAP community, to date, has focused on standardizing the client-server access protocol. Therefore, this group will standardize master-slave and multi-master LDAP replication as defined below: Multi-Master Replication - A replication model where entries can be written and updated on any of several replica copies, without requiring communication with other masters before the write or update is performed. Master-Slave, or Single-Master Replication - A replication model that assumes only one server, the master, allows write access to the replicated data. Note that Master-Slave replication can be considered a proper subset of multi-master replication. Our approach is to first develop a set of requirements for LDAP directory replication and write an applicability statement defining scenarios on which replication requirements are based. Once the requirements and applicability statement have been drafted, the working group will harmonize vendor/vendor-team replication concept proposals; such concept proposals will be constructed in such a manner as to support all forms of replication mentioned above. Each proposal will include provisions allowing functional decomposition of multi-master replication into a proper subset required to implement master-slave replication. After vendor replication concept proposals have been harmonized, a single replication architecture document will be published. Six areas of working group focus have been identified through LDUP Engineering Team discussions: * Abstract Model of LDAP Replication This would document a general-purpose LDAP replication architecture, define key components of this architecture, describe how these key components functionally behave, and describe how these components interact with each other when in various modes of operation) * LDAP Replication Information Model Schema and semantics of information used to operate, administer, maintain, and provision replication between LDAP servers. Specifically, this document will contain common schema specifications intended to facilitate interoperable implementations with respect to: + replication agreements + consistency models + replication topologies + graveyards, tombstones, and zombies + administration and management * LDAP Replication Information Transport Protocol LDAP extended operation and control specifications required to allow LDAP to be used as the transport protocol for information being replicated * Mandatory Replica Management Specifications required to allow administration, maintenance, and provisioning of replicas and replication agreements. These specifications may take the form of definitions for LDAP extended operations, controls, and/or new schema elements. * Conflict Detection and Resolution Procedures Procedures for detection and resolution of conflicts between the state of multiple replicas that contain information from the same unit of replication. * Profiles Including the Abstract Replication Model, Information Model, LDAP Protocol Extensions, and Conflict Detection and Resolution Procedures for: + Master-Slave LDAP Directory Replication + Multi-Master LDAP Directory Replication Milestones: May 1998 Directory Replication Requirements and Applicability Statement I-D Published. May 1998 Vendors publish replication concept proposals to LDUP Engineering team mailing list. Jun 1998 Harmonization of vendor replication concept proposals is complete. Aug 1998 Directory Replication Requirements and Applicability Statement I-D goes to WG Last Call as Informational. Aug 1998 Abstract Model of LDAP Replication (based on the concensus of the LDUP Engineering Team) is published as an I-D. Sep 1998 LDAP Replication Information Model is published as an I-D. Sep 1998 LDAP Replication Information Transport Protocol is published as an I-D. Oct 1998 Abstract Model of LDAP Replication goes to WG Last Call as Informational. Oct 1998 Mandatory LDAP Replica Management is published as an I-D. Oct 1998 Conflict Detection and Resolution Procedures is published as an I-D. Nov 1998 LDAP Replication Information Model goes to WG Last Call as Proposed Standard. Nov 1998 LDAP Replication Information Transport Protocol goes to WG Last Call as Proposed Standard. Dec 1998 Master-Slave LDAP Replication Profile is published as an I-D. Dec 1998 Multi-Master LDAP Replication Profile is published as an I-D. Jan 1999 Mandatory LDAP Replica Management goes to WG Last Call as Proposed Standard. Jan 1999 Conflict Detection and Resolution Procedures goes to WG Last Call as Proposed Standard. Mar 1999 Master-Slave LDAP Replication Profile goes to WG Last Call as Proposed Standard. Mar 1999 Multi-Master LDAP Replication Profile goes to WG Last Call as Proposed Standard. From owner-ietf-ldup Sat Jul 25 20:31:11 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA02830 for ietf-ldup-bks; Sat, 25 Jul 1998 20:31:11 -0700 (PDT) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA02826 for ; Sat, 25 Jul 1998 20:31:05 -0700 (PDT) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id ; Sun, 26 Jul 1998 13:31:35 +1000 Message-ID: From: Alan Lloyd To: "'ietf-ldup@imc.org '" , "'capple@master.control.att.com '" Cc: "'johns@cisco.com '" , "'capple@control.att.com '" , "'paf@swip.net '" Subject: RE: LDUP WG Charter Date: Sun, 26 Jul 1998 13:31:34 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldup@imc.org Precedence: bulk Chris - in line with my usual style of response one should not confuse the word "Distributed" with replicated. They are quite different in directory operations. This replication work is of importance to the LDAP server community who have to replicate everything to everywhere just to do authentication of users to many servers. Mind you the issue of cert path processing is still impossible in this case.... :-((( As you know I think like most out here that replicate everything to everywhere approach is operationally broken. As most are now saying now, LDAP is Hand-draulic ie what it does not do - namely distribution and mutual authentication then humans have to with LDIF, manual work and massess of replica utilities AND the bigger the system gets the worse it becomes. Never the less some will require this but pehaps the urgency is to look at scale. On the other hand - one can see that most directory oriented companies are realising that LDAP servers dont do much for "distributed" services and their users and are going down then X.500 path which you know already replicates quite well. I think the issue that should be addressed by LDAP servers suppliers is that this will put them even further back behind X.500 distributed systems. In addition one only has to say with 10 ldap servers and 10 replicas to be managed to everywhere one needs a few more staff - and thats enough to put people off. But thats a choice eh? regards alan ---------- From: capple@master.control.att.com To: ietf-ldup@imc.org Cc: johns@cisco.com; capple@control.att.com; paf@swip.net Sent: 7/26/98 11:02:55 AM Subject: LDUP WG Charter The charter John Strassner and I would like to send up for IESG review follows. We'd like to limit the comment period to two (2) calendar weeks. This period starts now, 7/25/1998, and ends on 8/11/1998. Please post comments on the list. After the comment period, we will incorporate changes as concensus indicates and send to the Apps Co-ADs with a request for IESG review and approval to create the LDUP WG. John Strassner Chris Apple IETF LDUP Proposed WG Co-Chairs Charter LDAP Duplication/Replication/Update Protocol(ldup) Chair(s): Chris Apple John Strassner Applications Area Director(s): Keith Moore Patrik Faltstrom Operations and Management Area Advisor: Patrik Faltstrom Mailing lists: General Discussion: ietf-ldup@imc.org To Subscribe: ietf-ldup-request@imc.org In Body: subscribe Archive: http://www.imc.org/ietf-ldup/ Description of Working Group: As LDAP becomes more widely deployed, replication of data across servers running different implementations becomes an important part of providing a distributed directory service. However, the LDAP community, to date, has focused on standardizing the client-server access protocol. Therefore, this group will standardize master-slave and multi-master LDAP replication as defined below: Multi-Master Replication - A replication model where entries can be written and updated on any of several replica copies, without requiring communication with other masters before the write or update is performed. Master-Slave, or Single-Master Replication - A replication model that assumes only one server, the master, allows write access to the replicated data. Note that Master-Slave replication can be considered a proper subset of multi-master replication. Our approach is to first develop a set of requirements for LDAP directory replication and write an applicability statement defining scenarios on which replication requirements are based. Once the requirements and applicability statement have been drafted, the working group will harmonize vendor/vendor-team replication concept proposals; such concept proposals will be constructed in such a manner as to support all forms of replication mentioned above. Each proposal will include provisions allowing functional decomposition of multi-master replication into a proper subset required to implement master-slave replication. After vendor replication concept proposals have been harmonized, a single replication architecture document will be published. Six areas of working group focus have been identified through LDUP Engineering Team discussions: * Abstract Model of LDAP Replication This would document a general-purpose LDAP replication architecture, define key components of this architecture, describe how these key components functionally behave, and describe how these components interact with each other when in various modes of operation) * LDAP Replication Information Model Schema and semantics of information used to operate, administer, maintain, and provision replication between LDAP servers. Specifically, this document will contain common schema specifications intended to facilitate interoperable implementations with respect to: + replication agreements + consistency models + replication topologies + graveyards, tombstones, and zombies + administration and management * LDAP Replication Information Transport Protocol LDAP extended operation and control specifications required to allow LDAP to be used as the transport protocol for information being replicated * Mandatory Replica Management Specifications required to allow administration, maintenance, and provisioning of replicas and replication agreements. These specifications may take the form of definitions for LDAP extended operations, controls, and/or new schema elements. * Conflict Detection and Resolution Procedures Procedures for detection and resolution of conflicts between the state of multiple replicas that contain information from the same unit of replication. * Profiles Including the Abstract Replication Model, Information Model, LDAP Protocol Extensions, and Conflict Detection and Resolution Procedures for: + Master-Slave LDAP Directory Replication + Multi-Master LDAP Directory Replication Milestones: May 1998 Directory Replication Requirements and Applicability Statement I-D Published. May 1998 Vendors publish replication concept proposals to LDUP Engineering team mailing list. Jun 1998 Harmonization of vendor replication concept proposals is complete. Aug 1998 Directory Replication Requirements and Applicability Statement I-D goes to WG Last Call as Informational. Aug 1998 Abstract Model of LDAP Replication (based on the concensus of the LDUP Engineering Team) is published as an I-D. Sep 1998 LDAP Replication Information Model is published as an I-D. Sep 1998 LDAP Replication Information Transport Protocol is published as an I-D. Oct 1998 Abstract Model of LDAP Replication goes to WG Last Call as Informational. Oct 1998 Mandatory LDAP Replica Management is published as an I-D. Oct 1998 Conflict Detection and Resolution Procedures is published as an I-D. Nov 1998 LDAP Replication Information Model goes to WG Last Call as Proposed Standard. Nov 1998 LDAP Replication Information Transport Protocol goes to WG Last Call as Proposed Standard. Dec 1998 Master-Slave LDAP Replication Profile is published as an I-D. Dec 1998 Multi-Master LDAP Replication Profile is published as an I-D. Jan 1999 Mandatory LDAP Replica Management goes to WG Last Call as Proposed Standard. Jan 1999 Conflict Detection and Resolution Procedures goes to WG Last Call as Proposed Standard. Mar 1999 Master-Slave LDAP Replication Profile goes to WG Last Call as Proposed Standard. Mar 1999 Multi-Master LDAP Replication Profile goes to WG Last Call as Proposed Standard. From owner-ietf-ldup Sat Jul 25 23:22:16 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA03196 for ietf-ldup-bks; Sat, 25 Jul 1998 23:22:16 -0700 (PDT) Received: from i.control.att.com (H-135-205-52-126.control.att.com [135.205.52.126] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA03192 for ; Sat, 25 Jul 1998 23:22:14 -0700 (PDT) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Sun, 26 Jul 1998 02:23:12 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for paf@swip.net; Sun, 26 Jul 1998 02:23:11 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Sun, 26 Jul 1998 02:23:11 -0400 (EDT) From: capple@master.control.att.com (Christopher W Apple) To: Alan Lloyd , "'ietf-ldup@imc.org '" , "'capple@master.control.att.com '" Cc: "'johns@cisco.com '" , "'capple@control.att.com '" , "'paf@swip.net '" Subject: RE: LDUP WG Charter Sender: owner-ietf-ldup@imc.org Precedence: bulk Alan, In your comments (included below) I cannot find a single word that I can use to implement a change to the proposed charter. If you can't make comments that are designed to improve the charter and are implementable (e.g., "I suggest changing these words to the following..." or "I'm confused by what you mean by distributed in this context, could you add text to the charter to clarify its definition?"), it would be best if you made none at all. ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Service Internet Directory Group http://www.anywho.com AT&T Labs capple@master.control.att.com +1 908 582 2409 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ >From OpenDirectory.com.au!Alan.Lloyd Sat Jul 25 23:32:37 1998 >Return-Path: >From: Alan Lloyd >To: "'ietf-ldup@imc.org '" , > "'capple@master.control.att.com '" >Cc: "'johns@cisco.com '" , > "'capple@control.att.com '" > , > "'paf@swip.net '" >Subject: RE: LDUP WG Charter >X-Priority: 3 >MIME-Version: 1.0 >Content-Type: text/plain; > charset="iso-8859-1" > > Chris - in line with my usual style of response one should not confuse >the word "Distributed" with replicated. They are quite different in >directory operations. This replication work is of importance to the LDAP >server community who have to replicate everything to everywhere just to >do authentication of users to many servers. >Mind you the issue of cert path processing is still impossible in this >case.... :-((( > >As you know I think like most out here that replicate everything to >everywhere approach is operationally broken. > >As most are now saying now, LDAP is Hand-draulic ie what it does not do >- namely distribution and mutual authentication then humans have to with >LDIF, manual work and massess of replica utilities AND the bigger the >system gets the worse it becomes. > >Never the less some will require this but pehaps the urgency is to look >at scale. >On the other hand - one can see that most directory oriented companies >are realising that LDAP servers dont do much for "distributed" services >and their users and are going down then X.500 path which you know >already replicates quite well. > > I think the issue that should be addressed by LDAP servers suppliers is >that this will put them even further back behind X.500 distributed >systems. > >In addition one only has to say with 10 ldap servers and 10 replicas to >be managed to everywhere one needs a few more staff - and thats enough >to put people off. > > >But thats a choice eh? >regards alan > >---------- >From: capple@master.control.att.com >To: ietf-ldup@imc.org >Cc: johns@cisco.com; capple@control.att.com; paf@swip.net >Sent: 7/26/98 11:02:55 AM >Subject: LDUP WG Charter > >The charter John Strassner and I would like to send up for IESG review >follows. We'd like to limit the comment period to two (2) calendar >weeks. >This period starts now, 7/25/1998, and ends on 8/11/1998. > >Please post comments on the list. > >After the comment period, we will incorporate changes as concensus >indicates and send to the Apps Co-ADs with a request for IESG review >and approval to create the LDUP WG. > >John Strassner >Chris Apple > >IETF LDUP Proposed WG Co-Chairs > >Charter > >LDAP Duplication/Replication/Update Protocol(ldup) > >Chair(s): > Chris Apple > John Strassner > >Applications Area Director(s): > > Keith Moore > Patrik Faltstrom > >Operations and Management Area Advisor: > > Patrik Faltstrom > >Mailing lists: > General Discussion: ietf-ldup@imc.org > To Subscribe: ietf-ldup-request@imc.org > In Body: subscribe > Archive: http://www.imc.org/ietf-ldup/ > >Description of Working Group: > >As LDAP becomes more widely deployed, replication of data across >servers running different implementations becomes an important >part of providing a distributed directory service. However, the LDAP >community, to date, has focused on standardizing the client-server >access protocol. Therefore, this group will standardize master-slave >and multi-master LDAP replication as defined below: > > Multi-Master Replication - A replication model where entries can > be written and updated on any of several replica copies, without > requiring communication with other masters before the write or > update is performed. > > Master-Slave, or Single-Master Replication - A replication model > that assumes only one server, the master, allows write access to > the replicated data. Note that Master-Slave replication can be > considered a proper subset of multi-master replication. > >Our approach is to first develop a set of requirements for LDAP >directory replication and write an applicability statement defining >scenarios on which replication requirements are based. Once the >requirements and applicability statement have been drafted, the >working group will harmonize vendor/vendor-team replication concept >proposals; such concept proposals will be constructed in such a manner >as to support all forms of replication mentioned above. Each proposal >will include provisions allowing functional decomposition of >multi-master >replication into a proper subset required to implement master-slave >replication. After vendor replication concept proposals have been >harmonized, a single replication architecture document will be >published. > >Six areas of working group focus have been identified through >LDUP Engineering Team discussions: > > * Abstract Model of LDAP Replication > > This would document a general-purpose LDAP replication > architecture, define key components of this architecture, > describe how these key components functionally behave, > and describe how these components interact with each other > when in various modes of operation) > > * LDAP Replication Information Model > > Schema and semantics of information used to operate, > administer, maintain, and provision replication between > LDAP servers. Specifically, this document will contain > common schema specifications intended to facilitate > interoperable implementations with respect to: > > + replication agreements > + consistency models > + replication topologies > + graveyards, tombstones, and zombies > + administration and management > > * LDAP Replication Information Transport Protocol > > LDAP extended operation and control specifications > required to allow LDAP to be used as the transport > protocol for information being replicated > > * Mandatory Replica Management > > Specifications required to allow administration, > maintenance, and provisioning of replicas and > replication agreements. These specifications may > take the form of definitions for LDAP extended > operations, controls, and/or new schema elements. > > * Conflict Detection and Resolution Procedures > > Procedures for detection and resolution of conflicts > between the state of multiple replicas that contain > information from the same unit of replication. > > * Profiles > > Including the Abstract Replication Model, Information > Model, LDAP Protocol Extensions, and Conflict Detection > and Resolution Procedures for: > > + Master-Slave LDAP Directory Replication > + Multi-Master LDAP Directory Replication > >Milestones: > >May 1998 Directory Replication Requirements and Applicability > Statement I-D Published. > >May 1998 Vendors publish replication concept proposals to > LDUP Engineering team mailing list. > >Jun 1998 Harmonization of vendor replication concept proposals > is complete. > >Aug 1998 Directory Replication Requirements and Applicability > Statement I-D goes to WG Last Call as Informational. > >Aug 1998 Abstract Model of LDAP Replication (based on the > concensus of the LDUP Engineering Team) is published > as an I-D. > >Sep 1998 LDAP Replication Information Model is published as an I-D. > >Sep 1998 LDAP Replication Information Transport Protocol is > published as an I-D. > >Oct 1998 Abstract Model of LDAP Replication goes to WG Last Call > as Informational. > >Oct 1998 Mandatory LDAP Replica Management is published as an I-D. > >Oct 1998 Conflict Detection and Resolution Procedures is > published as an I-D. > >Nov 1998 LDAP Replication Information Model goes to WG Last Call as > Proposed Standard. > >Nov 1998 LDAP Replication Information Transport Protocol goes to > WG Last Call as Proposed Standard. > >Dec 1998 Master-Slave LDAP Replication Profile is published > as an I-D. > >Dec 1998 Multi-Master LDAP Replication Profile is published > as an I-D. > >Jan 1999 Mandatory LDAP Replica Management goes to WG Last Call > as Proposed Standard. > >Jan 1999 Conflict Detection and Resolution Procedures goes to > WG Last Call as Proposed Standard. > >Mar 1999 Master-Slave LDAP Replication Profile goes to WG Last Call > as Proposed Standard. > >Mar 1999 Multi-Master LDAP Replication Profile goes to WG Last Call > as Proposed Standard. > > From owner-ietf-ldup Sun Jul 26 16:37:03 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA17286 for ietf-ldup-bks; Sun, 26 Jul 1998 16:37:03 -0700 (PDT) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA17282 for ; Sun, 26 Jul 1998 16:36:53 -0700 (PDT) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id ; Mon, 27 Jul 1998 09:37:15 +1000 Message-ID: From: Alan Lloyd To: "''ietf-ldup@imc.org ' '" , "''capple@master.control.att.com ' '" Cc: "''johns@cisco.com ' '" , "''capple@control.att.com ' '" , "''paf@swip.net ' '" Subject: RE: LDUP WG Charter Date: Mon, 27 Jul 1998 09:37:14 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldup@imc.org Precedence: bulk Thanks Chris. It is hard to comment on something which compounds the problems with more "mechanisms" rather than solving the system deficiences abounding the industry with LDAP. notes follow: -snip >As LDAP becomes more widely deployed, replication of data across >servers running different implementations becomes an important >part of providing a distributed directory service. However, the LDAP >community, to date, has focused on standardizing the client-server >access protocol. Therefore, this group will standardize master-slave >and multi-master LDAP replication as defined below: The word distributed in the above para is used in the physical sense not in the directory naming context sense. Distributed directories are interconnected servers that have a distributed naming context. If you mis use words like that, the more uninformed will assume that LDUP cures distribution issues which to date have meant that all LDAP (non X.500) severs need their information replicated to everywhere. Which as I have said is a broken unscaleable concept. eg I want to authenticate Users on an expanding directory system User A has their name/password in their entry in server A. A wants to access B. Therefore we must copy A's entries to B. B wants to access A. Therefore we must copy B's entries to A. C server wants to connect to the system with C's users. C wants to access A and B. Therefore we must copy C's entries to A & B. A wants to access C. Therefore we must copy A's entries to C. B wants to access C. Therefore we must copy B's entries to C. The UK now wants to talk via the directory system to the US, the Pac Rim wants to talk the rest of the world.. Now we have to copy all things to all people in all servers - and manage the people migration/mobility issues...across the whole world. I do not know where this replication push is coming from nor do I understand why LDAP server suppliers are even insisting on it. It is obvious that those trying to deploy such products must have to grit their teeth when asked how do I connect 10 of these LDAP server things together and how do I keep them effective..How many humans do I need. What happens if I want to access other directory systems? > > Multi-Master Replication - A replication model where entries can > be written and updated on any of several replica copies, without > requiring communication with other masters before the write or > update is performed. Is this multi master - all MM modes must ensure synchronous operation. snip > >Six areas of working group focus have been identified through >LDUP Engineering Team discussions: > > * Abstract Model of LDAP Replication > > This would document a general-purpose LDAP replication > architecture, define key components of this architecture, > describe how these key components functionally behave, > and describe how these components interact with each other > when in various modes of operation) This will probably need the notion of admin points, subentries and DSE types - eg master copy entries. > > * LDAP Replication Information Model > > Schema and semantics of information used to operate, > administer, maintain, and provision replication between > LDAP servers. Specifically, this document will contain > common schema specifications intended to facilitate > interoperable implementations with respect to: > > + replication agreements > + consistency models > + replication topologies > + graveyards, tombstones, and zombies > + administration and management Not in love with replicating zombies and tomestones and grave yards - particularly in MM mode - that will hurt the implentors - but thats just a view.- But to get any form of consistency into the model for replication one needs a DIT management model - see X.500. > > * LDAP Replication Information Transport Protocol > > LDAP extended operation and control specifications > required to allow LDAP to be used as the transport > protocol for information being replicated But this is operation on object focussed - not a bulk atomic protocol as the LDAP ext have discussed - It will be difficult to turn a object operation protocol into an atomic bulk protocol - without making more of a mess of LDAP than what it is. X.500 - DAP, DISP and DSP all for very good reasons. But developing systems that way is the choice of the vendors isnt it. As a point - the more one puts into LDAP the more complex and the more incompatable and the moore unreliable the client and the servers will become. Seperate protocols for different things are good - particularly when those diffrences relate to object oriented interactions and bulk atomic inter server transactions. regards alan From owner-ietf-ldup Mon Jul 27 05:55:21 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA02186 for ietf-ldup-bks; Mon, 27 Jul 1998 05:55:21 -0700 (PDT) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id FAA02180 for ; Mon, 27 Jul 1998 05:55:19 -0700 (PDT) Received: (qmail 8053 invoked from network); 27 Jul 1998 12:56:48 -0000 Received: from usera779.uk.uudial.com (HELO jacobsrimell.com) (193.149.69.17) by smtp.dial.pipex.com with SMTP; 27 Jul 1998 12:56:48 -0000 Message-ID: <35BC7982.436C9604@jacobsrimell.com> Date: Mon, 27 Jul 1998 13:58:43 +0100 From: Ian Parrott Organization: Jacobs Rimell Limited X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Christopher W Apple CC: Alan Lloyd , "'ietf-ldup@imc.org '" , "'johns@cisco.com '" , "'capple@control.att.com '" , "'paf@swip.net '" Subject: Re: LDUP WG Charter References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk Chris, As a relative newcomer in the integration and implementation of directory solutions (brought about by the success of LDAP as the directory access protocol), could I ask why there is a focus on replication only between LDAP servers, rather than both distribution and replication? Is there a separate working group planned for distribution? Also, I have spent much time coming upto speed on the "state of play" of LDAP and X500, and as X500 has clearly tackled these requirements in some detail over the past ten years, has there been much effort by the LDAP community to learn from and even adopt the DSP and DISP protocols? It seems strange that so much energy appears to be going into something that, at least on the face of it, already exists. Thanks, Ian. -- Ian Parrott Jacobs Rimell Ltd Office: (44) (0) 171 739 0850 Mobile: (44) (0) 411 527 260 FAX: (44) (0) 171 739 0860 Email: ian.parrott@jacobsrimell.com ---------- Christopher W Apple wrote: > Alan, > > In your comments (included below) I cannot find a single word > that I can use to implement a change to the proposed charter. > > If you can't make comments that are designed to improve the > charter and are implementable (e.g., "I suggest changing these > words to the following..." or "I'm confused by what you mean > by distributed in this context, could you add text to the > charter to clarify its definition?"), it would be best if > you made none at all. > > ------------------------------------------------------------------------ > Chris Apple Business Site: AnyWho Directory Service > Internet Directory Group http://www.anywho.com > AT&T Labs > capple@master.control.att.com > +1 908 582 2409 Tired of slow directories? Try AnyWho. > ------------------------------------------------------------------------ > >From OpenDirectory.com.au!Alan.Lloyd Sat Jul 25 23:32:37 1998 > >Return-Path: > >From: Alan Lloyd > >To: "'ietf-ldup@imc.org '" , > > "'capple@master.control.att.com '" > >Cc: "'johns@cisco.com '" , > > "'capple@control.att.com '" > > , > > "'paf@swip.net '" > >Subject: RE: LDUP WG Charter > >X-Priority: 3 > >MIME-Version: 1.0 > >Content-Type: text/plain; > > charset="iso-8859-1" > > > > Chris - in line with my usual style of response one should not confuse > >the word "Distributed" with replicated. They are quite different in > >directory operations. This replication work is of importance to the LDAP > >server community who have to replicate everything to everywhere just to > >do authentication of users to many servers. > >Mind you the issue of cert path processing is still impossible in this > >case.... :-((( > > > >As you know I think like most out here that replicate everything to > >everywhere approach is operationally broken. > > > >As most are now saying now, LDAP is Hand-draulic ie what it does not do > >- namely distribution and mutual authentication then humans have to with > >LDIF, manual work and massess of replica utilities AND the bigger the > >system gets the worse it becomes. > > > >Never the less some will require this but pehaps the urgency is to look > >at scale. > >On the other hand - one can see that most directory oriented companies > >are realising that LDAP servers dont do much for "distributed" services > >and their users and are going down then X.500 path which you know > >already replicates quite well. > > > > I think the issue that should be addressed by LDAP servers suppliers is > >that this will put them even further back behind X.500 distributed > >systems. > > > >In addition one only has to say with 10 ldap servers and 10 replicas to > >be managed to everywhere one needs a few more staff - and thats enough > >to put people off. > > > > > >But thats a choice eh? > >regards alan > > > >---------- > >From: capple@master.control.att.com > >To: ietf-ldup@imc.org > >Cc: johns@cisco.com; capple@control.att.com; paf@swip.net > >Sent: 7/26/98 11:02:55 AM > >Subject: LDUP WG Charter > > > >The charter John Strassner and I would like to send up for IESG review > >follows. We'd like to limit the comment period to two (2) calendar > >weeks. > >This period starts now, 7/25/1998, and ends on 8/11/1998. > > > >Please post comments on the list. > > > >After the comment period, we will incorporate changes as concensus > >indicates and send to the Apps Co-ADs with a request for IESG review > >and approval to create the LDUP WG. > > > >John Strassner > >Chris Apple > > > >IETF LDUP Proposed WG Co-Chairs > > > >Charter > > > >LDAP Duplication/Replication/Update Protocol(ldup) > > > >Chair(s): > > Chris Apple > > John Strassner > > > >Applications Area Director(s): > > > > Keith Moore > > Patrik Faltstrom > > > >Operations and Management Area Advisor: > > > > Patrik Faltstrom > > > >Mailing lists: > > General Discussion: ietf-ldup@imc.org > > To Subscribe: ietf-ldup-request@imc.org > > In Body: subscribe > > Archive: http://www.imc.org/ietf-ldup/ > > > >Description of Working Group: > > > >As LDAP becomes more widely deployed, replication of data across > >servers running different implementations becomes an important > >part of providing a distributed directory service. However, the LDAP > >community, to date, has focused on standardizing the client-server > >access protocol. Therefore, this group will standardize master-slave > >and multi-master LDAP replication as defined below: > > > > Multi-Master Replication - A replication model where entries can > > be written and updated on any of several replica copies, without > > requiring communication with other masters before the write or > > update is performed. > > > > Master-Slave, or Single-Master Replication - A replication model > > that assumes only one server, the master, allows write access to > > the replicated data. Note that Master-Slave replication can be > > considered a proper subset of multi-master replication. > > > >Our approach is to first develop a set of requirements for LDAP > >directory replication and write an applicability statement defining > >scenarios on which replication requirements are based. Once the > >requirements and applicability statement have been drafted, the > >working group will harmonize vendor/vendor-team replication concept > >proposals; such concept proposals will be constructed in such a manner > >as to support all forms of replication mentioned above. Each proposal > >will include provisions allowing functional decomposition of > >multi-master > >replication into a proper subset required to implement master-slave > >replication. After vendor replication concept proposals have been > >harmonized, a single replication architecture document will be > >published. > > > >Six areas of working group focus have been identified through > >LDUP Engineering Team discussions: > > > > * Abstract Model of LDAP Replication > > > > This would document a general-purpose LDAP replication > > architecture, define key components of this architecture, > > describe how these key components functionally behave, > > and describe how these components interact with each other > > when in various modes of operation) > > > > * LDAP Replication Information Model > > > > Schema and semantics of information used to operate, > > administer, maintain, and provision replication between > > LDAP servers. Specifically, this document will contain > > common schema specifications intended to facilitate > > interoperable implementations with respect to: > > > > + replication agreements > > + consistency models > > + replication topologies > > + graveyards, tombstones, and zombies > > + administration and management > > > > * LDAP Replication Information Transport Protocol > > > > LDAP extended operation and control specifications > > required to allow LDAP to be used as the transport > > protocol for information being replicated > > > > * Mandatory Replica Management > > > > Specifications required to allow administration, > > maintenance, and provisioning of replicas and > > replication agreements. These specifications may > > take the form of definitions for LDAP extended > > operations, controls, and/or new schema elements. > > > > * Conflict Detection and Resolution Procedures > > > > Procedures for detection and resolution of conflicts > > between the state of multiple replicas that contain > > information from the same unit of replication. > > > > * Profiles > > > > Including the Abstract Replication Model, Information > > Model, LDAP Protocol Extensions, and Conflict Detection > > and Resolution Procedures for: > > > > + Master-Slave LDAP Directory Replication > > + Multi-Master LDAP Directory Replication > > > >Milestones: > > > >May 1998 Directory Replication Requirements and Applicability > > Statement I-D Published. > > > >May 1998 Vendors publish replication concept proposals to > > LDUP Engineering team mailing list. > > > >Jun 1998 Harmonization of vendor replication concept proposals > > is complete. > > > >Aug 1998 Directory Replication Requirements and Applicability > > Statement I-D goes to WG Last Call as Informational. > > > >Aug 1998 Abstract Model of LDAP Replication (based on the > > concensus of the LDUP Engineering Team) is published > > as an I-D. > > > >Sep 1998 LDAP Replication Information Model is published as an I-D. > > > >Sep 1998 LDAP Replication Information Transport Protocol is > > published as an I-D. > > > >Oct 1998 Abstract Model of LDAP Replication goes to WG Last Call > > as Informational. > > > >Oct 1998 Mandatory LDAP Replica Management is published as an I-D. > > > >Oct 1998 Conflict Detection and Resolution Procedures is > > published as an I-D. > > > >Nov 1998 LDAP Replication Information Model goes to WG Last Call as > > Proposed Standard. > > > >Nov 1998 LDAP Replication Information Transport Protocol goes to > > WG Last Call as Proposed Standard. > > > >Dec 1998 Master-Slave LDAP Replication Profile is published > > as an I-D. > > > >Dec 1998 Multi-Master LDAP Replication Profile is published > > as an I-D. > > > >Jan 1999 Mandatory LDAP Replica Management goes to WG Last Call > > as Proposed Standard. > > > >Jan 1999 Conflict Detection and Resolution Procedures goes to > > WG Last Call as Proposed Standard. > > > >Mar 1999 Master-Slave LDAP Replication Profile goes to WG Last Call > > as Proposed Standard. > > > >Mar 1999 Multi-Master LDAP Replication Profile goes to WG Last Call > > as Proposed Standard. > > > > From owner-ietf-ldup Sat Aug 8 15:50:19 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA26676 for ietf-ldup-bks; Sat, 8 Aug 1998 15:50:19 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA26672 for ; Sat, 8 Aug 1998 15:50:17 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id PAA25344 for ; Sat, 8 Aug 1998 15:52:25 -0700 (PDT) Received: from netscape.com ([208.12.63.182]) by dredd.mcom.com (Netscape Messaging Server 3.52) with ESMTP id AAA58E1; Sat, 8 Aug 1998 15:52:23 -0700 Message-ID: <35CCD6A6.8548A303@netscape.com> Date: Sat, 08 Aug 1998 15:52:22 -0700 From: John Merrells Organization: Netscape Communications X-Mailer: Mozilla 4.06 [en]C-NSCP (WinNT; U) MIME-Version: 1.0 To: LDUP-REPL , LDUP Subject: LDAP Replication Architecure Draft Content-Type: multipart/mixed; boundary="------------2B6403165D3712A1363BA1B0" Sender: owner-ietf-ldup@imc.org Precedence: bulk This is a multi-part message in MIME format. --------------2B6403165D3712A1363BA1B0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Fellow LDUPers, Please find attached the first draft of the LDAP Replication Architecture draft. I posted it to internet-drafts on Friday, but managed to mis-address the message, then a construction crew brought down a power line wiping out most of the campus. So, I didn't realise the message bounced until today. So, it doesn't look like it'll be an official I-D by the next IETF meeting... But, I don't think that's any real impediment to our work. Please post your comments to ietf-ldup@imc.org. John, Ed & Uppili -- John Merrells, Software Engineer Netscape Communications, Directory Server http://people.netscape.com/merrells --------------2B6403165D3712A1363BA1B0 Content-Type: text/plain; charset=iso-8859-1; name="draft-merrells-ldup-model-00.txt" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="draft-merrells-ldup-model-00.txt" INTERNET-DRAFT draft-merrells-ldup-model-00.txt John Merrells Netscape Communications Corp. Ed Reed Novell, Inc. Uppili Srinivasan Oracle, Inc. August 5, 1998 LDAP Replication Architecture Copyright (C) The Internet Society (1998). All Rights Reserved. Status of this Memo This draft, file name draft-merrells-ldup-model-00.txt, is intended to be become a Proposed Standard RFC, to be published by the IETF Working Group LDUP, when it is formed. Distribution of this document is unlimited. Comments should be sent to the LDUP Replication mailing list or to the authors. This document is an Internet-Draft. 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 made obsolete 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 entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). This Internet-Draft expires on 5 February 1999. Merrells, Reed, Srinivasan [Page 1] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 1. Abstract 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. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. The sections below reiterate these definitions and include some additional ones. Merrells, Reed, Srinivasan [Page 2] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 2. Table of Contents 1. Abstract 2 2. Table of Contents 3 3. Introduction 4 3.1 Scope 4 3.2 Document Objectives 5 3.3 Document Non-Objectives 6 3.4 Terms and Definitions 7 4. Overview 8 4.1 Directory Model 8 4.2 Information Model 8 4.3 Policy Information 9 4.4 Update Transfer Protocol 9 4.5 Replication Configuration and Management 9 4.6 Update Vector 10 4.7 Time 10 5. Directory Model 10 5.1 Replica Type 10 5.2 Sub-Entries 11 5.3 LDAP Change Sequence Numbers 11 5.4 State Storage and Representation 12 5.5 LDAP Update Operations 13 5.6 Purging State Information 13 5.7 Replication Schedule 14 6. Information Model 14 6.1 Entries, Semantics & Relationships 15 6.1.1 Root DSE Attributes 15 6.1.2 Naming Context Auxiliary Object Class and Entries 15 6.1.3 Replica Object Class and Entries 15 6.1.4 Replication Agreement Object Class and Entries 16 6.1.5 Update Vector 16 6.2 Unique Identifiers 17 7. Policy Information 17 7.1 Access Control 18 7.2 Schema Knowledge 18 8. Update Transfer Protocol 19 8.1 Session Initiation 19 8.1.1 Authentication 19 8.1.2 Consumer Initiated 19 8.1.3 Supplier Initiated 20 8.1.4 Start Replication Request 20 8.1.5 Start Replication Response 21 8.2 Update Transfer 21 8.2.1 Full Update Transfer 22 8.2.2 Incremental Update Transfer 22 Merrells, Reed, Srinivasan [Page 3] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 8.2.2.1 Conflict Detection and Resolution 23 8.3 End Replication Session 24 8.3.1 Full Update End Replication Session 24 8.3.2 Incremental Update End Replication Session 24 8.3.3 End Replication Request 25 8.3.4 End Replication Response 25 8.4 Integrity & Confidentiality 26 9. Replication Configuration and Management 26 10. Time 28 11. Security Considerations 28 12. Acknowledgements 28 13. References 29 14. Intellectual Property Notice 30 15. Copyright Notice 30 16. Authors' Address 31 17. Appendix A - Open Issues 32 17.1 Replication Session Initiation 32 17.2 Lost and Found Container 32 17.3 Write Conflicts 32 17.4 Management and Configuration 32 17.5 Sparse, Fractional, and Partial Replicas 33 17.6 Update Transfer: Errors, Recovery, Diagnostics and Repair 33 17.7 Update Access Control 33 3. Introduction 3.1 Scope This architectural document provides an outline of an LDAP based replication scheme. Further detailed design documents will draw guidance from here. The design proceeds from prior work in the industry, including concepts from the ITU-T Recommendation X.525 (1993, 1997) Directory Information Shadowing Protocol (DISP) [X525], experience with widely deployed distributed directories in network operating systems, electronic mail address books, and other database technologies. The emphasis of the design is on: - Simplicity of operation, - Flexibility of configuration. Merrells, Reed, Srinivasan [Page 4] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 - Manageability of replica operations among mixed heterogeneous vendor LDAP servers under common administration. - Security of content and configuration information when LDAP servers from more than one administrative authority are interconnected. A range of deployment scenarios are supported, including multi-master and single-master topologies. Replication networks may include transitive and redundant relationships between LDAP servers. The controlling framework used to define the relationships, types, and state of replicas of the directory content is defined. In this way the directory content can itself be used to monitor and control the replication network. The directory schema is extended to define object classes, auxiliary classes, and attributes that describe areas of the namespace which are replicated, LDAP servers which hold replicas of various types for the various partitions of the namespace, LDAP Access Points (network addresses) where such LDAP servers may be contacted, which namespaces are held on given LDAP servers, and the progress of replication operations. Among other things, this knowledge of where directory content is located will provide the basis for dynamic generation of LDAP referrals for clients to follow. [REF] An update transfer protocol, which actually brings a replica up to date with respect to changes in directory content at another replica, is defined using LDAPv3 protocol extensions. The representation of directory content and changes will be defined by the LDAP Replication Update Transfer Protocol sub-team. Incremental and full update transfer mechanisms are described. Replication protocols are required to include initial population, change updates, and removal of directory content. Security information, including access control policy will be treated as directory content by the replication protocols. Confidentiality and integrity of replication information is required to be provided by lower-level transport/session protocols such as IPSEC and/or TLS. The architecture will describe required and optional house-keeping duties for compliant systems to implement, such as garbage collection of deleted entries. 3.2 Document Objectives The following list enumerates the objectives of this document. a) To define the architectural foundations for LDAP Replication, so that further detailed design documents may be written. For Merrells, Reed, Srinivasan [Page 5] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 instance, the Information Model, Update Transfer Protocol, and Conflict Detection and Resolution documents. b) Provide an architectural solution for each clause of the requirements document [LDUP Requirements]. c) To preserve the atomicity of LDAP operations. Updates to an entry, from multiple sources, will be combined such that the resultant entry is equivalent to a serial execution of the operations. d) To avoid tying the LDUP working group to the schedule of any other working group. e) Not to infringe known registered intellectual property. 3.3 Document Non-Objectives This document does not address the following issues, as they are considered beyond the scope of the Working Group. The following list describes the features we are not addressing in this document. a) How LDAP becomes a distributed directory. There are many issues beyond replication that should be considered. Such as, support for external references, algorithms for computing referrals from the distributed directory knowledge, etc. b) Specifying management protocols to create naming contexts or new replicas. LDAP may be sufficient for this. The document describes how new replicas and naming contexts are represented, in the directory, as entries, attributes, and attribute values. c) How transactions will be replicated. However, the architecture should not knowingly prevent or impede them, given the Working Group's incomplete understanding of the issues at this time. d) The mapping or merging of disparate Schema definitions. e) Support of overlapping replicated regions. f) The case where separate attributes of an entry may be mastered by different LDAP servers. This might be termed a 'Split Primary'. Replica roles are defined in section 5.1. Merrells, Reed, Srinivasan [Page 6] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 3.4 Terms and Definitions The definitions from the Replication Requirements document have been copied here and extended. For brevity, an LDAP server implementation to referred to throughout as 'the server'. The Naming Context is a subtree of entries in the Directory Information Tree (DIT). There may be multiple Naming Contexts stored on a single server. Naming contexts are defined in section 17 of X.501 A Replica is an instance of a replicated Naming Context. A Replication Relationship is established between two or more Replicas that are hosted on servers that cooperate to service a common area of the DIT. A Replication Agreement is defined between two parties of a Replication Relationship. The properties of the agreement codify the Unit of Replication, the Update Transfer Protocol to be used, and the Replication Schedule of a Replication Session. A Replication Session is an LDAP session between the two servers identified by a replication agreement. Interactions occur between the two servers, resulting in the transfer of updates from the supplier replica to the consumer replica. The Initiator of a Replication Session is the initiating server. A Responder server responds to the replication initiation request from the Initiator server. A Supplier server is the source of the updates to be transferred. A Consumer server is the recipient of the update sequence. The Update Transfer Protocol is the means by which the Replication Session proceeds. It defines the order of events, and update exchange mechanism between the Replication Relationship partners. An Entry Filter is an LDAP filter expression that describes the entries to be replicated. A Sparse Replica contains a subset of the naming context entries, being modified by the Entry Filter criteria associated with the replica. Merrells, Reed, Srinivasan [Page 7] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 A Fractional Entry Specification is a list of entry attributes to be included, or a list of attributes to be excluded in a replica. An empty specification implies that all entry attributes are included. A Fractional Entry is an entry that contains only a subset of its original attributes. It has been modified by a Fractional Entry Specification. A Fractional Replica is a replica that holds Fractional Entries of its naming context. Note that a Fractional Replica can also be a sparse replica. A Partial Replica is both a Sparse and Fractional Replica. 4. Overview This section provides an overview of the LDAP Replication architecture. It is broken down into Directory Model, Information Model, Policy Information, Update Transfer Protocol, Replication Configuration and Management, Update Vector, and Time. The remainder of the document discusses each in detail. 4.1 Directory Model The basic directory model must be extended in a number of ways. a) The Replication Management entries require a sub-entry object class to effectively hide them from end-user clients. b) A form of timestamp, a Change Sequence Number (CSN), must be recorded with every change to every entry. The change may be the creation of a new entry, the modification of an existing entry, or the deletion of an existing entry. c) Server implementations may need to include a CSN purging feature to control Directory Information Base (DIB) storage space. 4.2 Information Model The Naming Context Auxiliary Class is added to container entries that may have separately defined replication policy. [LDUP Info] Immediately subordinate to a Naming Context entry are the Replica Subentry container entries that identify its LDAP Access Point, its Merrells, Reed, Srinivasan [Page 8] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 replica type (Primary, Updateable, Read-Only), if it is sparse, the LDAP search filter defining which entries it holds, and if it is fractional, the attributes it does or does not hold. Immediately subordinate in the namespace to a Replica Subentry are Replication Agreement leaf entries which each identify another Replica, the scheduling policy for replication operations, including times when replication is to be performed, when it is not to be performed, or the policies governing event-driven replication initiation. 4.3 Policy Information Administrative policy information needs to be consistently known and applied by all replicas of a Naming Context. As such, the Naming Context Auxiliary Class provides a convenient way to define attributes which can communicate those policies among all replicas and users of the directory. 4.4 Update Transfer Protocol A Replication Session occurs between a Supplier server and Consumer server over an LDAP connection. The session initiator, termed the Initiator, could be either the Supplier or Consumer. The Initiator sends an LDAP extended operation to the Responder identifying the replication agreement being acted on. The Supplier then sends a sequence of updates to the Consumer. If the replica contents can be changed in more than one place then updates may conflict. As the consumer applies changes it must detect and resolve these conflicts. Change Sequence Numbers on each entry and each change enable the consumer to maintain the correct total ordering of updates. All transfers are in one direction only. A two way exchange requires two replication sessions; one session in each direction. 4.5 Replication Configuration and Management The management entries described in the Information Model may be created, modified, and deleted by administrative clients to configure and manage the replication network. The administrative operations performed over LDAP are discussed further in section 9. Merrells, Reed, Srinivasan [Page 9] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 4.6 Update Vector Each Replica holds an Update Vector that records the most recent change it has received for each of the other Replicas of this Naming Context. The vector is used at the initiation of a replication session to determine the sequence of updates that should be transferred. 4.7 Time Because Change Sequence Numbers are primarily based on timestamps, clock differences between servers can cause unexpected change ordering. The synchronization of server clocks is not required, though it is preferable that clocks are accurate. 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 effect and the real world time ordering of updates will not be maintained. However, an implementation may choose to require clock synchronisation. The Network Time Protocol [NTP] [SNTP] offers a protocol means by which heterogeneous server hosts may be time synchronised. 5. Directory Model The following sections describe changes to the basic directory model that are required by the replication architecture. 5.1 Replica Type Each Replica is characterized with a replica type. This may be Primary, Updatable, or Read-Only. The latter two types may be further defined as being Sparse, Fractional, or Partial. The Primary Replica is a full copy of the Replica, to which all applications that require strong consistency should direct their LDAP operations. There can be only one Primary Replica within the set of Replicas of a given Naming Context. It is also permissible for none of the Replicas to be designated the Primary. An Updatable Replica is a Replica that accepts all LDAP operations, but is not the Primary Replica. There could be none, one, or many Updatable Replicas within the set of Replicas of a given Naming Context. Merrells, Reed, Srinivasan [Page 10] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 A Read-Only Replica will accept only non-modifying LDAP operations. All modification operations will be referred to an updateable Replica, usually to its supplier. 5.2 Sub-Entries Replication management entries are to be stored at the base of the replicated naming context. They will be of a subentry objectclass to exclude them from regular searches. Entries with the objectclass subentry are not returned as the result of a search unless the filter component "(objectclass=subentry)" is included. 5.3 LDAP Change Sequence Numbers Every change, caused by an LDAP update operation, is assigned a sequence number. The Change Sequence Number (CSN) is formed of three components. In order of significance they are; the time, a replica id number, and a change count. The time component is a year-2000-safe representation of the real world time, with a granularity of one second. Should LDAP update operations occur at different replicas, to the same data, within the same single second, then the replica id is used to further order the changes. Because LDAP update operations at a single replica may also occur to the same data in a single second, the 'change count' component of the CSN is provided to definitely order the changes. Each replica maintains a count of changes made against it, which is reset to zero at the start of each second, and is monotonically increasing within the second, incremented for each LDAP update operation applied to the replica. The preferred time syntax is: yyyy mm dd hh:mi:ssz # replica id # 0xssss The "z" in the time stipulates that the time is expressed in GMT without any daylight savings time offsets permitted, and the 0xssss represents the hexidecimal representation of an unsigned integer. Implementations must support 16 bit change counts and should support longer ones (32, 64, 128). An example CSN would be " 1998081018:44:31z#1#0x000F " Merrells, Reed, Srinivasan [Page 11] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 5.4 State Storage and Representation All changes made to an entry, and its attributes, include the CSN assigned at the server where the change was first made. Each of the LDAP update operations Add, Modify, Modify RDN (LDAP v2), Modify DN (LDAP v3), and Delete change their target entry in different ways, and record the CSN of the change differently. This state information must be stored for each entry to enable Conflict Detection and Resolution. State information is recorded at three levels within each entry. At the entry level, attribute level, and attribute value level. Each is briefly described below. 5.4.1 Entry Change State Storage and Representation When an entry is created, with the LDAP Add operation, the CSN of the change is added to the entry as the value of an operational attribute named 'createdEntryCSN', of syntax type LDAPChangeSequenceNumber. createdEntryCSN ::= csn Deleted entries are marked as deleted by the addition of the object class 'deletedEntry'. The attribute 'deletedEntryCSN', of syntax type LDAP Change Sequence Number, is added to record where and when the entry was deleted. Deleted entries are not visible to LDAP clients - they may not be read, they don't appear in lists or search results, and they may not be changed once deleted. Names of deleted entries are available for reuse by new entries immediately after the deleted entry is so marked. It may be desirable to allow deleted entries to be accessed and manipulated by management and data recovery applications, but that is outside the scope of this document. deletedEntryCSN ::= csn 5.4.2 Attribute Change State Storage and Representation When all values of an attribute have been deleted, the attribute is marked as deleted and the CSN of the deletion is recorded. The deleted state and CSN are stored by the server, but have no representation on the entry, and may not be the subject of a search operation. This state information must be stored to enable Conflict Detection and Resolution to be performed. Merrells, Reed, Srinivasan [Page 12] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 5.4.3 Attribute Value Change State Storage and Representation The Modification CSN for each value is to be set by the server when it accepts a modification request to the value, or when a new value with a later Modification CSN is received via Replication. The modified value and the Modification CSN changes are required to be atomic, so that the value and its Modification CSN cannot be out of synch on a given server. The state information is stored by the server, but it has no representation on the entry, and may not be the subject of a search operation. When the value of an attribute is deleted the state of its deletion must recorded, with the CSN of the modifying change. It must be stored to enable Conflict Detection and Resolution to be performed. 5.5 LDAP Update Operations The server must reject LDAP client update operations with a CSN that is older than the state information that would be replaced if the operation were performed. This could occur in a replication topology where the difference between the clocks of updateable replicas was too large. Result code 72, serverClocksOutOfSync, is returned to the client. 5.6 Purging State Information The state information stored with each entry need not be stored indefinitely. A server implementation may choose to periodically, or continuously, remove state information that is no longer required. The mechanism is implementation-dependent, but to ensure interoperability between implementations, the state information must not be purged until all known replicas have received and acknowledged the change associated with a CSN. This can be determined by constructing an Update Vector containing the lowest CSN for each replica from all the known replicas. All the CSNs stored that are lower than this Update Vector may be purged, because no changes with older CSNs will be replicated to this replica. 5.6.1 Purging Deleted Entries, Attributes, and Attribute Values The following conditions must hold before an item can be deleted from the Directory Information Base. 1) The LDAP delete operation has been propagated to all replication agreement partners. Merrells, Reed, Srinivasan [Page 13] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 2) All the updates from all the other replicas with timestamps less than the timestamp on the deletion have been propagated to the server holding the deleted object (similarly for deleted attributes and attribute values). 3) The clocks of the other Replicas must have advanced beyond the deletion CSN of the deleted entry. Otherwise, it is possible for one of those Replicas to generate operations with CSNs earlier than the deleted object. 5.7 Replication Schedule There are two broad mechanisms for initiating replication sessions: (1) scheduled event driven and (2) change event driven. The mechanism is used to schedule replication operations between two servers is determined by the Schedule information that is part of the Replication Agreement governing the Replicas on those two servers. Because each Replication Agreement describes the policy for one direction of the relationship, it is possible that events propagate via scheduled events in one direction, and by change events in the other. Change event driven replication sessions are, by their nature, initiated by suppliers of change information. The server, which the change is made against, schedules a replication session in response to the change itself, so that notification of the change is passed on to other Replicas. Scheduled event driven replication sessions can be initiated by either consumers or suppliers of change information. The schedule defines a calendar of time periods during which Replication Sessions should be initiated. Schedule information may include both scheduled and change event driven mechanisms. For instance, one such policy may be to begin replication within 15 seconds of any change event, or every 30 minutes if no change events are received. 6. Information Model This section describes the object classes of the entries that represent the replication topology. The where, when and how of Naming Context replication is administered through these entries. The LDUP Working Group will publish an Internet Draft to fully detail all these schema elements. [LDUP Info] Merrells, Reed, Srinivasan [Page 14] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 6.1 Entries, Semantics & Relationships 6.1.1 Root DSE Attributes The Root DSE attribute 'replicaRoot', publishes the names of the Replicas that are held on that server. Each value of the attribute is the Distinguished Name of the root entry of the Replicated Area. 6.1.2 Naming Context Auxiliary Object Class and Entries Each Naming Context contains attributes which hold common configuration and policy information for all replicas of the Naming Context. A Naming Context Creation attribute records when and where the Naming Context was created. The Access Control Policy OID attribute defines the syntax and semantics of Access Control Information for entries within the Naming Context. The Naming Context is based at the entry given the auxiliary class, and continues down the tree until another Naming Context is encountered. 6.1.3 Replica Object Class and Entries Each Replica is characterized by a replica type. This may be Primary, Updatable, or Read-Only. The latter two types may be further defined as being Sparse, Fractional, or Partial. The Replica entry will include an Entry Filter for a Sparse Replica, a Fractional Entry Specification for a Fractional Replica, and both for a Partial Replica There is a need to represent network addresses of servers holding replicas and participating in Replication Agreements. The X.501 Access Point syntax is not sufficient, in that it is tied specifically to OSI transports. Therefore, a new syntax will be defined for LDAP which serves the same purpose, but uses IETF-style address information. [LDUP Info] An Update Vector (described below) describes the point to which the Replica has been updated, in respect to all the other Replicas of the Naming Context. Merrells, Reed, Srinivasan [Page 15] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 The intent is to enable distributed operations in LDAP with the replica information stored there, but not to complete the process of turning LDAP into a fully distributed service. 6.1.4 Replication Agreement Object Class and Entries The Replication Agreement defines: - The schedule for Replication Sessions initiation. - Which server initiates the Replication Session. Either Consumer, or Supplier. - The authentication credentials that will be presented between servers. - The network/transport security scheme that will be employed in order to ensure data confidentiality. - The replication protocols and relevant protocol parameters to be used for Full and Incremental updates. An OID is used to identify the update transfer protocol, thus allowing for future extensions or bilaterally agreed upon alternatives. Permission to participate in replication sessions will be controlled, at least in part, by the presence and content of replica agreements. 6.1.5 Update Vector Each Replica entry includes an Update Vector to record the point to which the replica has been updated. The vector is a set of CSN values, one value for each known updateable Replica. Each CSN is the most recent change, made at that Replica, that has been replicated to this Replica. It may be the case that a CSN for a given replica is absent, for one of two reasons. - CSNs for Read-Only replicas might be absent because no changes will have ever been applied to that Replica, so there are no changes to replicate. - CSNs for newly created replicas may be absent because no changes to that replica have yet been propagated. An Update Vector might contain a CSN for a replica that no longer exists. The replica may have been temporarily taken out of service, or may have been removed from the replication topology permanently. An Merrells, Reed, Srinivasan [Page 16] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 implementation may choose to retire a CSN after some configurable time period. Since the Update Vector records the state to which the replica has been updated, a supplier server, during Replication Session initiation, can determine the sequence of updates that should be sent to the consumer. The Update Vector embodies knowledge of updates made at all known replicas ensuring that changes are not transferred to a consumer multiple times. This would otherwise occur in the case where redundant replication agreements existed. Unnecessary transfers are eliminated because each replica maintains the highest CSN it has seen for all other replicas, not just the supplier replica. 6.2 Unique Identifiers Distinguished names can change, so are therefore unreliable as identifiers. A Unique Identifier must therefore be assigned to each entry as it is created. This identifier will be stored as an operational attribute of the entry. The unique identifier could be generated by a number of algorithms, so we propose that the first octet be a prefix to identify its type. The prefix zero is reserved to signify the UUID (Universally Unique IDentifier) format, also known as GUID (Globally Unique IDentifier) [UUID]. Support for alternative algorithms is provided so that future better unique identifier generation algorithms may be easily adopted. Implementations may also wish to impose some structure to their unique identifiers to ease implementation of Conflict Detection & Resolution. 7. Policy Information Policy information governs the behavior of the server. It may be represented in the DIT as sub-entries, attributes, and attribute values. When replicating a naming context that is itself a subtree of another naming context, there may be policy information stored in its antecedent entries. The most common examples are prescriptive access control information and inherited schema definition. Implementations may also define other policy attributes, or sub-entries, that apply to a whole subtree. For a naming context to be faithfully reproduced, this generational information must also be replicated. In all cases Merrells, Reed, Srinivasan [Page 17] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 the policy information is transmitted as if it were an element of the Replica root entry. Policy information is always replicated in the same manner as any other entries, attributes, and attribute values. 7.1 Access Control The Access Control Models supported by a server are identified by the 'accessControlScheme' multi-valued attribute of the Root DSE entry. Each model is assigned an OID so that Consumers and Suppliers can determine if their access control policy will be faithfully imposed when replicated. An access control policy must be consistently applied by all servers holding replicas of the same Naming Context. Therefore, the Access Control Policy attribute is to be an operational attribute of the Naming Context Auxiliary Class. Thus, any consumer of the directory, and any server which would replicate a Naming Context, will know that an Access Control Policy is defined for the Naming Context, and by reference to the OID value of this attribute, know what policy mechanism to invoke to enforce that policy. Administrators are strongly cautioned against placing replicas of naming contexts on servers that cannot enforce the policy required by the Access Control Policy OID. Servers should refuse to accept replicas with policies they are unable to properly interpret. 7.2 Schema Knowledge Schema subentries should be subordinate to the naming contexts to which they apply. Given our model, a single server may hold replicas of several naming contexts. It is therefore essential that schema should not be considered to be a server-wide policy, but rather to be scoped by the namespace to which it applies. Schema modifications replicate in the same manner as other directory data. Given the strict ordering of replication events, schema modifications will naturally be replicated prior to entry creations which use them, and subsequent to data deletions which eliminate references to schema elements to be deleted. servers may not replicate information about entries which are not defined in the schema. Servers SHOULD NOT replicate modifications to existing schema definitions for which there are existing entries and/or attributes which rely on the schema element. Merrells, Reed, Srinivasan [Page 18] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 Should a schema change cause an entry to be in violation of the new schema, it is recommended that the server preserve the entry for administrative repair. The server could add a known object class to make the entry valid and to mark the entry for maintenance. 8. Update Transfer Protocol This section describes the process by which a Replication Session is established, how updates are transferred, and how a session is terminated. Subject to Replication Agreements, either the supplier or the consumer server can initiate the replication session. This document only defines a transfer protocol for the supplier to push changes to the consumer. Other protocols could be defined to transfer changes, including those which pull changes from the supplier to the consumer, but those are left for future work. 8.1 Session Initiation The Initiator starts the Replication Session by opening an LDAP connection to its Responder. The Initiator binds using the authentication credentials provided in the Replication Agreement. The extended LDAP operation Start Replication is then sent by the Initiator to the Responder. This operation identifies which role each server will perform, and what type of replication is to be performed. One server is to be the Consumer, the other the Supplier, and the replication may be either Full or Incremental. If the Responder does not support the requested type of replication then an error is returned. 8.1.1 Authentication The initiation of a Replication Session is to be restricted to only permitted clients. The identity and credentials of a connected server are determined via the bind operation. Access control on the Replication Agreement determines if the Replication Session may proceed. Otherwise, the insufficientAccessRights error is returned. 8.1.2 Consumer Initiated The Consumer binds to the Supplier using the authentication credentials provided in the Replication Agreement. The Consumer sends the Start Replication extended request to begin the Replication Merrells, Reed, Srinivasan [Page 19] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 Session. The Supplier returns a Start Replication extended response containing a response code. The Consumer then disconnects from the Supplier. If the Supplier has agreed to the replication session initiation, it binds to the Consumer and behaves just as if the Supplier initiated the replication. 8.1.3 Supplier Initiated The Supplier binds to the Consumer using the authentication credentials provided in the Replication Agreement. The Supplier sends the Start Replication Request extended request to begin the Replication Session. The Consumer returns a Start Replication extended response containing a response code, and optionally its Update Vector. If the Consumer has agreed to the Replication Session initiation, then the transfer protocol begins. The Supplier uses the Consumer's Update Vector to determine the sequence of changes that should be sent to the Consumer. 8.1.4 Start Replication Request A client may request this operation by transmitting an LDAP PDU containing an LDAP ExtendedRequest, defined as follows. [LDAPv3] ExtendedRequest ::= [APPLICATION 23] SEQUENCE { requestName [0] LDAPOID, requestValue [1] OCTET STRING } The requestName field must be set to the string "2.16.840.1.113730.3.5.3". The requestValue field will contain as a value the DER-encoding of the following ASN.1 data type: SEQUENCE { namingContextDN LDAPDN, replicaID INTEGER (1..2^^16-1), protocolOID LDAPOID } The parameters of the Start Replication Request are: - The Distinguished Name of the entry at the root of the Naming Context. - The Replica Identifier of the Initiator. Merrells, Reed, Srinivasan [Page 20] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 - The OID identifying the Update Transfer Protocol to be used. From the DN and Replica ID the Responder can determine which Replication Agreement is being acted on. The Protocol OID identifies the Update Transfer Protocol that the Initiator wishes to use, this indicates whether the it is to be a Full or Incremental update. 8.1.5 Start Replication Response If a server implements this extension, then when the request is made it will return an LDAP PDU containing an ExtendedResponse, defined as follows. [LDAPv3] ExtendedResponse ::= [APPLICATION 24] SEQUENCE { COMPONENTS OF LDAPResult, responseName [10] LDAPOID OPTIONAL, responseValue [11] OCTET STRING OPTIONAL } The responseName field must be set to the string "2.16.840.1.113730.3.5.4". The responseValue field, when present, will contain as a value the DER-encoding of the following ASN.1 data type: SEQUENCE { startReplicationResult [0] startReplicationStatus, updateVector [1] SET OF OCTET STRING OPTIONAL, } startReplicationStatus ::= ENUMERATED { success (0), -- operation succeeded operationsError (1), -- server internal failure protocolError (2), -- protocol error insufficientAccessRights (50), -- refused to carry out operation busy (51), -- already being updated other (80) } The startReplicationResult field indicates any error condition encountered in the processing of the operation. In Supplier Initiated Replication the Consumer Responder responds with its Update Vector. 8.2 Update Transfer Each Update Transfer Protocol is identified by an OID. A conformant server implementation must support the two update protocols defined here, and may support many others. A server will advertise its Merrells, Reed, Srinivasan [Page 21] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 protocols in the Root DSE multi-valued attribute 'supportedReplicationProtocols'. The two mandatory to implement protocols will be defined by the LDUP Working Group in another Internet Draft. One is to provide a Full Update for initialisation and re-initialisation of a replica, the other is to maintain that replica via an Incremental Update. Each entry to be transferred is passed through the Entry Filter and Fractional Entry Specification. Necessary extended operations will be defined to support efficient transfer of change information from supplier to consumer servers. 8.2.1 Full Update Transfer This Full Update Protocol will provide a bulk transfer of the replica contents for the initial population of new replicas, and the refreshing of existing replicas. Upon receiving a full update request the Consumer must replace any existing information in its replica with that sent from the Supplier. The Consumer need not service any requests for this Naming Context whilst the full update is in progress. The Consumer could return a referral to another replica, possibly the supplier. [REF] 8.2.2 Incremental Update Transfer For efficiency the Incremental Update Protocol transmits only those changes that have been made to the Naming Context since updates were last transmitted, that the Consumer has not already received. In a replication topology with transitive redundant replication agreements, changes may propagate through the replica network via different routes. The Supplier uses the Consumer's Update Vector to determine the sequence of updates that should be sent to the Consumer. As the transmission of updates proceeds the Consumer may return the last CSN received as a form of committed acknowledgement. This provides an implicit restart value for the Supplier, should the connection be interrupted. Each individual change may contain a sequence of entry modifications that must be preserved when transferred. The atomicity of the LDAP operation must be preserved when it is applied to the Consumer Replica. Merrells, Reed, Srinivasan [Page 22] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 Changes must be transmitted in ascending change sequence number. Each change transmitted includes the unique identifier of the subject entry and the CSN of the originating operation. This allows the Consumer to keep track of which changes it has received. The Consumer must not support multiple concurrent replication sessions with many Suppliers for the same Naming Context. A Supplier that attempts to initiate a Replication Session with a Consumer already participating as a Consumer in another Replication Session will receive the busy error code. 8.2.2.1 Conflict Detection and Resolution A consequence of permitting multiple updateable replicas within a replication topology is that conflicting update changes may occur. A Consumer will receive replication changes from its various agreement partners. Those changes must be reconciled with the current replica contents and any previously received changes. In broad outline, received replication changes are compared to the state information associated with the item being operated on. If the change has a more recent CSN, then it is applied to the directory contents. If the replica has replication agreements where it acts as a supplier then the change is retained for forwarding at the appropriate time. If the change has an older CSN it is no longer relevant and is simply discarded. Naming collisions may occur when updates are received by a server for a given named entry whose Unique Identifier is different from that of an already existing entry with the same distinguished name. This may occur because events from various replicas cannot be guaranteed to arrive in sequence, or because of conflicting data changes being entered at two or more different replicas. Consider the following scenario: The entry named "A" has a Unique Identifier of "3", and it exists on each of three replicas, X, Y, and Z. At replica X, entry "A" is deleted, and then another entry "A" is created with the same name, but with the Unique Identifier of "4". If at replica Y a modification to entry "A" is entered before the deletion and creation events from X are received, Y will attempt to replicate the modification to "A" to X. When received, X will note that the Unique Identifier of the entry "A" which is being modified is "3". Because the entry "A" with Unique Identifier "3" is marked as "deleted" on X, server X will simply ignore the modification, since it applies to a deleted object, and not Merrells, Reed, Srinivasan [Page 23] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 to the entry currently defined with name "A", whose Unique Identifier is "4". Thus, the confusion over which entry was modified is resolved. This briefly describes the types of change collisions that can occur. The LDUP Working Group will publish an Internet Draft fully defining the Conflict Detection and Resolution mechanism. 8.3 End Replication Session A Replication Session is terminated by the Supplier by sending an End Replication LDAP extended request, see section 8.3.3. The purpose of the request and response operations is to carry the Update Vector from the Supplier to the Consumer in the Full Update case, and to convey the Update Vector from the Consumer to the Supplier in the Incremental Update case. 8.3.1 Full Update End Replication Session After a Full Update transfer the Supplier sends the Update Vector that reflects the update state of the full replica information sent. The Consumer records this as its Update Vector. The Supplier could be accepting updates whilst the update is in progress. Once the Full Update has completed, an Incremental Update should be performed to transfer these changes. 8.3.2 Incremental Update End Replication Session After an Incremental Update transfer has completed the Supplier must send its Update Vector to the Consumer. If the Supplier sent none of its own updates to the Consumer, then its CSN within its Update Vector should be updated with the earliest possible CSN that it could generate, to allow for deletion state information to be purged in a timely manner. The Consumer records the received Update Vector in the replica entry it holds for the Supplier Replica. The Consumer then returns its resultant Update Vector to the Supplier so that it too can update its replica entry for the Consumer Replica. The Consumer's Update Vector CSN values will be at least as great as the Supplier's Update Vector. Merrells, Reed, Srinivasan [Page 24] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 8.3.3 End Replication Request A client may request this operation by transmitting an LDAP PDU containing an LDAP ExtendedRequest, defined as follows. [LDAPv3] ExtendedRequest ::= [APPLICATION 23] SEQUENCE { requestName [0] LDAPOID, requestValue [1] OCTET STRING } The requestName field must be set to the string "2.16.840.1.113730.3.5.5". The requestValue field will contain as a value the DER-encoding of the following ASN.1 data type: SEQUENCE { updateVector SET OF OCTET STRING } When the update has completed the Supplier sends this extended request to inform the Consumer that all updates have been sent, and to advise the Consumer of its own Update Vector. 8.3.4 End Replication Response If a server implements this extension, then when the request is made it will return an LDAP PDU containing an ExtendedResponse, defined as follows. [LDAPv3] ExtendedResponse ::= [APPLICATION 24] SEQUENCE { COMPONENTS OF LDAPResult, responseName [10] LDAPOID OPTIONAL, responseValue [11] OCTET STRING OPTIONAL } The responseName field must be set to the string "2.16.840.1.113730.3.5.6". The responseValue field, when present, will contain as a value the DER-encoding of the following ASN.1 data type: SEQUENCE { endReplicationResult [0] endReplicationStatus, updateVector [1] SET OF OCTET STRING OPTIONAL, } startReplicationStatus ::= ENUMERATED { success (0), -- operation succeeded Merrells, Reed, Srinivasan [Page 25] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 operationsError (1), -- server internal failure protocolError (2), -- protocol error other (80) } The endReplicationResult field indicates any error condition encountered in the processing of the operation. The Consumer returns its Update Vector to the Supplier. 8.4 Integrity & Confidentiality Data integrity (i.e. protection from unintended changes) and confidentiality (i.e. protection from unintended disclosure to eavesdroppers) SHOULD be provided by appropriate selection of underlying transports, for instance TLS, or IPSEC. Replication MUST be supported across TLS LDAP connections. Servers MAY be configured to refuse replication connections over unprotected TCP connections. 9. Replication Configuration and Management Replication management entries, such as replica or replication agreement entries, can be altered on any updateable replica. These entries are implicitly included in the directory entries governed by any agreement associated with this naming context. As a result, all servers with a replica of a naming context will have access to information about all other replicas and associated agreements. The deployment and maintenance of a replicated directory network involves the creation and management of all the replicas of a naming context and replication agreements among these replicas. This section outlines, through an example, the administrative actions necessary to create a new replica and establish replication agreements. Typically, administrative tools will guide the administrator and facilitate these actions. The objective of this example is to illustrate the architectural relationship among various replication related operational information. A copy of an agreement should exist on both the supplier and consumer side for the replication update transfer protocol to be able to start. For this purpose, the root of the naming context, replica objects and the replication agreement objects are created first on one of the servers. A copy of these objects are then manually created on the second server associated with the agreement. Merrells, Reed, Srinivasan [Page 26] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 The scenario below starts with a server (named DSA1) that holds an updateable replica of a naming context NC1. Procedures to establish an updateable replica of the naming context on a second server (DSA2) are outlined. On DSA1: 1) Add the context prefix for NC1 to the Root DSE attribute 'replicaRoot'. If it does not already exist. 2) Alter the 'ObjectClass' attribute of the root entry of NC1 to include the "namingContext" auxiliary class. 3) Create a replica object, NC1R1, (as a child of the root of NC1) to represent the replica on DSA1. The attributes include replica type (updateable, read-only etc.) and DSA1 access point information. 4) Create a copy of the replica object NC1R2 (after it is created on DSA2) 5) Create a replication agreement, NC1R1-R2 to represent update transfer from NC1R1 to NC1R2. This object is a child of NC1R1. On DSA2: 1) Add NC1's context prefix to the Root DSE attribute 'replicaRoot'. 2) Create a copy of the root entry of NC1 as a copy of the one in DSA1 (including the namingContext auxiliary class) 3) Create a copy of the replica object NC1R1 4) Create a the second replica object, NC1R2 (as a sibling of NC1R1) to represent the replica on DSA2. 5) Create a copy the replication agreement, NC1R1-R2 6) Create a replication agreement, NC1R2-R1, to represent update transfer from NC1R2 to NC1R1. This object is a sibling of NC1R1- R2. After these actions update transfer to satisfy either of the two agreements can commence. If data already existed in one of the replicas, the update transfer protocol should perform a complete update of the data associated with the agreement before normal replication begins. Merrells, Reed, Srinivasan [Page 27] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 10. Time The server assigns CSN for every LDAP update operation it receives. Since the CSN is principally based on time, the CSN is susceptible to the Replica clocks drifting in relation to each other (either forwards or backwards). The server must never assign a CSN older than or equal to the last CSN it assigned. 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 error code serverClocksOutOfSync (72) should be returned. 11. Security Considerations The preceding architecture discussion covers the server authentication, session confidentiality, and session integrity in sections 8.1.1, 17.7, and 8.4 The internet draft "Authentication Methods" for LDAP, provides a detailed LDAP security discussion. Its introductory passage is paraphrased below. [AUTH] A Replication Session can be protected with the following security mechanisms. 1) Authentication by means of the SASL mechanism set, possibly backed by the TLS credentials exchange mechanism, 2) Authorization by means of access control based on the Initiators authenticated identity, 3) Data integrity protection by means of the TLS protocol or data- integrity SASL mechanisms, 4) Protection against snooping by means of the TLS protocol or data- encrypting SASL mechanisms, 12. Acknowledgements This document is a product of the LDUP Working Group of the IETF. The contributions of its members is greatly appreciated. Merrells, Reed, Srinivasan [Page 28] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 13. References [AUTH] - M. Wahl, H. Alvestrand, J. Hodges, RL "Bob" Morgan, "Authentication Methods for LDAP", Internet Draft, draft-ietf-ldapext- authmeth-02.txt, July 1998. [BCP-11] - R. Hovey, S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. [LDAPv3] - M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access Protocol (v3)", RFC 2251, December1997. [LDUP Requirements] - R. Weiser, E. Stokes “LDAP Replication Requirements”, Internet Draft, draft-weiser-replica-req-02.txt, April 1998. [LDUP Info.] - E. Reed, "LDUP Replication Information Model", Internet Draft, draft-reed-ldup-infomod-00-1.txt, August 1998. [NTP] - D. L. Mills, "Network Time Protocol (Version 3)", RFC 1305, March, 1992. [REF] - T. Howes, Mark Wahl, "Referrals and Knowledge References in LDAP Directories", Internet draft, draft-ietf-ldapext-referral-00.txt, March 1998. [RFC2119] - S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119. [RFC2252] - M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997. [SNTP] - D. L. Mills, "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030, University of Delaware, October 1996. [TLS] - J. Hodges, R. L. "Bob" Morgan, M. Wahl, "Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security", Internet draft, draft-ietf-ldapext-ldapv3-tls-01.txt, July 1998. [UUID] - P. Leach, R. Salz, "UUIDs and GUIDs", Internet draft, draft- leach-uuids-guids-01.txt, February 1998. [X501] - ITU-T Recommendation X.501 (1993), ) | ISO/IEC 9594-2:1993, Information Technology - Open Systems Interconnection - The Directory: Models Merrells, Reed, Srinivasan [Page 29] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 [X680] - ITU-T Recommendation X.680 (1994) | ISO/IEC 8824-1:1995, Information technology - Abstract Syntax Notation One (ASN.1): Specification of Basic Notation" [X525] ITU-T Recommendation X.525 (1997) | ISO/IEC 9594-9:1997, Information Technology - Open Systems Interconnection - The Directory: Replication 14. Intellectual Property Notice The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. [BCP-11] Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 15. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for Merrells, Reed, Srinivasan [Page 30] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 16. Authors' Address John Merrells Netscape Communications, Inc. 501 East Middlefield Road Mountain View CA 94043 E-mail: merrells@netscape.com Phone: +1 650-937-5739 Edwards E. Reed Novell, Inc. 122 E 1700 S Provo, UT 84606 E-mail: ed_reed@novell.com Phone: +1 801-861-3320 Fax: +1 801-861-2220 Uppili Srinivasan Oracle, Inc. Redwood Shores E-mail: usriniva@us.oracle.com Phone: +1 650 506 3039 LDUP Engineering Mailing List: ldup-repl@external.cisco.com Merrells, Reed, Srinivasan [Page 31] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 17. Appendix A - Open Issues 17.1 Replication Session Initiation Insisting that an agreement is always consumer initiated or always supplier initiated is rather inflexible. There are times when a read- only replica will want to initiate an immediate total refresh on an agreement that is ordinarily supplier initiated. With the above restriction a read-only replica will just have to wait until a supplier contacts it. It might be preferable that the identity of the initiator be associated with the schedule components, rather than with the whole replication agrement. 17.2 Lost and Found Container The replication architecture proposal submitted by Steven Legg of Teltra includes the concept of every entry being assigned a lost and found superior. If the entry becomes orphaned from its parent, due to some naming collision, then the lost and found container adopts that entry. This well known place would allow administrators and their tools to find and repair abandoned entries. 17.3 Write Conflicts Servers could be administratively configured to ignore updates with ridiculous times, and may choose their own definitions for what times are considered ridiculous. Servers that do so must declare their definition of ridiculous in the Root DSE or the Naming Context entry of the Replica. 17.4 Management and Configuration Topics that need coverage. - Creation, Destruction, and Modification of Naming Contexts, Replicas, and Replication Agreements. - Promotion and Demotion of Replicas from Read-Only to Updateable to Primary. - Patching up of partitioned replication networks. Merrells, Reed, Srinivasan [Page 32] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 - Discuss redundant replication agreements. - Triggering a Full Update for a Replication Agreement. 17.5 Sparse, Fractional, and Partial Replicas The scope and expressiveness of the Entry Filter and Fractional Attribute Specification need to be defined. One of the replication requirements is that not all replicas hold all the entries or all their attributes. There are some consequences. - Both Replica and Replication Agreements could specify the Partial- ness of a Replica. - What should the server behaviour be when an LDAP update operations is applied to Partial Replica that does not hold the data to be modified. - How is schema enforced on a Fractional Replica. 17.6 Update Transfer: Errors, Recovery, Diagnostics and Repair How should the protocol react to connection loss. Should the Replication Agreement protocol parameters define the acknowledgement frequency. Should keep-alive and progress feedback be provided for long operations. For instance replica preparation during Full Update for reinitialisation. 17.7 Update Access Control The Supplier must be subject to the access control policy enforced by the Consumer. Since the access control policy information is stored and replicated as directory content, the access control imposed on the Supplier by the Consumer must be stored in the Consumer's Replication Agreement. Merrells, Reed, Srinivasan [Page 33] Expires 5 February 1999 --------------2B6403165D3712A1363BA1B0-- From owner-ietf-ldup Sun Aug 9 00:32:02 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA27835 for ietf-ldup-bks; Sun, 9 Aug 1998 00:32:02 -0700 (PDT) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA27831 for ; Sun, 9 Aug 1998 00:31:55 -0700 (PDT) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id ; Sun, 9 Aug 1998 17:32:09 +1000 Message-ID: From: Alan Lloyd To: "'LDUP-REPL '" , "'LDUP '" , "'John Merrells '" Subject: RE: LDAP Replication Architecure Draft Date: Sun, 9 Aug 1998 17:32:08 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ietf-ldup@imc.org Precedence: bulk John, all - thanks for that. There seems to be a lot of work in the document and it is well presented. 2 points. 1. It is good that this is getting more and more like X.500 replication and re-affirming the DIT admin model. Which by the way has to be modelled in a distributed way so that replicated or master entries can be selected. In x.500 entries can be selected as a copy/replica through the use of Dont Use Copy in DAP and this is carried in DSP. This means that entries in the DIT need a notion of master or copy indicators. This retrieval selection in X.500 is actioned via DSP as replicas and distributed portions of the tree can be interconnected. ie Distributed operations in X.500 permit the notion of accessing a master or copy entry in a collective cloud of distributed entries. LDAP and LDAP servers do not support distribution so they removed this feature .. so LDAP is still quite deficient in this area. 2. The section- 3.3 Document Non-Objectives. The section below should be tightened up as they are fundamental to a replication design. "".............. This document does not address the following issues, as they are considered beyond the scope of the Working Group. The following list describes the features we are not addressing in this document. a) How LDAP becomes a distributed directory. There are many issues beyond replication that should be considered. Such as, support for external references, algorithms for computing referrals from the distributed directory knowledge, etc. b) Specifying management protocols to create naming contexts or new replicas. LDAP may be sufficient for this. The document describes how new replicas and naming contexts are represented, in the directory, as entries, attributes, and attribute values. c) How transactions will be replicated. However, the architecture should not knowingly prevent or impede them, given the Working Group's incomplete understanding of the issues at this time. Alan - this one must be defined - otherwise LDUP is not a protocol. d) The mapping or merging of disparate Schema definitions. e) Support of overlapping replicated regions. f) The case where separate attributes of an entry may be mastered by different LDAP servers. This might be termed a 'Split Primary'. Replica roles are defined in section 5.1. ".... In closing I think that those taking limited LDAP servers into this space will find that implementing a distributed DIT and its admin model (if you have not done that before) will need a bit of time and cash.. Also you will find that the nearer this LDAP model gets to X.500, the more people will take X.500 because it alrady has these features - and more ie. full distribution and a defined replication protocol. Anyway - good work and the issue raised above and those re selection of master/copy entry should be dealt with. regards alan ---------- From: John Merrells To: LDUP-REPL; LDUP Sent: 8/9/98 8:52:22 AM Subject: LDAP Replication Architecure Draft Fellow LDUPers, Please find attached the first draft of the LDAP Replication Architecture draft. I posted it to internet-drafts on Friday, but managed to mis-address the message, then a construction crew brought down a power line wiping out most of the campus. So, I didn't realise the message bounced until today. So, it doesn't look like it'll be an official I-D by the next IETF meeting... But, I don't think that's any real impediment to our work. Please post your comments to ietf-ldup@imc.org. John, Ed & Uppili -- John Merrells, Software Engineer Netscape Communications, Directory Server http://people.netscape.com/merrells From owner-ietf-ldup Sun Aug 9 16:03:12 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA17016 for ietf-ldup-bks; Sun, 9 Aug 1998 16:03:12 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA17012 for ; Sun, 9 Aug 1998 16:03:11 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id QAA22577 for ; Sun, 9 Aug 1998 16:05:24 -0700 (PDT) Received: from netscape.com ([208.12.63.182]) by dredd.mcom.com (Netscape Messaging Server 3.52) with ESMTP id AAA2597; Sun, 9 Aug 1998 16:05:24 -0700 Message-ID: <35CE2B2F.EC2D4D89@netscape.com> Date: Sun, 09 Aug 1998 16:05:19 -0700 From: John Merrells Organization: Netscape Communications X-Mailer: Mozilla 4.06 [en]C-NSCP (WinNT; U) MIME-Version: 1.0 To: Alan Lloyd CC: "'LDUP '" Subject: Re: Architecure Draft [Transactions] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk Alan Lloyd wrote: > c) How transactions will be replicated. However, the architecture > should not knowingly prevent or impede them, given the Working > Group's incomplete understanding of the issues at this time. > > Alan - this one must be defined - otherwise LDUP is not a protocol. I agree that once LDAP transactions have been defined they must be faithfully replicated by our replication protocol. However, one of our objectives is to avoid tying ourselves to any other work items. So, we're attempting to keep transactions in mind, rather than demanding that they be defined before we more forward. John From owner-ietf-ldup Sun Aug 9 16:07:08 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA17025 for ietf-ldup-bks; Sun, 9 Aug 1998 16:07:08 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA17021 for ; Sun, 9 Aug 1998 16:07:07 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id QAA22626 for ; Sun, 9 Aug 1998 16:09:21 -0700 (PDT) Received: from netscape.com ([208.12.63.182]) by dredd.mcom.com (Netscape Messaging Server 3.52) with ESMTP id AAA26BD; Sun, 9 Aug 1998 16:09:21 -0700 Message-ID: <35CE2C1B.FB72EE28@netscape.com> Date: Sun, 09 Aug 1998 16:09:15 -0700 From: John Merrells Organization: Netscape Communications X-Mailer: Mozilla 4.06 [en]C-NSCP (WinNT; U) MIME-Version: 1.0 To: Alan Lloyd CC: "'LDUP '" Subject: Re: Architecure Draft [Dont Use Copy] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk Alan Lloyd wrote: > In x.500 entries can be selected as a copy/replica through the use of > Dont Use Copy in DAP and this is carried in DSP. This means that entries > in the DIT need a notion of master or copy indicators. Our current thinking is that this bahaviour is up to clients to implement. Information about the LDAP servers hosting the Naming Context is published in sub-entries below the Naming Context. A client that demands high consistency would discover the access point for the Primary Replica and apply all its operations there. John From owner-ietf-ldup Mon Aug 10 14:31:27 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA12557 for ietf-ldup-bks; Mon, 10 Aug 1998 14:31:27 -0700 (PDT) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA12553 for ; Mon, 10 Aug 1998 14:31:23 -0700 (PDT) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id ; Tue, 11 Aug 1998 07:31:42 +1000 Message-ID: From: Alan Lloyd To: Alan Lloyd , "'John Merrells '" Cc: "''LDUP ' '" Subject: RE: Architecure Draft [Dont Use Copy] Date: Tue, 11 Aug 1998 07:31:40 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ietf-ldup@imc.org Precedence: bulk John - thanks for that - but this response has major problems. Say we awant autrhenticated access to 8 servers and by definition with LDAP servers we have to replicate everything to every where that is there is about 50+ replication agreements ie. 7*8.. etc you can work this out. This means that a client must know which part of the tree lives in what server that is the master - so in this LDAP client we do..... I want the master entry - and from scanning all the LDAP severs I know about (because of hand configuration, I then scan them for their master context and then get the entry i desire... Its this whole hand-cranked multi-ldap actions that make it so bad its unworkable. LDAP severs and what they do, will get worse and worse - with the more you add. regards alan ---------- From: John Merrells To: Alan Lloyd Cc: 'LDUP ' Sent: 8/10/98 9:09:15 AM Subject: Re: Architecure Draft [Dont Use Copy] Alan Lloyd wrote: > In x.500 entries can be selected as a copy/replica through the use of > Dont Use Copy in DAP and this is carried in DSP. This means that entries > in the DIT need a notion of master or copy indicators. Our current thinking is that this bahaviour is up to clients to implement. Information about the LDAP servers hosting the Naming Context is published in sub-entries below the Naming Context. A client that demands high consistency would discover the access point for the Primary Replica and apply all its operations there. John From owner-ietf-ldup Mon Aug 10 14:55:58 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA12697 for ietf-ldup-bks; Mon, 10 Aug 1998 14:55:58 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA12693 for ; Mon, 10 Aug 1998 14:55:57 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id OAA20555 for ; Mon, 10 Aug 1998 14:58:15 -0700 (PDT) Received: from netscape.com ([208.12.63.182]) by dredd.mcom.com (Netscape Messaging Server 3.52) with ESMTP id AAA5110; Mon, 10 Aug 1998 14:58:13 -0700 Message-ID: <35CF6CEE.38333A83@netscape.com> Date: Mon, 10 Aug 1998 14:58:06 -0700 From: John Merrells Organization: Netscape Communications X-Mailer: Mozilla 4.06 [en]C-NSCP (WinNT; U) MIME-Version: 1.0 To: Alan Lloyd CC: ietf-ldup@imc.org Subject: Re: Architecure Draft [Dont Use Copy] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk Alan Lloyd wrote: > John - thanks for that - but this response has major problems. Say we > awant autrhenticated access to 8 servers and by definition with LDAP > servers we have to replicate everything to every where that is there is > about 50+ replication agreements ie. 7*8.. etc you can work this out. > This means that a client must know which part of the tree lives in what > server that is the master - so in this LDAP client we do..... > I want the master entry - and from scanning all the LDAP severs I know > about (because of hand configuration, I then scan them for their master > context and then get the entry i desire... > > Its this whole hand-cranked multi-ldap actions that make it so bad its > unworkable. > > LDAP severs and what they do, will get worse and worse - with the more > you add. We're limiting ourselves here to just talking about the replication of a single Naming Context. We're specifically not addressing how servers host different parts of the DIT spread amongst many servers. It so happens that our replication management entries provide a description of where and what information is located where. A client could use this information to seek out the Primary Replica.... Or, another draft could define a control to encourage the server to do this work on its behalf. It could either generate a referral to the Primary, or perform the operation on the clients behalf... but that would probably be unworkable ;-) John From owner-ietf-ldup Mon Aug 10 17:48:58 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA13555 for ietf-ldup-bks; Mon, 10 Aug 1998 17:48:58 -0700 (PDT) Received: from ORM-BBWEB.orem.novell.com (orm-bbweb.orem.novell.com [151.155.134.147]) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA13551 for ; Mon, 10 Aug 1998 17:48:56 -0700 (PDT) Received: from GATEWAYS-Message_Server by ORM-BBWEB.orem.novell.com with Novell_GroupWise; Mon, 10 Aug 1998 18:50:53 -0600 Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Mon, 10 Aug 1998 18:31:38 -0600 From: "Ed Reed" To: , Cc: Subject: Re: Architecure Draft [Dont Use Copy] 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 mail.proper.com id RAA13552 Sender: owner-ietf-ldup@imc.org Precedence: bulk The question you raise, Alan, drives directly to the question of what must be done to LDAP to be able to use it as a distributed directory service. Not much discussion, here or elsewhere, has been given to how the community of LDAP servers on the Internet provide for a global namespace, connected conviently via DNS, for clients to peruse. It's that last bit - that clients peruse - that is the kicker. Novell chose, in our directory, to chain exactly one operation at the DSA for clients - the Resolve Name operation. The fuction is easily reproduceable in an LDAP extended operation, and that's probably where it belongs. While clients MAY do their own name resolution processing, all our application-oriented clients "let the server do the walking", returning a referral to one or more servers which match the criteria set out by the client as necessary - must we talk to the "primary" replica? Is an updateable replica required, or will an read-only do? Does the client require a certain version of the DSA software to be supported because of some special features it wants to support? And, of course, what's the DN of the entry the object wants to access, or the base name of the search it wants to perform? Obviously, figuring that all out taking into account sparse and fractional replicas will be interesting, but we're really only talking about how a client gets directed to the server that holds the information that will best suit the client's needs. Servers, who already have open, authenticated connections among themselves for replication purposes, and who already have ready, local, access to all the replication agreement information about the name contexts they hold, about the name contexts which are subordinate to the name contexts they hold, and about the name contexts superior to the root-most name contexts they hold...well, the servers have much of the information needed to compute a quick referral to the client, and so we let them. In fact, the Resolve Name operation even returns a handle to the object named in its request, so if the client is going to read or modify the entry, no further searches need to be performed. Similarly, if the entry is missing, or not available due to access control policy, an error is returned so the client won't waste any more of its time. But - the specification of that operation, or of the logic needed to perform the work (essentially documented in X.518, section 18.6, pretty literally - a flow chart in Figure 8/X.518 called "Find Naming Context" of the original 1988 spec, in fact) is outside of the replication specification, and so we leave it, for now, to the reader, and to the author who would like to flesh out the details. Ed ------------------- Ed Reed, Technologist Novell, Inc. +1 801 861 3320 From owner-ietf-ldup Wed Aug 12 08:11:37 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA05679 for ietf-ldup-bks; Wed, 12 Aug 1998 08:11:37 -0700 (PDT) Received: from alpha.dante.org.uk (dns.dante.org.uk [193.63.211.19]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA05674 for ; Wed, 12 Aug 1998 08:11:35 -0700 (PDT) Received: from nt10 (actually host nt9.dante.org.uk) by alpha.dante.org.uk with SMTP (MMTA) local; Wed, 12 Aug 1998 16:13:39 +0100 X-Sender: peter@alpha.dante.org.uk X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Wed, 12 Aug 1998 16:13:54 +0100 To: Ed Reed From: Peter Gietz Subject: Information Model Draft Cc: ietf-ldup@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <"alpha.dante.:216360:980812151339"@dante.org.uk> Sender: owner-ietf-ldup@imc.org Precedence: bulk Hi Ed, in the Replication Architecture Draft, I found a reference to yet another LDUP draft authored by you: "LDUP Replication Information Model" of August 1998. Is this text available yet? I couldn't find it at the IETF server. If possible I would like to have a look at it before the Chicago Meeting. Cheers, Peter ________________________________________________________________ * * Karl-Peter Gietz - Applications Engineer * * * Francis House Peter.Gietz@dante.org.uk * 112 Hills Road Tel +44 1223 302992 * Cambridge CB2 1PQ Fax +44 1223 303005 D A N T E United Kingdom WWW http://www.dante.net ________________________________________________________________ From owner-ietf-ldup Wed Aug 12 09:11:21 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA06104 for ietf-ldup-bks; Wed, 12 Aug 1998 09:11:21 -0700 (PDT) Received: from ORM-BBWEB.orem.novell.com (orm-bbweb.orem.novell.com [151.155.134.147]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA06100 for ; Wed, 12 Aug 1998 09:11:20 -0700 (PDT) Received: from GATEWAYS-Message_Server by ORM-BBWEB.orem.novell.com with Novell_GroupWise; Wed, 12 Aug 1998 10:13:34 -0600 Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Wed, 12 Aug 1998 09:48:13 -0600 From: "Ed Reed" To: Cc: Subject: Re: Information Model Draft 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 mail.proper.com id JAA06101 Sender: owner-ietf-ldup@imc.org Precedence: bulk Work to get the architecture draft kept me from getting adequate review time of the information model. My goal is to distribute it to the LDUP mailing list prior to Chicago - next week some time. Ed ------------------- Ed Reed, Technologist Novell, Inc. +1 801 861 3320 >>> Peter Gietz 08/12/1998 09:13:54 >>> Hi Ed, in the Replication Architecture Draft, I found a reference to yet another LDUP draft authored by you: "LDUP Replication Information Model" of August 1998. Is this text available yet? I couldn't find it at the IETF server. If possible I would like to have a look at it before the Chicago Meeting. Cheers, Peter ________________________________________________________________ * * Karl-Peter Gietz - Applications Engineer * * * Francis House Peter.Gietz@dante.org.uk * 112 Hills Road Tel +44 1223 302992 * Cambridge CB2 1PQ Fax +44 1223 303005 D A N T E United Kingdom WWW http://www.dante.net ________________________________________________________________ From owner-ietf-ldup Thu Aug 20 18:13:51 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA00317 for ietf-ldup-bks; Thu, 20 Aug 1998 18:13:51 -0700 (PDT) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA00313 for ; Thu, 20 Aug 1998 18:13:47 -0700 (PDT) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id ; Fri, 21 Aug 1998 11:14:15 +1000 Message-ID: From: Alan Lloyd To: "'John Merrells'" , Alan Lloyd Cc: "'LDUP '" Subject: RE: Architecure Draft [Dont Use Copy] Date: Fri, 21 Aug 1998 11:14:12 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ietf-ldup@imc.org Precedence: bulk John - this means more human configuration and more code for the client software... than X.500 systems regards alan > -----Original Message----- > From: John Merrells [SMTP:merrells@netscape.com] > Sent: Monday, 10 August 1998 9:09 > To: Alan Lloyd > Cc: 'LDUP ' > Subject: Re: Architecure Draft [Dont Use Copy] > > > > Alan Lloyd wrote: > > > In x.500 entries can be selected as a copy/replica through the use > of > > Dont Use Copy in DAP and this is carried in DSP. This means that > entries > > in the DIT need a notion of master or copy indicators. > > Our current thinking is that this bahaviour is up to clients to > implement. > Information about the LDAP servers hosting the Naming Context is > published in sub-entries below the Naming Context. A client that > demands high consistency would discover the access point for the > Primary Replica and apply all its operations there. > > John From owner-ietf-ldup Thu Aug 20 18:22:40 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA00386 for ietf-ldup-bks; Thu, 20 Aug 1998 18:22:40 -0700 (PDT) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA00380 for ; Thu, 20 Aug 1998 18:22:34 -0700 (PDT) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id ; Fri, 21 Aug 1998 11:23:04 +1000 Message-ID: From: Alan Lloyd To: "'John Merrells'" , Alan Lloyd Cc: "'LDUP '" Subject: RE: Architecure Draft [Transactions] Date: Fri, 21 Aug 1998 11:23:02 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ietf-ldup@imc.org Precedence: bulk John - having just returned from a long US/europe trip. and seeing all the LDAP extensions for: Persistent searches, Transactions, triggers, signed operations (which should be signed audit records) and initiating replication processes. I am concerned that if these extensions applied together by a naughty client what would an ldap server do. ie if transcation IDs lock resource, then how does one replicate in, what happens to a ldap server with persistent searches and triggers if one zaps in 200,k entries in replication processes. In addition most of the extensions being added do not work well in a distributed model. ie to put a transaction state, a trigger state and a persistent search state accross a distributed system where you do not know how many servers actually are involved with such a search operation - all hell will break loose.. But I suppose this is really upto the LDAP server (non X.500 types) implementors to sort out. All I can do is wish them good luck. - and the customers that use them. regards alan > -----Original Message----- > From: John Merrells [SMTP:merrells@netscape.com] > Sent: Monday, 10 August 1998 9:05 > To: Alan Lloyd > Cc: 'LDUP ' > Subject: Re: Architecure Draft [Transactions] > > > > Alan Lloyd wrote: > > > c) How transactions will be replicated. However, the architecture > > should not knowingly prevent or impede them, given the Working > > Group's incomplete understanding of the issues at this time. > > > > Alan - this one must be defined - otherwise LDUP is not a protocol. > > I agree that once LDAP transactions have been defined they must > be faithfully replicated by our replication protocol. However, one of > our objectives is to avoid tying ourselves to any other work items. > So, we're attempting to keep transactions in mind, rather than > demanding that they be defined before we more forward. > > John From owner-ietf-ldup Thu Aug 20 18:53:06 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA00584 for ietf-ldup-bks; Thu, 20 Aug 1998 18:53:06 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA00580 for ; Thu, 20 Aug 1998 18:53:05 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id SAA29390 for ; Thu, 20 Aug 1998 18:56:14 -0700 (PDT) Received: from netscape.com ([208.12.63.182]) by dredd.mcom.com (Netscape Messaging Server 3.52) with ESMTP id AAA540F; Thu, 20 Aug 1998 18:56:13 -0700 Message-ID: <35DCD3B7.5B1A1DD8@netscape.com> Date: Thu, 20 Aug 1998 18:56:08 -0700 From: John Merrells Organization: Netscape Communications X-Mailer: Mozilla 4.5b2 [en]C-NSCP (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Alan Lloyd CC: "'LDUP '" Subject: Re: Architecure Draft [Dont Use Copy] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk Alan Lloyd wrote: > John - this means more human configuration and more code for the client > software... than X.500 systems > regards alan As I said before, a draft could be written describing a control to convey 'Don't Use Copy', the server could refer the client or chain the request. This isn't part of the LDUP charter, so should be left to others to define. John From owner-ietf-ldup Fri Aug 21 08:12:35 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA22557 for ietf-ldup-bks; Fri, 21 Aug 1998 08:12:35 -0700 (PDT) Received: from ORM-BBWEB.orem.novell.com (orm-bbweb.orem.novell.com [151.155.134.147]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA22553 for ; Fri, 21 Aug 1998 08:12:34 -0700 (PDT) Received: from GATEWAYS-Message_Server by ORM-BBWEB.orem.novell.com with Novell_GroupWise; Fri, 21 Aug 1998 09:15:46 -0600 Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Fri, 21 Aug 1998 09:15:09 -0600 From: "Ed Reed" To: , , Cc: Subject: Re: RE: Architecure Draft [Transactions] 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 mail.proper.com id IAA22554 Sender: owner-ietf-ldup@imc.org Precedence: bulk Alan - I guess I'm not familiar with the version of DISP which propagates transactions in-tact, or the object-level (or is it attribute-level?) locking primatives which extend DAP to make them safe. Do you have a pointer? We haven't solved or addressed them here, because we're not aware of what the system must do to support them. The requirements document for transactions will no doubt provide us insight. As we said, we've not gone out of our way to obstruct replication of transactions, but neither have we attempted to specify how to do them. There may very well need to be a "different" mechanism to support distribution of transactions through a distributed directory environment, and we have attempted, with the ReplicationMechanismOID on the replicaAgreement object, to leave room for future innovation. Ed ------------------- Ed Reed, Technologist Novell, Inc. +1 801 861 3320 >>> Alan Lloyd 08/20/1998 19:23:02 >>> John - having just returned from a long US/europe trip. and seeing all the LDAP extensions for: Persistent searches, Transactions, triggers, signed operations (which should be signed audit records) and initiating replication processes. I am concerned that if these extensions applied together by a naughty client what would an ldap server do. ie if transcation IDs lock resource, then how does one replicate in, what happens to a ldap server with persistent searches and triggers if one zaps in 200,k entries in replication processes. In addition most of the extensions being added do not work well in a distributed model. ie to put a transaction state, a trigger state and a persistent search state accross a distributed system where you do not know how many servers actually are involved with such a search operation - all hell will break loose.. But I suppose this is really upto the LDAP server (non X.500 types) implementors to sort out. All I can do is wish them good luck. - and the customers that use them. regards alan > -----Original Message----- > From: John Merrells [SMTP:merrells@netscape.com] > Sent: Monday, 10 August 1998 9:05 > To: Alan Lloyd > Cc: 'LDUP ' > Subject: Re: Architecure Draft [Transactions] > > > > Alan Lloyd wrote: > > > c) How transactions will be replicated. However, the architecture > > should not knowingly prevent or impede them, given the Working > > Group's incomplete understanding of the issues at this time. > > > > Alan - this one must be defined - otherwise LDUP is not a protocol. > > I agree that once LDAP transactions have been defined they must > be faithfully replicated by our replication protocol. However, one of > our objectives is to avoid tying ourselves to any other work items. > So, we're attempting to keep transactions in mind, rather than > demanding that they be defined before we more forward. > > John From owner-ietf-ldup Fri Aug 21 08:08:10 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA22529 for ietf-ldup-bks; Fri, 21 Aug 1998 08:08:10 -0700 (PDT) Received: from ORM-BBWEB.orem.novell.com (orm-bbweb.orem.novell.com [151.155.134.147]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA22525 for ; Fri, 21 Aug 1998 08:08:08 -0700 (PDT) Received: from GATEWAYS-Message_Server by ORM-BBWEB.orem.novell.com with Novell_GroupWise; Fri, 21 Aug 1998 09:11:15 -0600 Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Fri, 21 Aug 1998 09:10:34 -0600 From: "Ed Reed" To: , , Cc: Subject: Re: RE: Architecure Draft [Dont Use Copy] 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 mail.proper.com id IAA22526 Sender: owner-ietf-ldup@imc.org Precedence: bulk Alan - you are, of course, correct. A Resolve Name operation which does this is certainly indicated as another possible extended operation for LDAP, which I hope we will get to as we add "full" distributed behavior to LDAP services and clients. Ed ------------------- Ed Reed, Technologist Novell, Inc. +1 801 861 3320 >>> Alan Lloyd 08/20/1998 19:14:12 >>> John - this means more human configuration and more code for the client software... than X.500 systems regards alan > -----Original Message----- > From: John Merrells [SMTP:merrells@netscape.com] > Sent: Monday, 10 August 1998 9:09 > To: Alan Lloyd > Cc: 'LDUP ' > Subject: Re: Architecure Draft [Dont Use Copy] > > > > Alan Lloyd wrote: > > > In x.500 entries can be selected as a copy/replica through the use > of > > Dont Use Copy in DAP and this is carried in DSP. This means that > entries > > in the DIT need a notion of master or copy indicators. > > Our current thinking is that this bahaviour is up to clients to > implement. > Information about the LDAP servers hosting the Naming Context is > published in sub-entries below the Naming Context. A client that > demands high consistency would discover the access point for the > Primary Replica and apply all its operations there. > > John From owner-ietf-ldup Fri Aug 21 09:19:37 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23339 for ietf-ldup-bks; Fri, 21 Aug 1998 09:19:37 -0700 (PDT) Received: from ORM-BBWEB.orem.novell.com (orm-bbweb.orem.novell.com [151.155.134.147]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA23335 for ; Fri, 21 Aug 1998 09:19:35 -0700 (PDT) Received: from GATEWAYS-Message_Server by ORM-BBWEB.orem.novell.com with Novell_GroupWise; Fri, 21 Aug 1998 10:22:48 -0600 Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Fri, 21 Aug 1998 10:22:21 -0600 From: "Sukanta Ganguly" To: , , , Cc: Subject: Re: RE: Architecure Draft [Dont Use Copy] 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 mail.proper.com id JAA23336 Sender: owner-ietf-ldup@imc.org Precedence: bulk Hi, Does that mean the LDAP Server needs to store the information about the copy/replica as some attribute value. First of all why would this be an issue at all. If it pertains to replication then the replication unit decides what needs to be replicated and the source and target of the replication. Why would one need to store information specific to particular attributes breaking down the concept of replication unit per se. I don't see this being a problem even in the transaction operation. Sukanta Ganguly >>> "Ed Reed" 08/21 9:10 AM >>> Alan - you are, of course, correct. A Resolve Name operation which does this is certainly indicated as another possible extended operation for LDAP, which I hope we will get to as we add "full" distributed behavior to LDAP services and clients. Ed ------------------- Ed Reed, Technologist Novell, Inc. +1 801 861 3320 >>> Alan Lloyd 08/20/1998 19:14:12 >>> John - this means more human configuration and more code for the client software... than X.500 systems regards alan > -----Original Message----- > From: John Merrells [SMTP:merrells@netscape.com] > Sent: Monday, 10 August 1998 9:09 > To: Alan Lloyd > Cc: 'LDUP ' > Subject: Re: Architecure Draft [Dont Use Copy] > > > > Alan Lloyd wrote: > > > In x.500 entries can be selected as a copy/replica through the use > of > > Dont Use Copy in DAP and this is carried in DSP. This means that > entries > > in the DIT need a notion of master or copy indicators. > > Our current thinking is that this bahaviour is up to clients to > implement. > Information about the LDAP servers hosting the Naming Context is > published in sub-entries below the Naming Context. A client that > demands high consistency would discover the access point for the > Primary Replica and apply all its operations there. > > John From owner-ietf-ldup Sat Aug 22 08:02:01 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA16491 for ietf-ldup-bks; Sat, 22 Aug 1998 08:02:01 -0700 (PDT) Received: from mailgw2.lmco.com (mailgw2.lmco.com [192.91.147.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA16487 for ; Sat, 22 Aug 1998 08:01:52 -0700 (PDT) Received: from emss03g01.ems.lmco.com (emss03g01.orl.lmco.com [141.240.4.144] (may be forged)) by mailgw2.lmco.com (8.8.8/8.8.8) with ESMTP id LAA07054; Sat, 22 Aug 1998 11:06:07 -0400 (EDT) Received: from emss03m00.ems.lmco.com ([141.240.4.64]) by lmco.com (PMDF V5.1-10 #20544) with ESMTP id <0EY3008G2J92K6@lmco.com>; Sat, 22 Aug 1998 11:05:26 -0400 (EDT) Received: by emss03m00.orl.lmco.com with Internet Mail Service (5.0.1460.8) id ; Sat, 22 Aug 1998 11:03:55 -0400 Content-return: allowed Date: Sat, 22 Aug 1998 11:04:28 -0400 From: "Slone, Skip" Subject: RE: RE: Architecure Draft [Dont Use Copy] To: "'Sukanta Ganguly'" , merrells@netscape.com, ED#032#REED@novell.com, Alan.Lloyd@OpenDirectory.com.au, Lloyd@OpenDirectory.com.au Cc: ietf-ldup@imc.org Message-id: <60875A437C39D211BE860000F807EDC70214B9@emss03m03.orl.lmco.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldup@imc.org Precedence: bulk Pardon the intrusion, but since I was heavily involved in the development of X.500 concepts such as DontUseCopy, I might be able to clear up the confusion by clarifying the intent of the DontUseCopy service control. The semantics are actually quite simple. Specifically... 1) A server holding entries is required to know for each entry it holds whether that entry is the original or a copy. How it represents this internally is a local matter -- what matters is that it KNOW. (It would be perfectly reasonable for the server to store this knowledge on a per-replication-unit basis.) 2) A client is allowed to request access to the original. (This request is on a per-operation basis.) 3) A server processing such a query is obliged to honor that request. Assuming a server holds a copy (not the original) of a certain entry, what this means is the following: a) if it receives a request for that entry and DontUseCopy is NOT set, it is free to return the copy. b) if it receives a request for that entry and DontUseCopy IS set, it must either chain the request or return a referal. In the absence of chaining (e.g., in an LDAP world), this leaves a referal as the ONLY VALID REPONSE to the query. It would be absolutely incorrect for a server to respond, in effect, by saying "I don't care whether you want the original, here's what I know about the entry. Now YOU go figure out whether what I just gave you was the original." In other words, when the original is requested, a server holding a copy simply DOES NOT HOLD the requested information and MUST NOT return a substitute. Note that there's nothing to prevent a client from optimizing its performance by learning where the originals are stored, and the subentry publication could provide a nice optimization mechanism. However, forcing the client to do some out-of-band operation in order to simply access the original provides for highly inconsistent distributed behavior. I hope this helps! -- Skip Slone Lockheed Martin Corporation > -----Original Message----- > From: Sukanta Ganguly [SMTP:SGANGULY@novell.com] > Sent: Friday, August 21, 1998 12:22 PM > To: merrells@netscape.com; ED#032#REED@novell.com; > Alan.Lloyd@OpenDirectory.com.au; Lloyd@OpenDirectory.com.au > Cc: ietf-ldup@imc.org > Subject: Re: RE: Architecure Draft [Dont Use Copy] > > Hi, > Does that mean the LDAP Server needs to store the information about the > copy/replica as some attribute value. First of all why would this be an > issue at all. If it pertains to replication then the replication unit > decides what needs to be replicated and the source and target of the > replication. Why would one need to store information specific to > particular attributes breaking down the concept of replication unit per > se. I don't see this being a problem even in the transaction operation. > > Sukanta Ganguly > > >>> "Ed Reed" 08/21 9:10 AM >>> > Alan - you are, of course, correct. A Resolve Name operation which > does this is certainly indicated as another possible extended operation > for LDAP, which I hope we will get to as we add "full" distributed > behavior to LDAP services and clients. > > Ed > > ------------------- > Ed Reed, Technologist > Novell, Inc. > +1 801 861 3320 > > >>> Alan Lloyd 08/20/1998 19:14:12 >>> > John - this means more human configuration and more code for the client > software... than X.500 systems > regards alan > > > -----Original Message----- > > From: John Merrells [SMTP:merrells@netscape.com] > > Sent: Monday, 10 August 1998 9:09 > > To: Alan Lloyd > > Cc: 'LDUP ' > > Subject: Re: Architecure Draft [Dont Use Copy] > > > > > > > > Alan Lloyd wrote: > > > > > In x.500 entries can be selected as a copy/replica through the use > > of > > > Dont Use Copy in DAP and this is carried in DSP. This means that > > entries > > > in the DIT need a notion of master or copy indicators. > > > > Our current thinking is that this bahaviour is up to clients to > > implement. > > Information about the LDAP servers hosting the Naming Context is > > published in sub-entries below the Naming Context. A client that > > demands high consistency would discover the access point for the > > Primary Replica and apply all its operations there. > > > > John > From owner-ietf-ldup Sun Aug 23 18:33:35 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA09446 for ietf-ldup-bks; Sun, 23 Aug 1998 18:33:35 -0700 (PDT) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA09441 for ; Sun, 23 Aug 1998 18:33:26 -0700 (PDT) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id ; Mon, 24 Aug 1998 11:33:29 +1000 Message-ID: From: Alan Lloyd To: ietf-ldup@imc.org Subject: FW: RE: Architecure Draft [Transactions] Date: Mon, 24 Aug 1998 11:33:28 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ietf-ldup@imc.org Precedence: bulk > -----Original Message----- > From: Alan Lloyd > Sent: Monday, 24 August 1998 11:23 > To: 'Ed Reed' > Subject: RE: RE: Architecure Draft [Transactions] > > Ed. the DISP protocol is implied to be a transaction eg a ROSE based > thing. Therefore a DSA that implements DISP either does it or does not > do it. Nothing in between - just internal operation based magic! > > In reality though it takes some doing. And good DB commit services > help. This is where all other non DB directories take a hit (we think > :-)) > > hope this helps > regards alan > > -----Original Message----- > From: Ed Reed [SMTP:ED#032#REED@novell.com] > Sent: Saturday, 22 August 1998 1:15 > To: Alan.Lloyd@OpenDirectory.com.au > Subject: Re: RE: Architecure Draft [Transactions] > > Alan - I guess I'm not familiar with the version of DISP which > propagates > transactions in-tact, or the object-level (or is it attribute-level?) > locking > primatives which extend DAP to make them safe. Do you have a pointer? > > We haven't solved or addressed them here, because we're not aware > of what the system must do to support them. The requirements document > for transactions will no doubt provide us insight. > > As we said, we've not gone out of our way to obstruct replication of > transactions, but neither have we attempted to specify how to do them. > There may very well need to be a "different" mechanism to support > distribution of transactions through a distributed directory > environment, > and we have attempted, with the ReplicationMechanismOID on the > replicaAgreement object, to leave room for future innovation. > > Ed > > ------------------- > Ed Reed, Technologist > Novell, Inc. > +1 801 861 3320 > > >>> Alan Lloyd 08/20/1998 19:23:02 > >>> > John - having just returned from a long US/europe trip. and seeing all > the LDAP extensions for: > Persistent searches, Transactions, triggers, signed operations (which > should be signed audit records) and initiating replication processes. > I > am concerned that if these extensions applied together by a naughty > client what would an ldap server do. ie if transcation IDs lock > resource, then how does one replicate in, what happens to a ldap > server > with persistent searches and triggers if one zaps in 200,k entries in > replication processes. > > In addition most of the extensions being added do not work well in a > distributed model. ie to put a transaction state, a trigger state and > a > persistent search state accross a distributed system where you do not > know how many servers actually are involved with such a search > operation > - all hell will break loose.. > > But I suppose this is really upto the LDAP server (non X.500 types) > implementors to sort out. All I can do is wish them good luck. - and > the > customers that use them. > regards alan > > > > > -----Original Message----- > > From: John Merrells [SMTP:merrells@netscape.com] > > Sent: Monday, 10 August 1998 9:05 > > To: Alan Lloyd > > Cc: 'LDUP ' > > Subject: Re: Architecure Draft [Transactions] > > > > > > > > Alan Lloyd wrote: > > > > > c) How transactions will be replicated. However, the > architecture > > > should not knowingly prevent or impede them, given the Working > > > Group's incomplete understanding of the issues at this time. > > > > > > Alan - this one must be defined - otherwise LDUP is not a > protocol. > > > > I agree that once LDAP transactions have been defined they must > > be faithfully replicated by our replication protocol. However, one > of > > our objectives is to avoid tying ourselves to any other work items. > > So, we're attempting to keep transactions in mind, rather than > > demanding that they be defined before we more forward. > > > > John From owner-ietf-ldup Sun Aug 23 20:21:29 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA10045 for ietf-ldup-bks; Sun, 23 Aug 1998 20:21:29 -0700 (PDT) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA10041 for ; Sun, 23 Aug 1998 20:21:20 -0700 (PDT) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id ; Mon, 24 Aug 1998 13:21:27 +1000 Message-ID: From: Alan Lloyd To: "'Sukanta Ganguly'" , merrells@netscape.com, ED#032#REED@novell.com Cc: ietf-ldup@imc.org Subject: RE: RE: Architecure Draft [Dont Use Copy] Date: Mon, 24 Aug 1998 13:21:27 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ietf-ldup@imc.org Precedence: bulk One needs to "record the unit of replication" in DSAs. The unit of replication ( a replicated naming context) may reside in a DSA with master entries of other naming contexts and both types of contexts need to be identified. A User may request Master entries only starting from the high parts of the DIT. In addition if the DSA has knowledge of other master contexts that can be accessed via DSP, then a distributed search to those DSAs can be actioned (if such naming contexts are within the scope of the search).. Note: X.500 uses knowledge and DSP to retrieve master entries in a distributed env, if the originating DSA holds a replica and dont use copy is set. Note LDAP does not have DSP and leaves the onus on the client to understand the knowledge/distribution and information management policy of any targeted set of LDAP servers. Note that a LDAP client who wishes to authenticate across a set of master or replicated LDAP servers, must also have their entry replicated and the password manageable. And managing password will cause replication actions to occur. In working with directory systems where the requirement is to have guaranteed access to master information, eg. Call Record Data, Targetting information, Stock exchange info.. the facility of "Dont Use Copy" is deemed essential. Hope this helps regards alan > -----Original Message----- > From: Sukanta Ganguly [SMTP:SGANGULY@novell.com] > Sent: Saturday, 22 August 1998 2:22 > To: merrells@netscape.com; ED#032#REED@novell.com; > Alan.Lloyd@OpenDirectory.com.au; Lloyd@OpenDirectory.com.au > Cc: ietf-ldup@imc.org > Subject: Re: RE: Architecure Draft [Dont Use Copy] > > Hi, > Does that mean the LDAP Server needs to store the information about > the copy/replica as some attribute value. First of all why would this > be an issue at all. If it pertains to replication then the replication > unit decides what needs to be replicated and the source and target of > the replication. Why would one need to store information specific to > particular attributes breaking down the concept of replication unit > per se. I don't see this being a problem even in the transaction > operation. > > Sukanta Ganguly > > >>> "Ed Reed" 08/21 9:10 AM >>> > Alan - you are, of course, correct. A Resolve Name operation which > does this is certainly indicated as another possible extended > operation > for LDAP, which I hope we will get to as we add "full" distributed > behavior to LDAP services and clients. > > Ed > > ------------------- > Ed Reed, Technologist > Novell, Inc. > +1 801 861 3320 > > >>> Alan Lloyd 08/20/1998 19:14:12 > >>> > John - this means more human configuration and more code for the > client > software... than X.500 systems > regards alan > > > -----Original Message----- > > From: John Merrells [SMTP:merrells@netscape.com] > > Sent: Monday, 10 August 1998 9:09 > > To: Alan Lloyd > > Cc: 'LDUP ' > > Subject: Re: Architecure Draft [Dont Use Copy] > > > > > > > > Alan Lloyd wrote: > > > > > In x.500 entries can be selected as a copy/replica through the use > > of > > > Dont Use Copy in DAP and this is carried in DSP. This means that > > entries > > > in the DIT need a notion of master or copy indicators. > > > > Our current thinking is that this bahaviour is up to clients to > > implement. > > Information about the LDAP servers hosting the Naming Context is > > published in sub-entries below the Naming Context. A client that > > demands high consistency would discover the access point for the > > Primary Replica and apply all its operations there. > > > > John > From owner-ietf-ldup Fri Sep 18 17:50:36 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA26848 for ietf-ldup-bks; Fri, 18 Sep 1998 17:50:36 -0700 (PDT) Received: from ntg.cisco.com (ntg.cisco.com [171.71.15.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA26844 for ; Fri, 18 Sep 1998 17:50:35 -0700 (PDT) Received: from jstrassn-pc ([171.69.108.130]) by ntg.cisco.com (8.8.4-Cisco.1/8.6.5) with SMTP id RAA03168; Fri, 18 Sep 1998 17:55:45 -0700 (PDT) Message-Id: <3.0.2.32.19980918175537.00b887a0@ntg.cisco.com> X-Sender: jstrassn@ntg.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Fri, 18 Sep 1998 17:55:37 -0700 To: minutes@ietf.org, ietf-ldup@imc.org From: "John C. Strassner" Subject: LDUP BOF draft minutes Cc: capple@att.com, johns@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@imc.org Precedence: bulk LDUPers, here are the proposed minutes from the Chicago LDUP BOF. Please review and comment to the list if there are any additions, deletions, or changes. ----------------------- snip ------------------------------------ The LDUP BOF was attended by approximately 100 people. After reviewing the BOF agenda, the co-chairs polled the room to determine who had reviewed the proposed LDUP WG charter. No one other than the LDUP Engineering Team members had read the proposed charter. Due to printing problems, neither co-chair actually had charts that would support detailed review of the charter in the meeting. There was a suggestion to shift detailed discussion of the charter to the end of the meeting while such charts were created. With this agenda change, Chris Apple reported on the LDUP Engineering Team's progress since the last BOF: + The LDAP replication requirements draft has been revised twice. + We met face-to-face in May-1998 for a round-robin set of implementor LDAP replication presentations. + We held a follow-up conference call to resolve diverging uses of the same terminology, identify and resolve any remaining issues in the requirements document, and make a decision on whether or not to proceed with multiple LDAP replication proposals. We all agreed that creating one set of LDAP replication specifications is better than proceeding with multiple competing sets. The LDUP Engineering Team is now moving forward with a single Replication Architecture, which will produce (at least) seven major RFCs. The next section of the meeting consisted of three presentations that were overviews of three of these seven documents: 1) Russ Weiser gave a brief overview of the LDAP replication requirements document. 2) John Merrells gave a thorough and well received presentation on the pre-I-D version of an LDAP Replication Architecture document. This document will serve as a foundation for other documents currently being drafted by various members of the LDUP Engineering Team. There were three significant issues identified during this presentation (all of which will require careful attention over the coming months): i) more work is required to define initiator versus consumer ownership of replicated entries and entry attributes ii) sparse and fractional replication is very complicated and must be appropriately constrained so that a tractable solution is possible (the BOF-room concensus was that specifying a read-only constraint for the non-original replicas is a good start; more discussion will occur on the list) iii) time can be our worst enemy when it comes to conflict detection and resolution (there was some discussion about how this is related to how you handle the issue of sequence numbers for LDAP transactions that are to be applied against replicas; more discussion is to occur on the list about sequence numbers and time) 3) Ed Reed gave a brief overview of the LDAP Information Model document. The document is currently under engineering team review. It will contain specifications of schema elements required to implement replication agreements and replication processes. During this presentation there was more discussion about the pros and cons of time-based and monotonic sequence numbers for transactions in a distributed replication environment. We agreed that this subject would be punted to the list. We reviewed John Strassner's hand-written charts of content from the proposed WG charter and John read aloud the sections of the charter that he didn't have time to scribe. There were a few comments and requests for changes: - the terms "updateable", "writeable" and similar terms are used interchangeably; we agreed to use only the term "updateable" - add a sentence indicating motivation for solving the single- and multi-master replication problems - replace terms like "zombies", "graveyard", and "tombstones" with "deletion state" or a grammatically appropriate substitute - add "v3" to all uses of "LDAP" in this charter - use a consistent prefix for all document titles: "LDAPv3 Replication..." - several milestone dates were changed to make them more realistic. It should be noted that all of the authors of these documents that were present stated that they should be able to hold these new dates. The co-chairs have an action to post a revised proposed charter to the mailing list for a review period of one week and will follow this up with a request for IESG review. Three out of the 7 documents that group will produce have been drafted and are to be published as I-Ds (or revised if already published) over the next few weeks. When polled, BOF attendees expressed strong interest in forming a working group based on the charter discussions and the architecture presentation. The BOF-room concensus was that forming a WG is in order. No dissenting opinion was expressed. Finally, Patrik stated that he has been monitoring the progress of the Engineering Team and is pleased, and also thinks that forming a WG is a Good Thing. regards, Chris and John From owner-ietf-ldup Wed Sep 23 12:57:35 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA25199 for ietf-ldup-bks; Wed, 23 Sep 1998 12:57:35 -0700 (PDT) Received: from i.control.att.com (H-135-205-52-126.control.att.com [135.205.52.126] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25195 for ; Wed, 23 Sep 1998 12:57:28 -0700 (PDT) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Wed, 23 Sep 1998 16:03:27 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for ietf-ldup@imc.org; Wed, 23 Sep 1998 16:03:32 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Wed, 23 Sep 1998 16:03:32 -0400 (EDT) From: capple@master.control.att.com (Christopher W Apple) To: ietf-ldup@imc.org Subject: Proposed LDUP Charter Sender: owner-ietf-ldup@imc.org Precedence: bulk This is the version of the charter that John Strassner and I plan to send to the Apps Co-ADs for IESG review to form a WG. Please post comments to the list by 10/1/1998. On 10/2/1998 this will be sent to the Co-ADs unless there are changes which require more discussion on the list. Thanks! Chris Apple John Strassner LDAPv3 Duplication/Replication/Update Protocol (LDUP) Charter Chair(s): Chris Apple John Strassner Applications Area Director(s): Keith Moore Patrik Faltstrom Operations and Management Area Advisor: Patrik Faltstrom Mailing lists: General Discussion: ietf-ldup@imc.org To Subscribe: ietf-ldup-request@imc.org In Body: subscribe Archive: http://www.imc.org/ietf-ldup/ Description of Working Group: As LDAPv3 becomes more widely deployed, replication of data across servers running different implementations becomes an important part of providing a distributed directory service. However, the LDAPv3 community, to date, has focused on standardizing the client-server access protocol. Therefore, this group will standardize master-slave and multi-master LDAPv3 replication as defined below: Multi-Master Replication - A replication model where entries can be written and updated on any of several replica copies, without requiring communication with other masters before the write or update is performed. Master-Slave, or Single-Master Replication - A replication model that assumes only one server, the master, allows write access to the replicated data. Note that Master-Slave replication can be considered a proper subset of multi-master replication. Our approach is to first develop a set of requirements for LDAPv3 directory replication and write an applicability statement defining scenarios on which replication requirements are based. An engineering team was formed consisting of different vendors and the co-chairs in order to harmonize the existing approaches into a single standard approach. All of these have been accomplished during the pre-working group stage. It should be noted, however, that replication using heterogeneous servers is dependent on resolving access control issues, which are the domain of other working groups. The new replication architecture support all forms of replication mentioned above. Six areas of working group focus have been identified through LDUP Engineering Team discussions, each leading to one or more documents to be published: * Abstract Model of LDAPv3 Replication This documents a general-purpose LDAPv3 replication architecture, define key components of this architecture, describes how these key components functionally behave, and describes how these components interact with each other when in various modes of operation * LDAPv3 Replication Information Model Defines the schema and semantics of information used to operate, administer, maintain, and provision replication between LDAPv3 servers. Specifically, this document will contain common schema specifications intended to facilitate interoperable implementations with respect to: + replication agreements + consistency models + replication topologies + managing deleted objects and their states + administration and management * LDAPv3 Replication Information Transport Protocol LDAPv3 extended operation and control specifications required to allow LDAPv3 to be used as the transport protocol for information being replicated * Mandatory Replica Management Specifications required to allow administration, maintenance, and provisioning of replicas and replication agreements. These specifications may take the form of definitions for LDAPv3 extended operations, controls, and/or new schema elements. * Conflict Detection and Resolution Procedures Procedures for detection and resolution of conflicts between the state of multiple replicas that contain information from the same unit of replication. * Profiles Including the Abstract Replication Model, Information Model, LDAPv3 Protocol Extensions, and Conflict Detection and Resolution Procedures for: + Master-Slave LDAPv3 Directory Replication + Multi-Master LDAPv3 Directory Replication Milestones: done May 1998 LDAPv3 Directory Replication Requirements and Applicability Statement I-D Published. done May 1998 Participants publish LDAPv3 replication concept proposals to LDUP Engineering team mailing list. done Jun 1998 Harmonization of different vendor replication LDAPv3 concept proposals is complete. Sep 1998 LDAPv3 Abstract Model of Replication (based on the concensus of the LDUP Engineering Team) is published as an I-D. Oct 1998 LDAPv3 Directory Replication Requirements and Applicability Statement I-D goes to WG Last Call as Informational. Oct 1998 LDAPv3 Replication Information Model is published as an I-D. Oct 1998 LDAPv3 Replication Information Transport Protocol is published as an I-D. Nov 1998 LDAPv3 Mandatory Replica Management is published as an I-D. Nov 1998 LDAPv3 Conflict Detection and Resolution Procedures is published as an I-D. Dec 1998 LDAPv3 Abstract Model of Replication goes to WG Last Call as Informational. Dec 1998 LDAPv3 Multi-Master Replication Profile is published as an I-D. Jan 1998 LDAPv3 Master-Slave Replication Profile is published as an I-D. Jan 1998 LDAPv3 Replication Information Model goes to WG Last Call as Proposed Standard. Jan 1998 LDAPv3 Replication Information Transport Protocol goes to WG Last Call as Proposed Standard. Feb 1999 LDAPv3 Mandatory Replica Management goes to WG Last Call as Proposed Standard. Feb 1999 LDAPv3 Conflict Detection and Resolution Procedures goes to WG Last Call as Proposed Standard. Apr 1999 LDAPv3 Master-Slave LDAPv3 Replication Profile goes to WG Last Call as Proposed Standard. Apr 1999 LDAPv3 Multi-Master LDAPv3 Replication Profile goes to WG Last Call as Proposed Standard. From owner-ietf-ldup Wed Sep 23 20:18:31 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA28296 for ietf-ldup-bks; Wed, 23 Sep 1998 20:18:31 -0700 (PDT) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA28290 for ; Wed, 23 Sep 1998 20:18:16 -0700 (PDT) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id ; Thu, 24 Sep 1998 13:22:26 +1000 Message-ID: From: Alan Lloyd To: "'ietf-ldup@imc.org '" , "'capple@master.control.att.com '" Subject: RE: Proposed LDUP Charter Date: Thu, 24 Sep 1998 13:22:21 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldup@imc.org Precedence: bulk Chris edits - there are a few "Jan 1998s" in the task list I would not mind an honest answer re this lists view on the integration or harmonisation of X.500 DISP. It seems LDAP is almost at DAP capability (with the few additions I have proposed). However with LDAP the world has now got a few issues to say the least re scaling and the operational management overheads of it. ie. There still no firm system design on how clients find and select master or replicas - without masses of configuration by hand. So candid views are welcomed. regards alan PS Lightweight Directory Access Protocol Replication Information Transport Protocol - is a bit long. ---------- From: capple@master.control.att.com To: ietf-ldup@imc.org Sent: 9/24/98 6:03:32 AM Subject: Proposed LDUP Charter This is the version of the charter that John Strassner and I plan to send to the Apps Co-ADs for IESG review to form a WG. Please post comments to the list by 10/1/1998. On 10/2/1998 this will be sent to the Co-ADs unless there are changes which require more discussion on the list. Thanks! Chris Apple John Strassner LDAPv3 Duplication/Replication/Update Protocol (LDUP) Charter Chair(s): Chris Apple John Strassner Applications Area Director(s): Keith Moore Patrik Faltstrom Operations and Management Area Advisor: Patrik Faltstrom Mailing lists: General Discussion: ietf-ldup@imc.org To Subscribe: ietf-ldup-request@imc.org In Body: subscribe Archive: http://www.imc.org/ietf-ldup/ Description of Working Group: As LDAPv3 becomes more widely deployed, replication of data across servers running different implementations becomes an important part of providing a distributed directory service. However, the LDAPv3 community, to date, has focused on standardizing the client-server access protocol. Therefore, this group will standardize master-slave and multi-master LDAPv3 replication as defined below: Multi-Master Replication - A replication model where entries can be written and updated on any of several replica copies, without requiring communication with other masters before the write or update is performed. Master-Slave, or Single-Master Replication - A replication model that assumes only one server, the master, allows write access to the replicated data. Note that Master-Slave replication can be considered a proper subset of multi-master replication. Our approach is to first develop a set of requirements for LDAPv3 directory replication and write an applicability statement defining scenarios on which replication requirements are based. An engineering team was formed consisting of different vendors and the co-chairs in order to harmonize the existing approaches into a single standard approach. All of these have been accomplished during the pre-working group stage. It should be noted, however, that replication using heterogeneous servers is dependent on resolving access control issues, which are the domain of other working groups. The new replication architecture support all forms of replication mentioned above. Six areas of working group focus have been identified through LDUP Engineering Team discussions, each leading to one or more documents to be published: * Abstract Model of LDAPv3 Replication This documents a general-purpose LDAPv3 replication architecture, define key components of this architecture, describes how these key components functionally behave, and describes how these components interact with each other when in various modes of operation * LDAPv3 Replication Information Model Defines the schema and semantics of information used to operate, administer, maintain, and provision replication between LDAPv3 servers. Specifically, this document will contain common schema specifications intended to facilitate interoperable implementations with respect to: + replication agreements + consistency models + replication topologies + managing deleted objects and their states + administration and management * LDAPv3 Replication Information Transport Protocol LDAPv3 extended operation and control specifications required to allow LDAPv3 to be used as the transport protocol for information being replicated * Mandatory Replica Management Specifications required to allow administration, maintenance, and provisioning of replicas and replication agreements. These specifications may take the form of definitions for LDAPv3 extended operations, controls, and/or new schema elements. * Conflict Detection and Resolution Procedures Procedures for detection and resolution of conflicts between the state of multiple replicas that contain information from the same unit of replication. * Profiles Including the Abstract Replication Model, Information Model, LDAPv3 Protocol Extensions, and Conflict Detection and Resolution Procedures for: + Master-Slave LDAPv3 Directory Replication + Multi-Master LDAPv3 Directory Replication Milestones: done May 1998 LDAPv3 Directory Replication Requirements and Applicability Statement I-D Published. done May 1998 Participants publish LDAPv3 replication concept proposals to LDUP Engineering team mailing list. done Jun 1998 Harmonization of different vendor replication LDAPv3 concept proposals is complete. Sep 1998 LDAPv3 Abstract Model of Replication (based on the concensus of the LDUP Engineering Team) is published as an I-D. Oct 1998 LDAPv3 Directory Replication Requirements and Applicability Statement I-D goes to WG Last Call as Informational. Oct 1998 LDAPv3 Replication Information Model is published as an I-D. Oct 1998 LDAPv3 Replication Information Transport Protocol is published as an I-D. Nov 1998 LDAPv3 Mandatory Replica Management is published as an I-D. Nov 1998 LDAPv3 Conflict Detection and Resolution Procedures is published as an I-D. Dec 1998 LDAPv3 Abstract Model of Replication goes to WG Last Call as Informational. Dec 1998 LDAPv3 Multi-Master Replication Profile is published as an I-D. Jan 1998 LDAPv3 Master-Slave Replication Profile is published as an I-D. Jan 1998 LDAPv3 Replication Information Model goes to WG Last Call as Proposed Standard. Jan 1998 LDAPv3 Replication Information Transport Protocol goes to WG Last Call as Proposed Standard. Feb 1999 LDAPv3 Mandatory Replica Management goes to WG Last Call as Proposed Standard. Feb 1999 LDAPv3 Conflict Detection and Resolution Procedures goes to WG Last Call as Proposed Standard. Apr 1999 LDAPv3 Master-Slave LDAPv3 Replication Profile goes to WG Last Call as Proposed Standard. Apr 1999 LDAPv3 Multi-Master LDAPv3 Replication Profile goes to WG Last Call as Proposed Standard. From owner-ietf-ldup Thu Sep 24 08:20:16 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA21985 for ietf-ldup-bks; Thu, 24 Sep 1998 08:20:16 -0700 (PDT) Received: from orm-mail20.provo.novell.com (orm-mail20.orem.novell.com [151.155.118.32]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA21981 for ; Thu, 24 Sep 1998 08:20:11 -0700 (PDT) Received: from INET-ORM-Message_Server by orm-mail20.provo.novell.com with Novell_GroupWise; Thu, 24 Sep 1998 09:26:10 -0600 Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Thu, 24 Sep 1998 09:25:57 -0600 From: "Ed Reed" To: , , Subject: RE: Proposed LDUP Charter 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 mail.proper.com id IAA21982 Sender: owner-ietf-ldup@imc.org Precedence: bulk My take is that X.500 DISP is a likely candidate for another replication mechanism which might be indicated on replication agreements, but it doesn't address the accepted requirement for multi-master replication. We know there will be others defined, but the one we're defining here is the multi-master mechanism to be standardized. It's likely that profile of usage we write which shows how to use this mechanism for single-master configurations will map well onto DISP, but with differences in how things are represented in transfer and in configuration. Instructing clients as to how to leverage the new knowledge about where replicas of data may be found, and indeed, which replicas hold which data (for incomplete replicas) is identified as work that needs to be done, but is outside the limited scope of LDUP. I think something informed by the Hierarchical Operations of X.519, and perhaps NDS, needs to be worked in here, in the broader context of distributed LDAP operations. Regards, Ed ---------------------- Ed Reed, Technologist Novell, Inc. +1 801 861-3320 >>> Alan Lloyd 09/23/1998 21:22:21 >>> Chris edits - there are a few "Jan 1998s" in the task list I would not mind an honest answer re this lists view on the integration or harmonisation of X.500 DISP. It seems LDAP is almost at DAP capability (with the few additions I have proposed). However with LDAP the world has now got a few issues to say the least re scaling and the operational management overheads of it. ie. There still no firm system design on how clients find and select master or replicas - without masses of configuration by hand. So candid views are welcomed. regards alan PS Lightweight Directory Access Protocol Replication Information Transport Protocol - is a bit long. ---------- From: capple@master.control.att.com To: ietf-ldup@imc.org Sent: 9/24/98 6:03:32 AM Subject: Proposed LDUP Charter This is the version of the charter that John Strassner and I plan to send to the Apps Co-ADs for IESG review to form a WG. Please post comments to the list by 10/1/1998. On 10/2/1998 this will be sent to the Co-ADs unless there are changes which require more discussion on the list. Thanks! Chris Apple John Strassner LDAPv3 Duplication/Replication/Update Protocol (LDUP) Charter Chair(s): Chris Apple John Strassner Applications Area Director(s): Keith Moore Patrik Faltstrom Operations and Management Area Advisor: Patrik Faltstrom Mailing lists: General Discussion: ietf-ldup@imc.org To Subscribe: ietf-ldup-request@imc.org In Body: subscribe Archive: http://www.imc.org/ietf-ldup/ Description of Working Group: As LDAPv3 becomes more widely deployed, replication of data across servers running different implementations becomes an important part of providing a distributed directory service. However, the LDAPv3 community, to date, has focused on standardizing the client-server access protocol. Therefore, this group will standardize master-slave and multi-master LDAPv3 replication as defined below: Multi-Master Replication - A replication model where entries can be written and updated on any of several replica copies, without requiring communication with other masters before the write or update is performed. Master-Slave, or Single-Master Replication - A replication model that assumes only one server, the master, allows write access to the replicated data. Note that Master-Slave replication can be considered a proper subset of multi-master replication. Our approach is to first develop a set of requirements for LDAPv3 directory replication and write an applicability statement defining scenarios on which replication requirements are based. An engineering team was formed consisting of different vendors and the co-chairs in order to harmonize the existing approaches into a single standard approach. All of these have been accomplished during the pre-working group stage. It should be noted, however, that replication using heterogeneous servers is dependent on resolving access control issues, which are the domain of other working groups. The new replication architecture support all forms of replication mentioned above. Six areas of working group focus have been identified through LDUP Engineering Team discussions, each leading to one or more documents to be published: * Abstract Model of LDAPv3 Replication This documents a general-purpose LDAPv3 replication architecture, define key components of this architecture, describes how these key components functionally behave, and describes how these components interact with each other when in various modes of operation * LDAPv3 Replication Information Model Defines the schema and semantics of information used to operate, administer, maintain, and provision replication between LDAPv3 servers. Specifically, this document will contain common schema specifications intended to facilitate interoperable implementations with respect to: + replication agreements + consistency models + replication topologies + managing deleted objects and their states + administration and management * LDAPv3 Replication Information Transport Protocol LDAPv3 extended operation and control specifications required to allow LDAPv3 to be used as the transport protocol for information being replicated * Mandatory Replica Management Specifications required to allow administration, maintenance, and provisioning of replicas and replication agreements. These specifications may take the form of definitions for LDAPv3 extended operations, controls, and/or new schema elements. * Conflict Detection and Resolution Procedures Procedures for detection and resolution of conflicts between the state of multiple replicas that contain information from the same unit of replication. * Profiles Including the Abstract Replication Model, Information Model, LDAPv3 Protocol Extensions, and Conflict Detection and Resolution Procedures for: + Master-Slave LDAPv3 Directory Replication + Multi-Master LDAPv3 Directory Replication Milestones: done May 1998 LDAPv3 Directory Replication Requirements and Applicability Statement I-D Published. done May 1998 Participants publish LDAPv3 replication concept proposals to LDUP Engineering team mailing list. done Jun 1998 Harmonization of different vendor replication LDAPv3 concept proposals is complete. Sep 1998 LDAPv3 Abstract Model of Replication (based on the concensus of the LDUP Engineering Team) is published as an I-D. Oct 1998 LDAPv3 Directory Replication Requirements and Applicability Statement I-D goes to WG Last Call as Informational. Oct 1998 LDAPv3 Replication Information Model is published as an I-D. Oct 1998 LDAPv3 Replication Information Transport Protocol is published as an I-D. Nov 1998 LDAPv3 Mandatory Replica Management is published as an I-D. Nov 1998 LDAPv3 Conflict Detection and Resolution Procedures is published as an I-D. Dec 1998 LDAPv3 Abstract Model of Replication goes to WG Last Call as Informational. Dec 1998 LDAPv3 Multi-Master Replication Profile is published as an I-D. Jan 1998 LDAPv3 Master-Slave Replication Profile is published as an I-D. Jan 1998 LDAPv3 Replication Information Model goes to WG Last Call as Proposed Standard. Jan 1998 LDAPv3 Replication Information Transport Protocol goes to WG Last Call as Proposed Standard. Feb 1999 LDAPv3 Mandatory Replica Management goes to WG Last Call as Proposed Standard. Feb 1999 LDAPv3 Conflict Detection and Resolution Procedures goes to WG Last Call as Proposed Standard. Apr 1999 LDAPv3 Master-Slave LDAPv3 Replication Profile goes to WG Last Call as Proposed Standard. Apr 1999 LDAPv3 Multi-Master LDAPv3 Replication Profile goes to WG Last Call as Proposed Standard. From owner-ietf-ldup Thu Sep 24 11:09:48 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA23823 for ietf-ldup-bks; Thu, 24 Sep 1998 11:09:48 -0700 (PDT) Received: from ottawa-mail.geotrain.on.ca (mail.pscgroup.com [209.146.178.198]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA23819 for ; Thu, 24 Sep 1998 11:09:45 -0700 (PDT) Received: from Skovgaard (vanc01m02-128.bctel.ca [206.108.197.128]) by ottawa-mail.geotrain.on.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id SS0R7582; Thu, 24 Sep 1998 14:18:01 -0400 Message-Id: <3.0.5.32.19980924090606.007af610@pop1.mda.ca> X-Sender: erik@pop1.mda.ca X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 24 Sep 1998 09:06:06 -0700 To: Alan Lloyd , "'ietf-ldup@imc.org '" , "'capple@master.control.att.com '" From: Erik Skovgaard Subject: RE: Proposed LDUP Charter In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@imc.org Precedence: bulk Alan, It certainly would make life easier for people with large X.500 installations. Perhaps a subset of DISP could be defined to allow developers to get started implementing replication? As it currently stands, users will either have to install a large X.500, that may not otherwise be warrented in a smaller organization, or they will have to put up with proprietary shadowing methods. Either way LDAP v3 is effectively neutered. Large organizations are simply not going to install it without a good distribution capability. It gets even worse when you are trying to implement a PKI infrastructure which needs to interoperate with customers, partners and vendors. I would suggest pushing forward with a subset of DISP is the best way forward. The protocols and information model have already been developed. They just need to be molded slightly for our purposes. We can then add multi-master replication later, if people are still keen on that. Cheers, ....Erik. ------------------------------------------- Erik Skovgaard GeoTrain Corp. LDAP/X.500 Consulting and Training http://wwww.geotrain.com +1 (604) 244-9131 At 13:22 24/09/98 +1000, Alan Lloyd wrote: >Chris >edits - there are a few "Jan 1998s" in the task list > > >I would not mind an honest answer re this lists view on the integration >or harmonisation of X.500 DISP. It seems LDAP is almost at DAP >capability (with the few additions I have proposed). However with LDAP >the world has now got a few issues to say the least re scaling and the >operational management overheads of it. > >ie. There still no firm system design on how clients find and select >master or replicas - without masses of configuration by hand. > >So candid views are welcomed. > >regards alan > >PS Lightweight Directory Access Protocol Replication Information >Transport Protocol - is a bit long. > > >---------- >From: capple@master.control.att.com >To: ietf-ldup@imc.org >Sent: 9/24/98 6:03:32 AM >Subject: Proposed LDUP Charter > >This is the version of the charter that John Strassner and I >plan to send to the Apps Co-ADs for IESG review to form a WG. >Please post comments to the list by 10/1/1998. On 10/2/1998 >this will be sent to the Co-ADs unless there are changes which >require more discussion on the list. > >Thanks! > >Chris Apple >John Strassner > >LDAPv3 Duplication/Replication/Update Protocol (LDUP) Charter > >Chair(s): > Chris Apple > John Strassner > >Applications Area Director(s): > > Keith Moore > Patrik Faltstrom > >Operations and Management Area Advisor: > > Patrik Faltstrom > >Mailing lists: > General Discussion: ietf-ldup@imc.org > To Subscribe: ietf-ldup-request@imc.org > In Body: subscribe > Archive: http://www.imc.org/ietf-ldup/ > >Description of Working Group: > >As LDAPv3 becomes more widely deployed, replication of data across >servers running different implementations becomes an important >part of providing a distributed directory service. However, the LDAPv3 >community, to date, has focused on standardizing the client-server >access protocol. Therefore, this group will standardize master-slave >and multi-master LDAPv3 replication as defined below: > > Multi-Master Replication - A replication model where entries can > be written and updated on any of several replica copies, without > requiring communication with other masters before the write or > update is performed. > > Master-Slave, or Single-Master Replication - A replication model > that assumes only one server, the master, allows write access to > the replicated data. Note that Master-Slave replication can be > considered a proper subset of multi-master replication. > >Our approach is to first develop a set of requirements for LDAPv3 >directory replication and write an applicability statement defining >scenarios on which replication requirements are based. An engineering >team was formed consisting of different vendors and the co-chairs in >order to harmonize the existing approaches into a single standard >approach. All of these have been accomplished during the pre-working >group stage. It should be noted, however, that replication using >heterogeneous servers is dependent on resolving access control issues, >which are the domain of other working groups. > >The new replication architecture support all forms of replication >mentioned above. Six areas of working group focus have been identified >through LDUP Engineering Team discussions, each leading to one or >more documents to be published: > > * Abstract Model of LDAPv3 Replication > > This documents a general-purpose LDAPv3 replication > architecture, define key components of this architecture, > describes how these key components functionally behave, > and describes how these components interact with each other > when in various modes of operation > > * LDAPv3 Replication Information Model > > Defines the schema and semantics of information used to > operate, administer, maintain, and provision replication > between LDAPv3 servers. Specifically, this document will > contain common schema specifications intended to > facilitate interoperable implementations with respect to: > > + replication agreements > + consistency models > + replication topologies > + managing deleted objects and their states > + administration and management > > * LDAPv3 Replication Information Transport Protocol > > LDAPv3 extended operation and control specifications > required to allow LDAPv3 to be used as the transport > protocol for information being replicated > > * Mandatory Replica Management > > Specifications required to allow administration, > maintenance, and provisioning of replicas and > replication agreements. These specifications may > take the form of definitions for LDAPv3 extended > operations, controls, and/or new schema elements. > > * Conflict Detection and Resolution Procedures > > Procedures for detection and resolution of conflicts > between the state of multiple replicas that contain > information from the same unit of replication. > > * Profiles > > Including the Abstract Replication Model, Information > Model, LDAPv3 Protocol Extensions, and Conflict Detection > and Resolution Procedures for: > > + Master-Slave LDAPv3 Directory Replication > + Multi-Master LDAPv3 Directory Replication > >Milestones: > >done May 1998 LDAPv3 Directory Replication Requirements and > Applicability Statement I-D Published. > >done May 1998 Participants publish LDAPv3 replication concept > proposals to LDUP Engineering team mailing list. > >done Jun 1998 Harmonization of different vendor replication > LDAPv3 concept proposals is complete. > > Sep 1998 LDAPv3 Abstract Model of Replication (based on the > concensus of the LDUP Engineering Team) is published > as an I-D. > > Oct 1998 LDAPv3 Directory Replication Requirements and > Applicability Statement I-D goes to WG Last Call > as Informational. > > Oct 1998 LDAPv3 Replication Information Model is published > as an I-D. > > Oct 1998 LDAPv3 Replication Information Transport Protocol is > published as an I-D. > > Nov 1998 LDAPv3 Mandatory Replica Management is published as > an I-D. > > Nov 1998 LDAPv3 Conflict Detection and Resolution Procedures > is published as an I-D. > > Dec 1998 LDAPv3 Abstract Model of Replication goes to WG Last > Call as Informational. > > Dec 1998 LDAPv3 Multi-Master Replication Profile is published > as an I-D. > > Jan 1998 LDAPv3 Master-Slave Replication Profile is published > as an I-D. > > Jan 1998 LDAPv3 Replication Information Model goes to WG Last > Call as Proposed Standard. > > Jan 1998 LDAPv3 Replication Information Transport Protocol > goes to WG Last Call as Proposed Standard. > > Feb 1999 LDAPv3 Mandatory Replica Management goes to WG Last Call > as Proposed Standard. > > Feb 1999 LDAPv3 Conflict Detection and Resolution Procedures goes >to > WG Last Call as Proposed Standard. > > Apr 1999 LDAPv3 Master-Slave LDAPv3 Replication Profile goes to >WG > Last Call as Proposed Standard. > > Apr 1999 LDAPv3 Multi-Master LDAPv3 Replication Profile goes to >WG > Last Call as Proposed Standard. > > > From owner-ietf-ldup Fri Sep 25 08:36:44 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA22697 for ietf-ldup-bks; Fri, 25 Sep 1998 08:36:44 -0700 (PDT) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA22692 for ; Fri, 25 Sep 1998 08:36:23 -0700 (PDT) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id ; Sat, 26 Sep 1998 01:40:30 +1000 Message-ID: From: Alan Lloyd To: Alan Lloyd , "''ietf-ldup@imc.org ' '" , "''capple@master.control.att.com ' '" , "'Erik Skovgaard '" Subject: RE: Proposed LDUP Charter Date: Sat, 26 Sep 1998 01:40:28 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldup@imc.org Precedence: bulk Erik - thanks for that. Absolutely agree re the larger directory systems. In fact we provide a range of import/export tools, LDIF facilities, DISP facilities and because we have a relational back end database we can use the commercial on line replication facilities. In fact that seems to be a preference when one gets to the bigger and more dependant systems where online distaster recovery backups of the directory system are mandated. The main concerns I have is that LDAP has turned out to be a mass of operational weaknesses with many scaleability problems. I would not like to have a yet another replication technology that was had little integrity in the real commercial world or was full of high operational costs. If things are simple to implement then by defintion they do little and in the case of dealing with fault tolerant, business level, information infrastructures, which is a complex transaction issue, simple mechanisms wont do a thing. So if things must be simple in LDUP they will be useless for the real world - but if LDUP is only used for address book synchronisation then it does not matter. Perhaps getting the protocol requirements defined will help. regards alan ---------- From: Erik Skovgaard To: Alan Lloyd; 'ietf-ldup@imc.org '; 'capple@master.control.att.com ' Sent: 9/25/98 2:06:06 AM Subject: RE: Proposed LDUP Charter Alan, It certainly would make life easier for people with large X.500 installations. Perhaps a subset of DISP could be defined to allow developers to get started implementing replication? As it currently stands, users will either have to install a large X.500, that may not otherwise be warrented in a smaller organization, or they will have to put up with proprietary shadowing methods. Either way LDAP v3 is effectively neutered. Large organizations are simply not going to install it without a good distribution capability. It gets even worse when you are trying to implement a PKI infrastructure which needs to interoperate with customers, partners and vendors. I would suggest pushing forward with a subset of DISP is the best way forward. The protocols and information model have already been developed. They just need to be molded slightly for our purposes. We can then add multi-master replication later, if people are still keen on that. Cheers, ....Erik. ------------------------------------------- Erik Skovgaard GeoTrain Corp. LDAP/X.500 Consulting and Training http://wwww.geotrain.com +1 (604) 244-9131 At 13:22 24/09/98 +1000, Alan Lloyd wrote: >Chris >edits - there are a few "Jan 1998s" in the task list > > >I would not mind an honest answer re this lists view on the integration >or harmonisation of X.500 DISP. It seems LDAP is almost at DAP >capability (with the few additions I have proposed). However with LDAP >the world has now got a few issues to say the least re scaling and the >operational management overheads of it. > >ie. There still no firm system design on how clients find and select >master or replicas - without masses of configuration by hand. > >So candid views are welcomed. > >regards alan > >PS Lightweight Directory Access Protocol Replication Information >Transport Protocol - is a bit long. > > >---------- >From: capple@master.control.att.com >To: ietf-ldup@imc.org >Sent: 9/24/98 6:03:32 AM >Subject: Proposed LDUP Charter > >This is the version of the charter that John Strassner and I >plan to send to the Apps Co-ADs for IESG review to form a WG. >Please post comments to the list by 10/1/1998. On 10/2/1998 >this will be sent to the Co-ADs unless there are changes which >require more discussion on the list. > >Thanks! > >Chris Apple >John Strassner > >LDAPv3 Duplication/Replication/Update Protocol (LDUP) Charter > >Chair(s): > Chris Apple > John Strassner > >Applications Area Director(s): > > Keith Moore > Patrik Faltstrom > >Operations and Management Area Advisor: > > Patrik Faltstrom > >Mailing lists: > General Discussion: ietf-ldup@imc.org > To Subscribe: ietf-ldup-request@imc.org > In Body: subscribe > Archive: http://www.imc.org/ietf-ldup/ > >Description of Working Group: > >As LDAPv3 becomes more widely deployed, replication of data across >servers running different implementations becomes an important >part of providing a distributed directory service. However, the LDAPv3 >community, to date, has focused on standardizing the client-server >access protocol. Therefore, this group will standardize master-slave >and multi-master LDAPv3 replication as defined below: > > Multi-Master Replication - A replication model where entries can > be written and updated on any of several replica copies, without > requiring communication with other masters before the write or > update is performed. > > Master-Slave, or Single-Master Replication - A replication model > that assumes only one server, the master, allows write access to > the replicated data. Note that Master-Slave replication can be > considered a proper subset of multi-master replication. > >Our approach is to first develop a set of requirements for LDAPv3 >directory replication and write an applicability statement defining >scenarios on which replication requirements are based. An engineering >team was formed consisting of different vendors and the co-chairs in >order to harmonize the existing approaches into a single standard >approach. All of these have been accomplished during the pre-working >group stage. It should be noted, however, that replication using >heterogeneous servers is dependent on resolving access control issues, >which are the domain of other working groups. > >The new replication architecture support all forms of replication >mentioned above. Six areas of working group focus have been identified >through LDUP Engineering Team discussions, each leading to one or >more documents to be published: > > * Abstract Model of LDAPv3 Replication > > This documents a general-purpose LDAPv3 replication > architecture, define key components of this architecture, > describes how these key components functionally behave, > and describes how these components interact with each other > when in various modes of operation > > * LDAPv3 Replication Information Model > > Defines the schema and semantics of information used to > operate, administer, maintain, and provision replication > between LDAPv3 servers. Specifically, this document will > contain common schema specifications intended to > facilitate interoperable implementations with respect to: > > + replication agreements > + consistency models > + replication topologies > + managing deleted objects and their states > + administration and management > > * LDAPv3 Replication Information Transport Protocol > > LDAPv3 extended operation and control specifications > required to allow LDAPv3 to be used as the transport > protocol for information being replicated > > * Mandatory Replica Management > > Specifications required to allow administration, > maintenance, and provisioning of replicas and > replication agreements. These specifications may > take the form of definitions for LDAPv3 extended > operations, controls, and/or new schema elements. > > * Conflict Detection and Resolution Procedures > > Procedures for detection and resolution of conflicts > between the state of multiple replicas that contain > information from the same unit of replication. > > * Profiles > > Including the Abstract Replication Model, Information > Model, LDAPv3 Protocol Extensions, and Conflict Detection > and Resolution Procedures for: > > + Master-Slave LDAPv3 Directory Replication > + Multi-Master LDAPv3 Directory Replication > >Milestones: > >done May 1998 LDAPv3 Directory Replication Requirements and > Applicability Statement I-D Published. > >done May 1998 Participants publish LDAPv3 replication concept > proposals to LDUP Engineering team mailing list. > >done Jun 1998 Harmonization of different vendor replication > LDAPv3 concept proposals is complete. > > Sep 1998 LDAPv3 Abstract Model of Replication (based on the > concensus of the LDUP Engineering Team) is published > as an I-D. > > Oct 1998 LDAPv3 Directory Replication Requirements and > Applicability Statement I-D goes to WG Last Call > as Informational. > > Oct 1998 LDAPv3 Replication Information Model is published > as an I-D. > > Oct 1998 LDAPv3 Replication Information Transport Protocol is > published as an I-D. > > Nov 1998 LDAPv3 Mandatory Replica Management is published as > an I-D. > > Nov 1998 LDAPv3 Conflict Detection and Resolution Procedures > is published as an I-D. > > Dec 1998 LDAPv3 Abstract Model of Replication goes to WG Last > Call as Informational. > > Dec 1998 LDAPv3 Multi-Master Replication Profile is published > as an I-D. > > Jan 1998 LDAPv3 Master-Slave Replication Profile is published > as an I-D. > > Jan 1998 LDAPv3 Replication Information Model goes to WG Last > Call as Proposed Standard. > > Jan 1998 LDAPv3 Replication Information Transport Protocol > goes to WG Last Call as Proposed Standard. > > Feb 1999 LDAPv3 Mandatory Replica Management goes to WG Last Call > as Proposed Standard. > > Feb 1999 LDAPv3 Conflict Detection and Resolution Procedures goes >to > WG Last Call as Proposed Standard. > > Apr 1999 LDAPv3 Master-Slave LDAPv3 Replication Profile goes to >WG > Last Call as Proposed Standard. > > Apr 1999 LDAPv3 Multi-Master LDAPv3 Replication Profile goes to >WG > Last Call as Proposed Standard. > > > From owner-ietf-ldup Fri Sep 25 09:37:01 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23297 for ietf-ldup-bks; Fri, 25 Sep 1998 09:37:01 -0700 (PDT) Received: from i.control.att.com (H-135-205-52-126.control.att.com [135.205.52.126] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA23291 for ; Fri, 25 Sep 1998 09:37:00 -0700 (PDT) Received: from master.control.att.com(really [135.205.52.13]) by i.control.att.com via sendmail with esmtp id for ; Fri, 25 Sep 1998 12:43:09 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #1 built 1997-May-3) Received: by master.control.att.com via sendmail with stdio id for ietf-ldup@imc.org; Fri, 25 Sep 1998 12:43:14 -0400 (EDT) (Smail-3.2.0.94 1997-Apr-22 #4 built 1997-May-2) Message-Id: Date: Fri, 25 Sep 1998 12:43:14 -0400 (EDT) From: capple@master.control.att.com (Christopher W Apple) To: ietf-ldup@imc.org Subject: RE: Proposed LDUP Charter Sender: owner-ietf-ldup@imc.org Precedence: bulk >Perhaps getting the protocol requirements defined will help. The LDUP requirements document can be accessed using: http://search.ietf.org/internet-drafts/draft-weiser-replica-req-01.txt ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Service Internet Directory Group http://www.anywho.com AT&T Labs capple@master.control.att.com +1 908 582 2409 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ From owner-ietf-ldup Sat Sep 26 14:34:21 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA20584 for ietf-ldup-bks; Sat, 26 Sep 1998 14:34:21 -0700 (PDT) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA20580 for ; Sat, 26 Sep 1998 14:34:17 -0700 (PDT) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id ; Sun, 27 Sep 1998 07:38:27 +1000 Message-ID: From: Alan Lloyd To: "'ietf-ldup@imc.org '" , "'capple@master.control.att.com '" Subject: RE: Proposed LDUP Charter Date: Sun, 27 Sep 1998 07:38:26 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ietf-ldup@imc.org Precedence: bulk Thanks for that Chris - and I realised that X.525 is mentioned in the requirements. However, X.500 and DAP was mentioned in LDAP and look what happened. eg LDAP Extensions that wont work on distributed systems and all sorts of information and encoding issues. IMHO I think it is very bad engineering to have a protocol (eg. LDAP that permits extensions) and to put in these extensions other protocols that do different (semantically speaking) system operations. ie. I could add FTP as an LDAP extension and so on. This may seem a fun way of doing something but what happens - nobody in the commercial world dealing with this stuff knows what the differences are between LDAP V3 support in a client, a server, in replication, in LDAP single servers and what works in larger scale X.500 systems. ie an operational and interoperability a mess. I just do not believe using LDAP as a gladbag for anything that moves. No doubt as soon as the protocol spec is release many will comment. thanks and regards alan PS - cannot resist it. :-) Tired of slow and small directories - try X.500. ---------- From: capple@master.control.att.com To: ietf-ldup@imc.org Sent: 9/26/98 2:43:14 AM Subject: RE: Proposed LDUP Charter >Perhaps getting the protocol requirements defined will help. The LDUP requirements document can be accessed using: http://search.ietf.org/internet-drafts/draft-weiser-replica-req-01.txt ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Service Internet Directory Group http://www.anywho.com AT&T Labs capple@master.control.att.com +1 908 582 2409 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ From owner-ietf-ldup Sat Sep 26 15:19:27 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA20717 for ietf-ldup-bks; Sat, 26 Sep 1998 15:19:27 -0700 (PDT) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA20713 for ; Sat, 26 Sep 1998 15:19:19 -0700 (PDT) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id ; Sun, 27 Sep 1998 08:23:31 +1000 Message-ID: From: Alan Lloyd To: "'ietf-ldup@imc.org '" , "'capple@master.control.att.com '" , "'Ed Reed '" Subject: RE: Proposed LDUP Charter Date: Sun, 27 Sep 1998 08:23:29 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ietf-ldup@imc.org Precedence: bulk Ed thanks for that - good input. Here is a view re MM. I have also got a "impure" paper on our web site re backbone issues. some good points. a) Directory topologies. Replicated directories intermingle with a distributed directories. ie. One should always design the distributed components/requirements of a directory system first and then apply replication components for backup or local access requirements. I have seen many "replicated" system put together without any consideration for distribution with the obvious results. High operational costs, low integrity in the information, and a nightmare to manage if the information dynamics are high. With X.500 one can deal with distribution in many ways. ie with Root level DSA and subordinates, a range of First level DSAs that mulicast when Root level Search/Lists are performed (these FLDSAs also have subordinate DSAs if required). In addition, we can run our DSA without a database as DAP/LDAP, DSP, DISP router so that multiplexing and interconnection of top level DSAs can be effected in the most optimum way. In addition we can couple LDAP servers to our DSAs. Now given that some components of this system may need replicating for backup reasons and others for local access, etc. It is fundamental that knowledge references and naming contexts are dealt with correctly for Search /List etc and master/replica contexts are known. The point here is that I think its not very useful to define a replication protocol/process for directory systems untill one has a firm grip on the distribution and topology issues. Unless one is just considering simple server to simple server replication. b) With serious multi master mode, one needs serious engineering and that is not a simple protocol. As said we can use the commercial DB replicators that do very fast, robust replication below the X.500 level of operations - as well as tools, DISP and LDIF. The point here is that if the commercial world wants serious multi master facilities - I dont think LDAP the way it stands will do the job. It has no robustness. just thoughts and regards alan. ---------- From: Ed Reed To: ietf-ldup@imc.org; capple@master.control.att.com; Alan.Lloyd@OpenDirectory.com.au Sent: 9/25/98 1:25:57 AM Subject: RE: Proposed LDUP Charter My take is that X.500 DISP is a likely candidate for another replication mechanism which might be indicated on replication agreements, but it doesn't address the accepted requirement for multi-master replication. We know there will be others defined, but the one we're defining here is the multi-master mechanism to be standardized. It's likely that profile of usage we write which shows how to use this mechanism for single-master configurations will map well onto DISP, but with differences in how things are represented in transfer and in configuration. Instructing clients as to how to leverage the new knowledge about where replicas of data may be found, and indeed, which replicas hold which data (for incomplete replicas) is identified as work that needs to be done, but is outside the limited scope of LDUP. I think something informed by the Hierarchical Operations of X.519, and perhaps NDS, needs to be worked in here, in the broader context of distributed LDAP operations. Regards, Ed ---------------------- Ed Reed, Technologist Novell, Inc. +1 801 861-3320 removed previous text From owner-ietf-ldup Mon Sep 28 08:25:42 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA03851 for ietf-ldup-bks; Mon, 28 Sep 1998 08:25:42 -0700 (PDT) Received: from orm-mail20.provo.novell.com (orm-mail20.orem.novell.com [151.155.118.32]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA03847 for ; Mon, 28 Sep 1998 08:25:39 -0700 (PDT) Received: from INET-ORM-Message_Server by orm-mail20.provo.novell.com with Novell_GroupWise; Mon, 28 Sep 1998 09:32:36 -0600 Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Mon, 28 Sep 1998 09:32:22 -0600 From: "Ed Reed" To: , , "'Ed Reed '" , Subject: RE: if the commercial world wants serious multi-master facilities (was Re: Proposed LDUP Charter) 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 mail.proper.com id IAA03848 Sender: owner-ietf-ldup@imc.org Precedence: bulk One thing that is evident, is that "industry" is decidely schizophrenic when it comes to agreeing on what "it" wants. There are many, many deployment scenarios. Some emphasize rapid search on arbitrary criteria, others on selected specific criteria. Some emphasize lookup, not search, in order to read quickly a few bits of configuration or profile information associated with an entry (like a name service, or DNS does). Some require transactional integrity among all potential writers / updaters of information. Others emphasize availability of reasonably quick updates, even when they're unconnected to the rest of the replicated environment. Some just want to automate the propagation of descriptive information about users and administrators. Others want to manage relationships while trying to juggle some subset of all the other requirements. I generally categorize back end, database-to-database replication services as supporting transactional, or near transactional integrity facilities for the applications (including LDAP or X.500 or whatever) which use those data stores. This seems particularly interesting in clustered configurations at large network operating centers, where high speed, high capacity, high availability, high transaction rate services are offered, as for ISPs, national telcos and PTTs, etc. That is an interesting part of the industry, but by no means all, nor probably even a large fraction, of the directory market place. I generally categorize distributed name services, including NDS, as serving a role in supporting authentication and authorization services in a distributed, decentralized enterprise, where centralized management of the directory service and its topology is desired, but where distributed administration of content requires delegation of non-operational authority to users and secretaries, who create accounts, ACL groups and distribution lists for themselves, to support their local work environments. This is an interesting fraction of the industry, represented by Apollo, Xerox, Digital, Banyan, Novell, and (soon) Microsoft. The industry representatives, both customers and vendors, that I work with want these two broadly different categories of directory usage to play nice with each other, to share information with each other, and to reach out to the hundreds of other application specific repositories of user profiles that exist in corporations, and to exchange information about changes to content with each other. LDUP should facilitate that exchange of information, even among radically different repositories, by standardizing on representing the location of replicas of the directory, in the directory itself. By providing a useful set of extensible schema elements to document replica agreements, including specification of how different transfer protocols are documented, and how policy elements which one or both sides of a replication agreement values as important are to be documented. Mechanics of how changes are noted - at what granularity, are scheduled - by what event or time mechanism, are expressed - with what information about the change, are all defined for a common understanding of what change notifications mean. Defining a mechanism which is able to support both single-master and multi-master replication is only part of the whole story, as you point out. It will be encumbant on systems who perform transactional updates to not slop over into loose consistency operations without intending to. And it is, as always, the responsibility of applications to choose their data stores carefully, with requirements for consistency, latency, capacity, and availability in mind. Further thoughts... Ed >>> Alan Lloyd 09/26/1998 16:23:29 >>> [snip] b) With serious multi master mode, one needs serious engineering and that is not a simple protocol. As said we can use the commercial DB replicators that do very fast, robust replication below the X.500 level of operations - as well as tools, DISP and LDIF. The point here is that if the commercial world wants serious multi master facilities - I dont think LDAP the way it stands will do the job. It has no robustness. just thoughts and regards alan. ---------------------- Ed Reed, Technologist Novell, Inc. +1 801 861-3320 From owner-ietf-ldup Mon Oct 26 10:02:14 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA25263 for ietf-ldup-bks; Mon, 26 Oct 1998 10:02:14 -0800 (PST) Received: from prv-mail25.provo.novell.com (prv-mail25.Provo.Novell.COM [137.65.40.3]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA25259 for ; Mon, 26 Oct 1998 10:02:13 -0800 (PST) Received: from INET-PRV1-Message_Server by prv-mail25.provo.novell.com with Novell_GroupWise; Mon, 26 Oct 1998 11:03:41 -0700 Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Mon, 26 Oct 1998 11:03:33 -0700 From: "Ed Reed" To: , Subject: Fwd: WG Review:LDAP Duplication/Replication/Update Protocols (ldup) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_BEE9B16D.51303A0F" Sender: owner-ietf-ldup@imc.org Precedence: bulk This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_BEE9B16D.51303A0F Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline FYI - presume most of you have already seen this... ---------------------- Ed Reed, Technologist Novell, Inc. +1 801 861-3320 --=_BEE9B16D.51303A0F Content-Type: message/rfc822 Received: from prv-mx.provo.novell.com by prv-mail25.provo.novell.com; Mon, 26 Oct 1998 06:57:03 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by prv-mx.provo.novell.com; Mon, 26 Oct 1998 06:56:58 -0700 Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id IAA17781 for ietf-123-outbound.04@ietf.org; Mon, 26 Oct 1998 08:15:01 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA17590; Mon, 26 Oct 1998 08:11:20 -0500 (EST) Message-Id: <199810261311.IAA17590@ietf.org> To: IETF-Announce: ; cc: new-work@ietf.org Subject: WG Review:LDAP Duplication/Replication/Update Protocols (ldup) reply-to: iesg@ietf.org Date: Mon, 26 Oct 1998 08:11:20 -0500 From: Steve Coya A new IETF working group has been proposed in the Applications Area. The IESG has not made any determination as yet. The following Description was submitted, and is provided for informational purposes only: Description of Working Group: As LDAPv3 becomes more widely deployed, replication of data across servers running different implementations becomes an important part of providing a distributed directory service. However, the LDAPv3 community, to date, has focused on standardizing the client-server access protocol. Therefore, this group will standardize master-slave and multi-master LDAPv3 replication as defined below: o Multi-Master Replication - A replication model where entries can be written and updated on any of several replica copies, without requiring communication with other masters before the write or update is performed. o Master-Slave, or Single-Master Replication - A replication model that assumes only one server, the master, allows write access to the replicated data. Note that Master-Slave replication can be considered a proper subset of multi-master replication. The WG's approach is to first develop a set of requirements for LDAPv3 directory replication and write an applicability statement defining scenarios on which replication requirements are based. An engineering team was formed consisting of different vendors and the co-chairs in order to harmonize the existing approaches into a single standard approach. All of these have been accomplished during the pre-working group stage. It should be noted, however, that replication using heterogeneous servers is dependent on resolving access control issues, which are the domain of other working groups. The new replication architecture support all forms of replication mentioned above. Six areas of working group focus have been identified through LDUP Engineering Team discussions, each leading to one or more documents to be published: o Abstract Model of LDAPv3 Replication This documents a general-purpose LDAPv3 replication architecture, defines key components of this architecture, describes how these key components functionally behave, and describes how these components interact with each other when in various modes of operation o LDAPv3 Replication Information Model Defines the schema and semantics of information used to operate, administer, maintain, and provision replication between LDAPv3 servers. Specifically, this document will contain common schema specifications intended to facilitate interoperable implementations with respect to: + replication agreements + consistency models + replication topologies + managing deleted objects and their states + administration and management o LDAPv3 Replication Information Transport Protocol LDAPv3 extended operation and control specifications required to allow LDAPv3 to be used as the transport protocol for information being replicated o LDAPv3 Mandatory Replica Management Specifications required to allow administration, maintenance, and provisioning of replicas and replication agreements. These specifications may take the form of definitions for LDAPv3 extended operations, controls, and/or new schema elements. o LDAPv3 Conflict Detection and Resolution Procedures Procedures for detection and resolution of conflicts between the state of multiple replicas that contain information from the same unit of replication. o LDAPv3 Profiles Including the Abstract Replication Model, Information Model, LDAPv3 Protocol Extensions, and Conflict Detection and Resolution Procedures for: + Master-Slave LDAPv3 Directory Replication + Multi-Master LDAPv3 Directory Replication --=_BEE9B16D.51303A0F-- From owner-ietf-ldup Tue Oct 27 16:58:24 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA28185 for ietf-ldup-bks; Tue, 27 Oct 1998 16:58:24 -0800 (PST) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA28181 for ; Tue, 27 Oct 1998 16:58:20 -0800 (PST) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id ; Wed, 28 Oct 1998 11:56:03 +1100 Message-ID: From: Alan Lloyd To: "'Ed Reed'" , ietf-ldup@imc.org, ietf-ldapext@netscape.com Subject: RE: WG Review:LDAP Duplication/Replication/Update Protocols(ldup) Date: Wed, 28 Oct 1998 11:56:03 +1100 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ietf-ldup@imc.org Precedence: bulk Seen it, thanks In fact we have multi master (fault tolerant capabilities) with DB or DISP replication capabilities in our X.500 - so we can contribute to the multi DSA, MM mode operations spec. regards alan > -----Original Message----- > From: Ed Reed [SMTP:ED_REED@novell.com] > Sent: Tuesday, 27 October 1998 5:04 > To: ietf-ldup@imc.org; ietf-ldapext@netscape.com > Subject: Fwd: WG Review:LDAP Duplication/Replication/Update > Protocols(ldup) > > FYI - presume most of you have already seen this... > > ---------------------- > Ed Reed, Technologist > Novell, Inc. > +1 801 861-3320 << Message: WG Review:LDAP > Duplication/Replication/Update Protocols (ldup) >> From owner-ietf-ldup Mon Nov 16 04:58:42 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA16193 for ietf-ldup-bks; Mon, 16 Nov 1998 04:58:42 -0800 (PST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.proper.com (8.8.8/8.8.5) with SMTP id EAA16188 for ; Mon, 16 Nov 1998 04:58:38 -0800 (PST) Received: from France.Sun.COM ([129.157.188.1]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA17877; Mon, 16 Nov 1998 04:59:36 -0800 Received: from bebop.France.Sun.COM by France.Sun.COM (SMI-8.6/SMI-SVR4-sd.fkk200) id NAA03795; Mon, 16 Nov 1998 13:59:34 +0100 Received: from bondi by bebop.France.Sun.COM (SMI-8.6/SMI-SVR4) id NAA04123 for ; Mon, 16 Nov 1998 13:58:51 +0100 Date: Mon, 16 Nov 1998 13:57:51 +0100 (MET) From: Ludovic Poitou - Sun Microsystems Reply-To: Ludovic Poitou - Sun Microsystems Subject: Cthon 99 Registration Open (Fwd) To: ietf-ldapext@netscape.com, ldap-nis-interest@ufo.com.au, ietf-ldup@imc.org, IETF-LSD@LISTSERV.UMU.SE, openldap-general@openldap.org Cc: audrey@vanb.com In-Reply-To: "Your message with ID" <3640FCF6.53BB0803@vanb.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-ldup@imc.org Precedence: bulk For those who are interested by testing the interoperability of their LDAP enabled products, Connectathon `99 will take place in March 4-11 in San Jose. Connectathon brings together the world's LDAP engineers along with their implementations and source code. Then we have fun finding bugs in each other's code. There's also a series of talks over several afternoons (open to anyone who walks in). LDAP v3 and extensions will be a big topic of conversation there. Also, it will be a nice opportunity to test your clients and servers against the LDAP enabled Solaris 8 (prototype). For information on LDAP testing, contact Ludovic Poitou (ludovic.poitou@france.sun.com). The Connectathon website is at: www.connectathon.org I've appended additional information from Audrey Van Belleghem, the Connectathon manager. If you receive this message several times, excuse me for the cross-posting. Ludovic Poitou. >----------------Begin Forwarded Message----------------< Plans for Connectathon 99 are already under way! The 13th annual Connectathon event, an interoperability testing event for engineers only, will be held March 4-11, 1999, in San Jose, California. Connectathon, sponsored by Sun Microsystems, Inc., hosts over 40 companies annually in an effort to test and debug source code which utilize the following technologies and protocols: NFS versions 2, 3 and 4 NFS over TCP WebNFS Lock Manager NIS/NIS+/DNS TI-RPC Kerberos Automounter IPv6 IPsec DHCP Network Computers LDAP Service Location Protocol Gigabit Ethernet Y2K Compatibility Based on demand, in addition we are considering to offer: Fiber Channel Attached Loop ATM If you are interested in testing FCAL or ATM, please send a note to Cthon@Sun.COM and we'll gauge interest. Or if you have a suggestion for another technology, feel free to contact us as well. Testing continues 24 hours per day. Technology testing coordinators will organize testing procedures and test suite material. In addition, there will be seminars with speakers addressing various topics. The registration deadline is February 14, 1999. An Early Bird Discount on booth fees is available to those who register and pay by December 18, 1998. For registration information, please see our web site at http://www.connectathon.org. If you have any questions, please feel free to contact Audrey Van Belleghem at audrey@vanb.com or (408) 358-9598. We look forward to seeing you at the 13th annual Connectathon event! Audrey Van Belleghem Connectathon Manager >----------------End Forwarded Message----------------< From owner-ietf-ldup Mon Nov 16 10:58:52 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA19941 for ietf-ldup-bks; Mon, 16 Nov 1998 10:58:52 -0800 (PST) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA19937 for ; Mon, 16 Nov 1998 10:58:51 -0800 (PST) Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id LAA28416 for ; Mon, 16 Nov 1998 11:02:02 -0800 (PST) Received: from netscape.com ([208.12.63.182]) by tintin.mcom.com (Netscape Messaging Server 4.0) with ESMTP id F2J3JE00.RKU for ; Mon, 16 Nov 1998 11:02:02 -0800 Message-ID: <36507638.D5DA41D@netscape.com> Date: Mon, 16 Nov 1998 11:00:08 -0800 From: merrells@netscape.com (John Merrells) Organization: Netscape Communications X-Mailer: Mozilla 4.5 [en]C-NSCP (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: LDUP Subject: LDUP Meeting Date & Time? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk I was just wondering when the LDUP meeting will be. I'd like to get my tickets booked this week. John From owner-ietf-ldup Mon Nov 16 16:39:45 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA22605 for ietf-ldup-bks; Mon, 16 Nov 1998 16:39:45 -0800 (PST) Received: from ntg.cisco.com (ntg.cisco.com [171.71.15.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA22601 for ; Mon, 16 Nov 1998 16:39:44 -0800 (PST) Received: from jstrassn-pc ([171.69.237.193]) by ntg.cisco.com (8.8.4-Cisco.1/8.6.5) with SMTP id QAA14495; Mon, 16 Nov 1998 16:42:30 -0800 (PST) Message-Id: <3.0.2.32.19981116164230.00aa0a50@ntg.cisco.com> X-Sender: jstrassn@ntg.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Mon, 16 Nov 1998 16:42:30 -0800 To: merrells@netscape.com (John Merrells), LDUP From: "John C. Strassner" Subject: Re: LDUP Meeting Date & Time? In-Reply-To: <36507638.D5DA41D@netscape.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@imc.org Precedence: bulk Two dates have been proposed - Tuesday, Session II and Wednesday, Session II, though it has not been finalized yet. I'd also like to start getting feedback on the agenda. Please send in your suggestions soon! regards, John At 11:00 AM 11/16/98 -0800, John Merrells wrote: > >I was just wondering when the LDUP meeting will be. >I'd like to get my tickets booked this week. > >John > > From owner-ietf-ldup Mon Nov 16 20:15:53 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA24100 for ietf-ldup-bks; Mon, 16 Nov 1998 20:15:53 -0800 (PST) Received: from inet16.us.oracle.com (inet16.us.oracle.com [192.86.155.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA24096 for ; Mon, 16 Nov 1998 20:15:52 -0800 (PST) Received: from mailsun3 (mailsun3-fddi.us.oracle.com [144.25.88.135]) by inet16.us.oracle.com (8.8.5/8.8.5) with SMTP id UAA15923; Mon, 16 Nov 1998 20:20:17 -0800 (PST) Received: from oracle.com by mailsun3 with ESMTP (SMI-8.6/37.9) id UAA21889; Mon, 16 Nov 1998 20:19:38 -0800 Message-ID: <3650F8DE.CF3C6315@oracle.com> Date: Mon, 16 Nov 1998 20:17:35 -0800 From: Uppili Srinivasan X-Mailer: Mozilla 4.06 [en] (WinNT; U) MIME-Version: 1.0 To: "John C. Strassner" CC: ietf-ldup@imc.org Subject: Re: LDUP Meeting Date & Time? References: <3.0.2.32.19981116164230.00aa0a50@ntg.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk Could you and Tim please coordinate this and have the two events on the same day? That will be the most convenient. Thanks! John C. Strassner wrote: > Two dates have been proposed - Tuesday, Session II and Wednesday, Session > II, though it has not been finalized yet. > > I'd also like to start getting feedback on the agenda. Please send in your > suggestions soon! > > regards, > John > > At 11:00 AM 11/16/98 -0800, John Merrells wrote: > > > >I was just wondering when the LDUP meeting will be. > >I'd like to get my tickets booked this week. > > > >John > > > > From owner-ietf-ldup Mon Nov 16 21:28:41 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA25515 for ietf-ldup-bks; Mon, 16 Nov 1998 21:28:41 -0800 (PST) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA25510 for ; Mon, 16 Nov 1998 21:28:40 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id VAA20759 for ; Mon, 16 Nov 1998 21:29:37 -0800 (PST) Received: from netscape.com ([206.222.244.146]) by dredd.mcom.com (Netscape Messaging Server 4.0) with ESMTP id F2JWLB00.7AX; Mon, 16 Nov 1998 21:29:35 -0800 Message-ID: <365109BB.1F2947F9@netscape.com> Date: Mon, 16 Nov 1998 21:29:31 -0800 From: Tim Howes X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Uppili Srinivasan CC: "John C. Strassner" , ietf-ldup@imc.org Subject: Re: LDUP Meeting Date & Time? References: <3.0.2.32.19981116164230.00aa0a50@ntg.cisco.com> <3650F8DE.CF3C6315@oracle.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk LDAPEXT is Wednesday, I believe. Aren't Tuesday slots only one hour each? Seems like Wednesday would be better all around. -- Tim Uppili Srinivasan wrote: > > Could you and Tim please coordinate this and have the two events on the same > day? That will be the most convenient. > > Thanks! > > John C. Strassner wrote: > > > Two dates have been proposed - Tuesday, Session II and Wednesday, Session > > II, though it has not been finalized yet. > > > > I'd also like to start getting feedback on the agenda. Please send in your > > suggestions soon! > > > > regards, > > John > > > > At 11:00 AM 11/16/98 -0800, John Merrells wrote: > > > > > >I was just wondering when the LDUP meeting will be. > > >I'd like to get my tickets booked this week. > > > > > >John > > > > > > From owner-ietf-ldup Tue Nov 17 08:18:51 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA01092 for ietf-ldup-bks; Tue, 17 Nov 1998 08:18:51 -0800 (PST) Received: from orm-mail20.provo.novell.com (orm-mail20.orem.novell.com [151.155.118.32]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA01088 for ; Tue, 17 Nov 1998 08:18:50 -0800 (PST) Received: from INET-ORM-Message_Server by orm-mail20.provo.novell.com with Novell_GroupWise; Tue, 17 Nov 1998 09:22:01 -0700 Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Tue, 17 Nov 1998 09:21:52 -0700 From: "Sukanta Ganguly" To: , Cc: , Subject: Re: LDUP Meeting Date & Time? 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 mail.proper.com id IAA01089 Sender: owner-ietf-ldup@imc.org Precedence: bulk So will it be Wednesday then ? We can go and get our tickets booked based on it. Sukanta Ganguly >>> Tim Howes 11/16/98 10:29PM >>> LDAPEXT is Wednesday, I believe. Aren't Tuesday slots only one hour each? Seems like Wednesday would be better all around. -- Tim Uppili Srinivasan wrote: > > Could you and Tim please coordinate this and have the two events on the same > day? That will be the most convenient. > > Thanks! > > John C. Strassner wrote: > > > Two dates have been proposed - Tuesday, Session II and Wednesday, Session > > II, though it has not been finalized yet. > > > > I'd also like to start getting feedback on the agenda. Please send in your > > suggestions soon! > > > > regards, > > John > > > > At 11:00 AM 11/16/98 -0800, John Merrells wrote: > > > > > >I was just wondering when the LDUP meeting will be. > > >I'd like to get my tickets booked this week. > > > > > >John > > > > > > From owner-ietf-ldup Tue Nov 17 08:42:25 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA01255 for ietf-ldup-bks; Tue, 17 Nov 1998 08:42:25 -0800 (PST) Received: from ntg.cisco.com (ntg.cisco.com [171.71.15.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA01251 for ; Tue, 17 Nov 1998 08:42:24 -0800 (PST) Received: from jstrassn-pc (sj-dial-1-32.cisco.com [171.68.180.33]) by ntg.cisco.com (8.8.4-Cisco.1/8.6.5) with SMTP id IAA06038; Tue, 17 Nov 1998 08:45:08 -0800 (PST) Message-Id: <3.0.2.32.19981117084507.00a9f210@ntg.cisco.com> X-Sender: jstrassn@ntg.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Tue, 17 Nov 1998 08:45:07 -0800 To: "Sukanta Ganguly" , , From: "John C. Strassner" Subject: Re: LDUP Meeting Date & Time? Cc: , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@imc.org Precedence: bulk I'll pass on the request to The Powers That Are. regards, John At 09:21 AM 11/17/98 -0700, Sukanta Ganguly wrote: >So will it be Wednesday then ? We can go and get our tickets booked based on it. > >Sukanta Ganguly > >>>> Tim Howes 11/16/98 10:29PM >>> >LDAPEXT is Wednesday, I believe. Aren't Tuesday slots >only one hour each? Seems like Wednesday would be better >all around. -- Tim > >Uppili Srinivasan wrote: >> >> Could you and Tim please coordinate this and have the two events on the same >> day? That will be the most convenient. >> >> Thanks! >> >> John C. Strassner wrote: >> >> > Two dates have been proposed - Tuesday, Session II and Wednesday, Session >> > II, though it has not been finalized yet. >> > >> > I'd also like to start getting feedback on the agenda. Please send in your >> > suggestions soon! >> > >> > regards, >> > John >> > >> > At 11:00 AM 11/16/98 -0800, John Merrells wrote: >> > > >> > >I was just wondering when the LDUP meeting will be. >> > >I'd like to get my tickets booked this week. >> > > >> > >John >> > > >> > > > > > From owner-ietf-ldup Thu Nov 19 22:38:11 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA15041 for ietf-ldup-bks; Thu, 19 Nov 1998 22:38:11 -0800 (PST) Received: from Wind.Stanford.EDU (wind.Stanford.EDU [171.64.20.170]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA15030 for ; Thu, 19 Nov 1998 22:38:09 -0800 (PST) Received: from localhost (hodges@localhost) by Wind.Stanford.EDU (8.8.3/8.8.3) with ESMTP id WAA24339; Thu, 19 Nov 1998 22:42:12 -0800 (PST) Message-Id: <199811200642.WAA24339@Wind.Stanford.EDU> X-Mailer: exmh version 2.0.2 2/24/98 Subject: Re: LDUP Meeting Date & Time? To: ietf-ldup@imc.org cc: "John C. Strassner" , howes@netscape.com Reply-to: ietf-ldup@imc.org From: Jeff.Hodges@Stanford.EDU X-Office: Pine Hall Rm 161; +1-650-723-2452 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 19 Nov 1998 22:42:12 -0800 Sender: owner-ietf-ldup@imc.org Precedence: bulk I note that PKIX is scheduled for Wed 1300-1500. There's several LDAPers that also attend that WG these days, so hopefully ldapext and ldup won't collide with it. thanks, Jeff From owner-ietf-ldup Fri Nov 20 07:32:08 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA10024 for ietf-ldup-bks; Fri, 20 Nov 1998 07:32:08 -0800 (PST) Received: from orm-mail20.provo.novell.com (orm-mail20.orem.novell.com [151.155.118.32]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA10020 for ; Fri, 20 Nov 1998 07:32:07 -0800 (PST) Received: from INET-ORM-Message_Server by orm-mail20.provo.novell.com with Novell_GroupWise; Fri, 20 Nov 1998 08:35:31 -0700 Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Fri, 20 Nov 1998 08:35:23 -0700 From: "Ed Reed" To: , Cc: , Subject: Re: LDUP Meeting Date & Time? 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 mail.proper.com id HAA10021 Sender: owner-ietf-ldup@imc.org Precedence: bulk ..like it did last time... ---------------------- Ed Reed, Technologist Novell, Inc. +1 801 861-3320 >>> 11/19/1998 23:42:12 >>> I note that PKIX is scheduled for Wed 1300-1500. There's several LDAPers that also attend that WG these days, so hopefully ldapext and ldup won't collide with it. thanks, Jeff From owner-ietf-ldup Fri Nov 20 07:32:02 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA10019 for ietf-ldup-bks; Fri, 20 Nov 1998 07:32:02 -0800 (PST) Received: from prv-mail25.provo.novell.com (prv-mail25.Provo.Novell.COM [137.65.40.3]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA10015 for ; Fri, 20 Nov 1998 07:32:01 -0800 (PST) Received: from INET-PRV1-Message_Server by prv-mail25.provo.novell.com with Novell_GroupWise; Fri, 20 Nov 1998 08:35:36 -0700 Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Fri, 20 Nov 1998 08:35:23 -0700 From: "Ed Reed" To: , Cc: "John C. Strassner" , Subject: Re: LDUP Meeting Date & Time? 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 mail.proper.com id HAA10016 Sender: owner-ietf-ldup@imc.org Precedence: bulk ..like it did last time... ---------------------- Ed Reed, Technologist Novell, Inc. +1 801 861-3320 >>> 11/19/1998 23:42:12 >>> I note that PKIX is scheduled for Wed 1300-1500. There's several LDAPers that also attend that WG these days, so hopefully ldapext and ldup won't collide with it. thanks, Jeff From owner-ietf-ldup Fri Nov 20 08:05:20 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA10358 for ietf-ldup-bks; Fri, 20 Nov 1998 08:05:20 -0800 (PST) Received: from fl.dk (ns.fl.dk [193.88.152.147]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA10354 for ; Fri, 20 Nov 1998 08:05:18 -0800 (PST) Received: by gw.fl.dk id <26896-2>; Fri, 20 Nov 1998 18:06:33 +0100 Message-Id: <98Nov20.180633gmt+0100.26896-2@gw.fl.dk> From: Erik Andersen To: "'LDUP'" Subject: RE: Status of LDIF and Changelog? Date: Fri, 20 Nov 1998 17:12:11 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-ietf-ldup@imc.org Precedence: bulk Thre has been some discussions on the status of LDIF resently on this mailing list started by the attached note from Keith Richardson from ICL. Some while ago I put onto the server a proposal for an extended LDIF (draft-andersen-isss-ws-dir-ldifext-00.txt). Very few have commented on this proposal and I am now in doubt on how the progress the work, as the proposed format will be used in Denmark, and probably in UK, for telephone number exchange among service provider and to third parties. One posiblity is to progress it through IETF-LDUP, and I would like an reaction to this. Compared to the basic LDIF it has the following characteristics: 1. It does not assume that a single system is the master for all information about a particular object. It is based on much the same philosophy as the "Related Entry" work item being progressed within ISO/IEC and ITU-T. 2. It does not assume that it is possible always to assign distinguished names that are agreed across systems. 3. It does not assume that a participating system is a standard directory system, but can be a database system. 4. It allows minimum amount of data to be transferred, which is essential when transmitting a file consisting of millions or records. Each extra byte per record adds up to several Mbytes. 5. It can use other character sets than UTF8. This is esential in non-English speaking countries wanting to transmit national characters in single bytes. The extended LDIF is compatible with LDIF in the sense that by using it in a defined way, it produces a basic LDIF stream. Erik Andersen, Consultant, Direct Tel. (+45) 3945 0736, Mobile: (+45) 2097 1490 E-mail: era@fl.dk FISCHER & LORENZ A/S Tuborg Parkvej 10, DK-2900 Hellerup, Copenhagen, Denmark Tel. (+45) 3945 0700, Fax (+45) 3945 0777, E-mail: fl@fl.dk, Internet: http://www.fl.dk CEN/ISSS Directory Workshop chairman, Internet: http://www.cenorm.be/isss/Workshop/DIR/Default.htm > -----Original Message----- > From: Richardson K [SMTP:k.richardson@man05t1.wins.icl.co.uk] > Sent: 13. november 1998 11:06 > To: ERA@FL.DK > Subject: Status of LDIF and Changelog? > > Hi, > I have some general LDIF-related questions. The current LDIF > technical specification (draft-good-ldap-ldif-01.txt) is now an > individual contribution although it was previously an ASID work > item. Presumably this is now destined to be an informational RFC? > If so, shouldn't we be considering giving LDIF a more formal > status than this? All of the LDAP servers I know support LDIF to > some degree and it seems to me that it would better if the > format used to import/export and apply changes to different > servers was an agreed standard - interoperability between servers > goes beyond the basic protocol level. > I guess if the LDIF status were to reviewed then the LDIF > extensions needed to meet certain country's legal/regulatory > directory requirements (draft-andersen-isss-ws-dir-ldifext-00.txt) > would also need to be considered - possibly for optional > implementation on top of a "standard" LDIF? > Also, the changelog draft (draft-good-ldap-changelog-00.txt) > which exploits LDIF expired on October 1st. Is a new draft planned > or is the changelog proposal now considered to be superseded by the > planned LDUP replication mechanisms? > > Keith Richardson > ICL, Manchester, UK From owner-ietf-ldup Fri Nov 27 07:27:46 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA08856 for ietf-ldup-bks; Fri, 27 Nov 1998 07:27:46 -0800 (PST) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA08852 for ; Fri, 27 Nov 1998 07:27:45 -0800 (PST) From: Mike_Spreitzer.PARC@xerox.com Received: from dmsms2.OSBU_North.Xerox.xns by alpha.xerox.com via XNS id <52148(1)>; Fri, 27 Nov 1998 07:32:21 PST X-NS-Transport-ID: 0800201FCE5D39B4192E Date: Fri, 27 Nov 1998 07:32:06 PST Subject: hello To: ietf-ldup@imc.org cc: Mike_Spreitzer.PARC@xerox.com Message-Id: <98Nov27.073221pst."52148(1)"@alpha.xerox.com> Sender: owner-ietf-ldup@imc.org Precedence: bulk Hi. I'm interested in this WG. I work at Xerox PARC, and am one of the Bayou team. I'll be at IETF-43. Looking forward to meeting you folks. Mike From owner-ietf-ldup Fri Dec 4 13:03:20 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA15732 for ietf-ldup-bks; Fri, 4 Dec 1998 13:03:20 -0800 (PST) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA15728 for ; Fri, 4 Dec 1998 13:03:20 -0800 (PST) Received: from dmsms2.OSBU_North.Xerox.xns by alpha.xerox.com via XNS id <55359(4)>; Fri, 4 Dec 1998 13:08:34 PST X-NS-Transport-ID: 0800201FCE5D39B41A16 Date: Fri, 4 Dec 1998 13:08:16 PST From: Terry.PARC@xerox.com Subject: comments on the LDAP Replication Architecture document To: ietf-ldup@imc.org cc: Terry.PARC@xerox.com Message-Id: <98Dec4.130834pst."55359(4)"@alpha.xerox.com> Sender: owner-ietf-ldup@imc.org Precedence: bulk Hi all, I carefully read the "LDAP Replication Architecture" document dated August 5 and then today read quickly the newer version dated November 18, 1998. In general, the document looks great. The proposed architecture appears to be sound. Some specific comments on the document are included below. Unfortunately, I haven't had time to follow the e-mail discussions. So my comments may point out issues that have already been raised by others or may be out-dated. Hopefully you'll find them at least somewhat useful. I wanted to send them out before next week's IETF meeting, which I'm unable to attend. I'll be happy to clarify any of my comments... ... Doug Terry ---------- Although the document mentions "conflicts", it does not actually define what it means for two updates to conflict. I assume that any concurrent updates to the same attribute value are considered conflicting. Two updates are concurrent if they are accepted by different replicas and, at the time of acceptance, the accepting replica had not yet seen the other update. It wouldn't hurt to say this explicitly in the document. If some other definition of conflict is intended, then the document should definitely state what it is. In a number of places, the document suggests that change sequence numbers (CSNs) are needed to detect and resolve conflicts. Actually, CSNs cannot detect conflicts. CSNs can be used to totally order updates, thereby resolving any conflicting updates, but they cannot detect whether two updates are concurrent. You need more information, like version vectors or dependency sets, to detect concurrent updates. For LDAP replication, you might not care about detecting conflicts, only resolving them. It depends on your requirements. The statement in section 4.7 "If ... a server consistently produces timestamps which are significantly older than those of other servers, its updates will not have effect" needs further explanation. Is it that *all* of its updates will have no effect or simply that any concurrent updates it introduces will lose according to the "last timestamp wins" conflict resolution mechanism? The former would only be true, i.e. a non-conflicting update would be lost, if the server created a CSN for an update that is earlier than the modification CSN that is already on the attribute being updated. This would be a silly thing to do. Section 5.1.1 suggests that "applications that require strong consistency should direct their LDAP operations" to the primary. The only way to get strong consistency, without atomically updating multiple replicas, is to have *every* application update the primary. If some applications, i.e. those that do not require strong consistency, are allowed to update non-primary replicas, then no applications can get strong consistency since the primary does not always have the most up-to-date data. Do CSNs really need to include a change count? I understand that more than one update could be done within a second. But the real issue is whether the sustained update rate is going to exceed one per second. If not, then why not do away with the change count and simply ensure that the timestamp (in seconds) is bumped by at least one for each update. That is, if bursty updates occur, then the CSN will use timestamps from the future for a little while. Eliminating change counts could simplify the servers and reduce the size of each CSN. Section 5.5.1 states that "Names of deleted entries are available for reuse by new entries immediately". I presume that the new entry should have a CSN that is greater than that of the old entry. If so, this should be stated explicitly. The whole point of the createdEntryCSN and deletedEntryCSN, apparently, is to avoid the create/delete ambiguity. The document should explicitly say what happens during update propagation when an entry is deleted and its name reused. There are lots of cases (one replica has a createdEntryCSN and the other doesn't, one replica has a deletedEntryCSN and the other has only a createdEntryCSN, the two replicas have different createdEntryCSNs, etc.); what should happen in each of these cases should be discussed. This relates, of course, to the conditions for deleting an entry discussed in section 5.7.1. I found section 5.6 to be a bit confusing. The statement "The server must reject LDAP client update operations with a CSN that is older ..." could imply that clients generate the CSNs for updates that they issue. If servers generate CSNs, as is stated in section 10, then why would a server ever return a "serverClockOutOfSync" result to the client? And what is the client expected to do with this result? Section 10 implies that "serverClockOutOfSync" is also returned to a supplier during a replication session if it rejects an update operation because it has an old CSN. But conflicting updates can occur, and will cause some updates with earlier CSNs to be rejected, even if server clocks are synchronized. So, detecting that server clocks are out of sync requires something more than simply comparing CSNs on updated entries. In section 5.7, I assume that "state information that is no longer required" are CSNs for deleted entries, though this is not explicitly stated. Why is the mechanism for purging this information "implementation-dependent"? My experience is that purging deleted entries in a way that they don't later spring back to life is tricky. The mechanism for doing this should be well-reasoned and standardized so that all servers get it right. One incorrect implementation can mess up the whole system. Section 6.1.6 on update vectors says that "CSNs for Read-Only replicas might be absent". Why wouldn't they always be absent? That is, why would a read-only replica ever need to be included in the update vector? If the issue is that an updateable replica can change to be read-only, then say that. Also, it would be nice if this section stated the conditions under which a retired replica can be removed from the update vector; again, this is tricky. Section 8.4 states that the supplier sends its update vector to the consumer. Why can't the consumer compute this for himself based on the updates it has received? Does this imply that if the network connection fails in the middle of a replication session then the consumer needs to discard any updates it received? Is there some proposal for how replica IDs are assigned? I'll be interested to see how "Sparse Replicas" are specified and maintained. In Bayou, we tried to design a scheme by which partial replicas could be defined as arbitrary queries over the data. This turned out to be quite complicated. From owner-ietf-ldup Fri Dec 4 13:16:46 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA15804 for ietf-ldup-bks; Fri, 4 Dec 1998 13:16:46 -0800 (PST) Received: from orm-mail20.provo.novell.com (orm-mail20.orem.novell.com [151.155.118.32]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA15800 for ; Fri, 4 Dec 1998 13:16:42 -0800 (PST) Received: from INET-ORM-Message_Server by orm-mail20.provo.novell.com with Novell_GroupWise; Fri, 04 Dec 1998 14:21:24 -0700 Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Fri, 04 Dec 1998 14:21:14 -0700 From: "Sukanta Ganguly" To: Cc: Subject: Re: comments on the LDAP Replication Architecture document 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 mail.proper.com id NAA15801 Sender: owner-ietf-ldup@imc.org Precedence: bulk Could somebody point me to the newer version of the LDAP Replication Achitecture, dated Nov 18, 1998 ! Thanks Sukanta Ganguly >>> 12/04/98 02:08PM >>> Hi all, I carefully read the "LDAP Replication Architecture" document dated August 5 and then today read quickly the newer version dated November 18, 1998. In general, the document looks great. The proposed architecture appears to be sound. Some specific comments on the document are included below. Unfortunately, I haven't had time to follow the e-mail discussions. So my comments may point out issues that have already been raised by others or may be out-dated. Hopefully you'll find them at least somewhat useful. I wanted to send them out before next week's IETF meeting, which I'm unable to attend. I'll be happy to clarify any of my comments... .. Doug Terry ---------- Although the document mentions "conflicts", it does not actually define what it means for two updates to conflict. I assume that any concurrent updates to the same attribute value are considered conflicting. Two updates are concurrent if they are accepted by different replicas and, at the time of acceptance, the accepting replica had not yet seen the other update. It wouldn't hurt to say this explicitly in the document. If some other definition of conflict is intended, then the document should definitely state what it is. In a number of places, the document suggests that change sequence numbers (CSNs) are needed to detect and resolve conflicts. Actually, CSNs cannot detect conflicts. CSNs can be used to totally order updates, thereby resolving any conflicting updates, but they cannot detect whether two updates are concurrent. You need more information, like version vectors or dependency sets, to detect concurrent updates. For LDAP replication, you might not care about detecting conflicts, only resolving them. It depends on your requirements. The statement in section 4.7 "If ... a server consistently produces timestamps which are significantly older than those of other servers, its updates will not have effect" needs further explanation. Is it that *all* of its updates will have no effect or simply that any concurrent updates it introduces will lose according to the "last timestamp wins" conflict resolution mechanism? The former would only be true, i.e. a non-conflicting update would be lost, if the server created a CSN for an update that is earlier than the modification CSN that is already on the attribute being updated. This would be a silly thing to do. Section 5.1.1 suggests that "applications that require strong consistency should direct their LDAP operations" to the primary. The only way to get strong consistency, without atomically updating multiple replicas, is to have *every* application update the primary. If some applications, i.e. those that do not require strong consistency, are allowed to update non-primary replicas, then no applications can get strong consistency since the primary does not always have the most up-to-date data. Do CSNs really need to include a change count? I understand that more than one update could be done within a second. But the real issue is whether the sustained update rate is going to exceed one per second. If not, then why not do away with the change count and simply ensure that the timestamp (in seconds) is bumped by at least one for each update. That is, if bursty updates occur, then the CSN will use timestamps from the future for a little while. Eliminating change counts could simplify the servers and reduce the size of each CSN. Section 5.5.1 states that "Names of deleted entries are available for reuse by new entries immediately". I presume that the new entry should have a CSN that is greater than that of the old entry. If so, this should be stated explicitly. The whole point of the createdEntryCSN and deletedEntryCSN, apparently, is to avoid the create/delete ambiguity. The document should explicitly say what happens during update propagation when an entry is deleted and its name reused. There are lots of cases (one replica has a createdEntryCSN and the other doesn't, one replica has a deletedEntryCSN and the other has only a createdEntryCSN, the two replicas have different createdEntryCSNs, etc.); what should happen in each of these cases should be discussed. This relates, of course, to the conditions for deleting an entry discussed in section 5.7.1. I found section 5.6 to be a bit confusing. The statement "The server must reject LDAP client update operations with a CSN that is older ..." could imply that clients generate the CSNs for updates that they issue. If servers generate CSNs, as is stated in section 10, then why would a server ever return a "serverClockOutOfSync" result to the client? And what is the client expected to do with this result? Section 10 implies that "serverClockOutOfSync" is also returned to a supplier during a replication session if it rejects an update operation because it has an old CSN. But conflicting updates can occur, and will cause some updates with earlier CSNs to be rejected, even if server clocks are synchronized. So, detecting that server clocks are out of sync requires something more than simply comparing CSNs on updated entries. In section 5.7, I assume that "state information that is no longer required" are CSNs for deleted entries, though this is not explicitly stated. Why is the mechanism for purging this information "implementation-dependent"? My experience is that purging deleted entries in a way that they don't later spring back to life is tricky. The mechanism for doing this should be well-reasoned and standardized so that all servers get it right. One incorrect implementation can mess up the whole system. Section 6.1.6 on update vectors says that "CSNs for Read-Only replicas might be absent". Why wouldn't they always be absent? That is, why would a read-only replica ever need to be included in the update vector? If the issue is that an updateable replica can change to be read-only, then say that. Also, it would be nice if this section stated the conditions under which a retired replica can be removed from the update vector; again, this is tricky. Section 8.4 states that the supplier sends its update vector to the consumer. Why can't the consumer compute this for himself based on the updates it has received? Does this imply that if the network connection fails in the middle of a replication session then the consumer needs to discard any updates it received? Is there some proposal for how replica IDs are assigned? I'll be interested to see how "Sparse Replicas" are specified and maintained. In Bayou, we tried to design a scheme by which partial replicas could be defined as arbitrary queries over the data. This turned out to be quite complicated. From owner-ietf-ldup Fri Dec 4 15:07:02 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA16592 for ietf-ldup-bks; Fri, 4 Dec 1998 15:07:02 -0800 (PST) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA16588 for ; Fri, 4 Dec 1998 15:07:01 -0800 (PST) Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id PAA20309 for ; Fri, 4 Dec 1998 15:11:44 -0800 (PST) Received: from netscape.com ([208.12.63.200]) by tintin.mcom.com (Netscape Messaging Server 4.0) with ESMTP id F3GR3K00.4RH; Fri, 4 Dec 1998 15:11:44 -0800 Message-ID: <36686B6B.3591E1E3@netscape.com> Date: Fri, 04 Dec 1998 15:08:28 -0800 From: merrells@netscape.com (John Merrells) X-Mailer: Mozilla 4.5 [en]C-NSCP (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Terry.PARC@xerox.com CC: ietf-ldup@imc.org Subject: Re: comments on the LDAP Replication Architecture document References: <98Dec1.121244pst."55036(1)"@alpha.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk Thanks for your comments Terry. My responses are interleaved below. Terry.PARC@xerox.com wrote: > Although the document mentions "conflicts", it does not actually define what it > means for two updates to conflict. I assume that any concurrent updates to the > same attribute value are considered conflicting. Two updates are concurrent if > they are accepted by different replicas and, at the time of acceptance, the > accepting replica had not yet seen the other update. It wouldn't hurt to say > this explicitly in the document. If some other definition of conflict is > intended, then the document should definitely state what it is. The next revision of the document will include a clearer statement of what a conflict is. > In a number of places, the document suggests that change sequence numbers > (CSNs) are needed to detect and resolve conflicts. Actually, CSNs cannot > detect conflicts. CSNs can be used to totally order updates, thereby resolving > any conflicting updates, but they cannot detect whether two updates are > concurrent. You need more information, like version vectors or dependency > sets, to detect concurrent updates. For LDAP replication, you might not care > about detecting conflicts, only resolving them. It depends on your > requirements. I've added a small section to the draft to make it clear that the CSNs provide a total ordering. Could you elaborate on what a 'dependency set' is? > The statement in section 4.7 "If ... a server consistently produces timestamps > which are significantly older than those of other servers, its updates will not > have effect" needs further explanation. Is it that *all* of its updates will > have no effect or simply that any concurrent updates it introduces will lose > according to the "last timestamp wins" conflict resolution mechanism? The > former would only be true, i.e. a non-conflicting update would be lost, if the > server created a CSN for an update that is earlier than the modification CSN > that is already on the attribute being updated. This would be a silly thing to > do. What's the alternative? I guess it's to generate a CSN that is newer than the modification CSN already on the target attribute. This would have to be achieved by pushing forward the time on the replica. > Section 5.1 suggests that "applications that require strong consistency should > direct their LDAP operations" to the primary. The only way to get strong > consistency, without atomically updating multiple replicas, is to have *every* > application update the primary. If some applications, i.e. those that do not > require strong consistency, are allowed to update non-primary replicas, then no > applications can get strong consistency since the primary does not always have > the most up-to-date data. Yes, I think we should define this more accurately. How about... "All applications that make exclusive use of a set of entries and attributes must direct all their operations to the Primary." > Do CSNs really need to include a change count? I understand that more than one > update could be done within a second. But the real issue is whether the > sustained update rate is going to exceed one per second. If not, then why not > do away with the change count and simply ensure that the timestamp (in seconds) > is bumped by at least one for each update. That is, if bursty updates occur, > then the CSN will use timestamps from the future for a little while. > Eliminating change counts could simplify the servers and reduce the size of > each CSN. The update rate will be >1 per second. In our experience our customers are writing directory enabled applications that generate considerable write traffic. Large extranet deployments can require upto 50 updates per second, and the more compelling the applications they publishing on the net, and the more personalisation opportunities they provide, the greater the update rate they will require. I'm certain that the change count is a requirement. > Section 5.4.1 states that "Names of deleted entries are available for reuse by > new entries immediately". I presume that the new entry should have a CSN that > is greater than that of the old entry. If so, this should be stated > explicitly. The whole point of the createdEntryCSN and deletedEntryCSN, > apparently, is to avoid the create/delete ambiguity. The document should > explicitly say what happens during update propagation when an entry is deleted > and its name reused. There are lots of cases (one replica has a > createdEntryCSN and the other doesn't, one replica has a deletedEntryCSN and > the other has only a createdEntryCSN, the two replicas have different > createdEntryCSNs, etc.); what should happen in each of these cases should be > discussed. This relates, of course, to the conditions for deleting an entry > discussed in section 5.6.1. I'm expecting the additional CD&R document to fully describe these cases. > I found section 5.5 to be a bit confusing. The statement "The server must > reject LDAP client update operations with a CSN that is older ..." could imply > that clients generate the CSNs for updates that they issue. If servers > generate CSNs, as is stated in section 10, then why would a server ever return > a "serverClockOutOfSync" result to the client? And what is the client expected > to do with this result? > > Section 10 implies that "serverClockOutOfSync" is also returned to a supplier > during a replication session if it rejects an update operation because it has > an old CSN. But conflicting updates can occur, and will cause some updates > with earlier CSNs to be rejected, even if server clocks are synchronized. So, > detecting that server clocks are out of sync requires something more than > simply comparing CSNs on updated entries. Correct, this statement about detecting when another server has regressed in time is bogus. I'm not sure how it would ever be possible to determine of one's peer were too far behind or forward in time. It might possible to determine if it has regressed if we've seen newer CSNs from that replica before. Clearly the discussion on Time needs more work. > In section 5.6, I assume that "state information that is no longer required" > are CSNs for deleted entries, though this is not explicitly stated. Why is the > mechanism for purging this information "implementation-dependent"? My > experience is that purging deleted entries in a way that they don't later > spring back to life is tricky. The mechanism for doing this should be > well-reasoned and standardized so that all servers get it right. One incorrect > implementation can mess up the whole system. The state information is also the CSNs on all the attribute values. These can also be purged. Saying that the mechanism is implementation dependent is a redundant thing to say.... What I was trying to get at was that we don't care how it's done, just that it's not done too soon. There's a Purging section that attempts to define the point at which purging should stop. > Section 6.1.5 on update vectors says that "CSNs for Read-Only replicas might be > absent". Why wouldn't they always be absent? That is, why would a read-only > replica ever need to be included in the update vector? If the issue is that an > updateable replica can change to be read-only, then say that. Also, it would > be nice if this section stated the conditions under which a retired replica can > be removed from the update vector; again, this is tricky. The 18th Nov draft improves the description here. I was unable to define how update vectors may be trimmed... I suspected there was a way of defining this by attaching CSNs to the elements of the update vector itself... but couldn't convince myself this was totally correct. > Sections 8.3.1 and 8.3.2 state that the supplier sends its update vector to the > consumer. Why can't the consumer compute this for himself based on the updates > it has received? Does this imply that if the network connection fails in the > middle of a replication session then the consumer needs to discard any updates > it received? When a replication session fails the consumer may either update the vector to its present state, or may leave its vector as before. An implementation could break the usually atomic ldap operations into pieces to optimise the amount of network traffic required to update the replica. This is one of the differences between the changelog based and state based replication schemes. I've been thinking that there should be a flag on the start replication control to define how the consumer should behave. > Is there some proposal for how replica IDs are assigned? The latest draft defines the replica ID as being the RDN of the replication agreement. It is suggested that these be short... or some local optimisation could occur to translate them into small integers. > I'll be interested to see how "Sparse Replicas" are specified and maintained. > In Bayou, we tried to design a scheme by which partial replicas could be > defined as arbitrary queries over the data. This turned out to be quite > complicated. Yes, Sparse replicas have proved to be very troublesome. We've decided to try to constrain the problem by defining that they may only be read-only. I'd be glad to discuss all of the points you've raised further. Thanks John From owner-ietf-ldup Wed Dec 9 18:09:28 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA01871 for ietf-ldup-bks; Wed, 9 Dec 1998 18:09:28 -0800 (PST) Received: from nsm-mail2.cisco.com (nsm-mail2.cisco.com [171.71.15.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA01867 for ; Wed, 9 Dec 1998 18:09:27 -0800 (PST) Received: from jstrassn-pc.cisco.com (rtp-dial-2-197.cisco.com [171.70.158.197]) by nsm-mail2.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id SAA21759 for ; Wed, 9 Dec 1998 18:14:22 -0800 (PST) Message-ID: <01f201be23e2$e48ed6e0$339e46ab@jstrassn-pc.cisco.com> Reply-To: "John Strassner" From: "John Strassner" To: Subject: attached please find the second revision of the ldup requirements doc Date: Wed, 9 Dec 1998 18:14:59 -0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_01EF_01BE239F.D566AA00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-ldup@imc.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_01EF_01BE239F.D566AA00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit regards, John Strassner Co-chair, LDUP WG, IETF ------=_NextPart_000_01EF_01BE239F.D566AA00 Content-Type: text/plain; name="draft-weiser-replica-req-02.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-weiser-replica-req-02.txt" =20 INTERNET-DRAFT Russel Weiser Informational Draft Novell, Inc. Expires 29 October 1998 Ellen Stokes IBM=20 29 April 1998 LDAP Replication Requirements=20 =20 Status of this Memo This document is an Internet-Draft. 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 entire list of current Internet-Drafts, please check the 1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). =20 Abstract This document discusses the fundamental requirements for replication of data accessible via the LDAPv3 [RFC2251] protocol. It is intended to be a gathering place for general replication requirements needed to provide interoperability between informational directories. The key words MUST MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Weiser & Stokes 29 October 1998 [Page 1] =0C INTERNET-DRAFT LDAP V3 Replication Requirements 29 April 1998 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Applicability Statement . . . . . . . . . . . . . . . . . . . . . 5 5. Replication Model . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Replication Protocol . . . . . . . . . . . . . . . . . . . . . . . 7 7. Replication Predetermined Agreements . . . . . . . . . . . . . . . 8 8. Administration and Management Considerations . . . . . . . . . . . 8 9. Other for furhter discussion or the garbage heap . . . . . . . . . 9 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 12. Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 Weiser & Stokes 29 October 1998 [Page 2] =0C INTERNET-DRAFT LDAP V3 Replication Requirements 29 April 1998 1. Introduction The ability to distribute directory information throughout the network provides a two fold benefit to the network: (1) increasing the reliabililty of the directory through fault tolerance, and (2) brings the directory content closer to the clients using the data. LDAPs acceptance as a access protocol for directory information is driving the need to distribute LDAP directory content among servers within enterprise and Internet. Currently LDAP does not define a replication mechanism and only generally mentions LDAP shadow servers (see [RFC2251] and [Changelog]) in passing. The require- ments for replication are critical to the successful deployment and acceptance of LDAP in the market place. 2. Terminology=20 For the purposes of this document, the following definitions are used: Area of replication - A whole or portion of a directory tree making up a distinct unit of data to be replicated. =20 Authoritative Master Replica - The Primary read-writeable copy of the replicated information. Fractional replication - The capability to replicate a subset of attributes of any given entry.=20 Incremental Update - The process of updating a replica, or copy, of a naming context, by updating only those fields or objects which have changed. Master Slave, or Single Master Replication - Replication model that assumes only one server, the master, allows write access to the replicated data. Note that Master-Slave replication can be considered a proper subset of multi-master replication. Multi-Master Replication - A replication model where entries can be written and updated on any of several updateable replica copy without requiring communication with other updateable replicas before the write or update is performed.=20 Naming Context - Suffix of a Sub-tree. One-way Replication - The process of synchronization in a single direction where the authoritative source information is provided to a replica.=20 Read-only Replica - A read-only copy of the replicated information. Replica - An instance of a replicated directory. Weiser & Stokes 29 October 1998 [Page 3] =0C INTERNET-DRAFT LDAP V3 Replication Requirements 29 April 1998 Replication - The process of copying portions of naming context information and content, between multiple LDAP servers, such that certain, predefined portions of the information are available from different servers. that which is done between either homogeneous implementations across heterogeneous platforms (operating systems) or heterogeneous implementations supporting identical replication across heterogeneous platforms (operating systems). No mapping mechanisms are required here. Sparse Replica - A incomplete copy of a sub-tree which maybe inclusive with Updateable, or Read-only=20 Topology - as in the replicated directory toplogy . Refers to the shape of the directed graph describing the relationships between replicas.=20 Two-way Replication - The process of synchronization where change information may flow bidirectionally between two replicas.=20 Update Propagation - Protocol-based process by which directory replicas are reconciled.=20 Updateable Replica - A Non-authoritative read-writeable copy of the = replicated information=20 3. Objective The major objective is to provide an interoperable LDAP V3 directory synchronization protocol which is simple, highly efficient and flexible enough to support both Multi-master and Master-slave replication operations to meet the needs of both the Internet and enterprise environments. =20 4. Applicability Statement =20 Generally replication can be characterized by looking at data consistency models across existing technologies which provide insight to the possible functional coverage the LDAP v3 =20 replication requirements should provide support for. By categorizing the data consistency as follows:=20 Tight Consistency -- Includes environments where 2 phase commit transaction models may be used. Loose Consistency -- Includes X.500 Directories and NDS distal names Service where definite knowledge of the global replica topology is provided through predetermined replication agreements. = Weiser & Stokes 29 October 1998 [Page 4] =0C INTERNET-DRAFT LDAP V3 Replication Requirements 29 April 1998 Looser Consistency -- Includes Xerox Clearinghouse and Bayou which provides a statistical probability of convergence with no global knowledge of replica topology. =20 Loosest Consistency -- Includes opportunistic or simple cache where information is provided from the cache until stale.=20 Ad hoc -- A copy of a date store where now follow up checks are made for the accuracy/freshness of the data.=20 The later two of =91Ad Hoc=92 and =91Loosest Consistency=92 can be = looked as a unregistered replica where the client pulls the information from the data store without the data stores knowledge. Its also believed that these two are out of scope the LDUP replication.=20 The first three of these which provide replication in a registered means =91Predetermined Replication Agreements=92 using either a = push or pull access to the replica. So through further review of these consistency models three application areas can then be derived with even further characterizations of the data types usages. =20 Looser Loose Tight=20 White Pages Policy Configuration Enforcement ----------- -------------------- ----------- Very Static Data Security Management Params. Intrusion Policy Static Address Info Dynamic Data Dynamic addr Contracts = Message Attributes Dynamic Address Info Real-time State Info=20 Therefore it is believed an LDAP replication should be flexible enough to cover above range of capabilities =20 4.1 Replication Scenarios The following directory deployment examples are intended to substantiate and validate our replication requirements. It is assumed in all cases that directory implementations from different vendors are involved. 4.1.1 Extranet Example A company has a trading partner to whom it wishes to provide=20 directory information. This information may be as simple as a corporate telephone directory, or as complex as an extranet work flow application. For performance reasons the company may wish to have a replica of it's directory within the partner company, rather than simply exposed beyond its fire wall. Weiser & Stokes 29 October 1998 [Page 5] =0C INTERNET-DRAFT LDAP V3 Replication Requirements 29 April 1998 The requirements which follow from this scenario are: - One-way replication, single mastered. - Authentication of clients. - Secure transmission of updates. - Selective attribute replication, so that only partial entries =20 can be replicated. 4.1.2 Consolidation Example Company A acquires company B. In the transition period, whilst the organizations are merged, both directory services must coexist. Company A may wish to attach make company B's The requirements which follow from this scenario are: - Multi-Master replication. - Common access control model. - Replication between DITs with differing schemas. 4.1.3 Replication Example An organization may deliberately deploy multiple directory services = within their enterprise to employ the differing benefits of each service. In this case multi-master replication will be required to ensure that the multiple copies of the DIT are synchronized. Some vendors may provide directory clients which are tied to their own directory service. The requirements which follow from this scenario are: - Multi-Master replication - Common access control model. - Replication between DITs with differing schemas. 4.1.4 Shared Name space Example Two organizations may choose to cooperate on some venture and need a shared name space to manage their operation. Both organizations will require administrative rights over the shared name space. The requirements which follow from this scenario are: - Multi-Master replication. - Common access control model. 4.1.5 Supplier Initiated Replication Single master maintains a number of replicas of the DIT by pushing changes based on a defined schedule. 4.1.6 Consumer Initiated Replication Weiser & Stokes 29 October 1998 [Page 6] =0C INTERNET-DRAFT LDAP V3 Replication Requirements 29 April 1998 Again a single mastered replication topology, but the replica initiates the replication exchange rather than the master. 4.1.7 Prioritized attribute replication=20 =20 The password is and example. Say a user working in the Provo Utah and the Administrator lives in Mountain View Ca. The user having forgot a password for a little used account. So the user calls or emails the administrator requesting a new password which the administrator changes for the user. Because of scheduling policies to criticality of certain attributes the user is able to login with the new password shortly after the administrator changed it.=20 4.1.8 Bandwidth issues=20 The replication of Server (A)- R/W replica (a) in Catmando is handled via a dial up phone link to Paris where server (B) R/W replica (a) resides. While Server (C) R/W replica (a) is connected by a T1 connection to server(B).=20 =20 4.1.9 Administration and management =20 The administrator with administrative authority of the corp directory which is replicated by numerous geographically dispersed LDAP servers from different vendors notices that the replication process is not completing correctly as the change log is continuing to grow or and error message informs him. The administrator using his $19.95 Repco LDAP directory replication diagnostics tools looking at Root DSE replica knowledge on server 17 and determines that the server 42 made by xyzzy Inc. is not replicating properly due to an Object conflict. Using his Repco Remote repair tools he connects to server 42 and resolves the conflict on te remote server.=20 5. Replication Model=20 5.1 LDAP Replication MUST be allowed to span different vendors directory services in order to provide interoperability. 5.2 All replicas MUST eventually be updated with the changed information, specified by the replication policy. 5.3 Replication schedules MUST be dynamic to allow for periodic replication, with the replication period determined by administrator of the replicated system. 5.4 Replication Model SHALL enable replication cycle to initiated based in the number of pending changes. Weiser & Stokes 29 October 1998 [Page 7] =0C INTERNET-DRAFT LDAP V3 Replication Requirements 29 April 1998 5.5 The replication model SHOULD allow for initiation of replication cycle for any replica that may have just come back online or was unavailable previously. =20 5.6 The replication model MUST support both master-slave and authoritative multi-updateable replica relationships. .=20 5.7 All replicated information between the master database and its replica databases SHALL be identical including all no user modify operational attributes such as time stamps. Note this does not imply that the entire database is identical from replica to replica, but that the subset of data, chosen to replicate is identical from replica to replica.=20 5.8 Distributed multi-vendor environment, LDAP replication SHALL NOT require all copies of the replicated information be complete copies of the replicated object. 5.9 Replication MUST allow Definition content of replicated information.=20 5.10 LDAP replication SHALL encompass common schema objects and attributes, access control and name spaces. 5.11 Sub tree Replication SHALL be defined to allow for greater flexibility replication topologies of the DIT as defined by by the area of replication. 5.12 A propagation schedule SHALL be defined and SHOULD be tunable within Predetermined replication agreement. 5.13 Replication of critical values SHALL be synchronized with priority over non critical values, an example of a critical value might be a password and or certificate value which maybe considered critical. 5.14 Currently X.525 DISP [X.525] discusses this as a shadowing agreement including such information as unit of replication, update mode, and access point defining many of the policies between the master and a replica. The use of predetermined replication agreements between the directory replicas MUST be addressed to provide proper knowledge of access requirements and credentials between the synchronizing directories. 5.15 Due to the acceptance and usage of the Internet, and the requirement that LDAP replication be available across disparate vendors directory services, LDAP replication MUST provide scalability for both enterprise and internet environments.=20 5.16 The replication model MUST define deterministic policy such that replication cycle startup time conflicts between two or Weiser & Stokes 29 October 1998 [Page 8] =0C INTERNET-DRAFT LDAP V3 Replication Requirements 29 April 1998 more competing master replicas may be resolved programmatically. An Example might be automatic submission and rescheduling by one of the masters. In such a case, these replication "conflicts" SHALL be resolved by the replication policy. 5.17 Replication SHALL be allowed to any LDAP server available on the network; provided appropriate security authorization is granted.=20 6. Replication Protocol 6.1 The act of replication MUST have minimal impact on both the system and network performance.=20 6.2 The replica synchronization MUST be handled in such a manner as to not saturate network with repetitive entry replication from multiple synchronization providers points. =20 6.3 Replication SHALL only be allowed after the authentication and verification of authorization of both the replica and the source directory. 6.4 The transport for LDAP synchronization MUST allow for the integrity and confidentiality of each replicated server. 6.5 Replicated data MUST be transferred in a secure manner. 6.6 Replication protocol MUST provide for recovery and rescheduling of a replication cycle due to update conflict and or loss of conncetion=20 6.7 LDAP replication MUST allow for full update to facilitate replica initialization and reset loading utilizing a standardized LDIF [LDIF] format. 6.8 The normal means of synchronizing replicas SHALL be performed through incremental synchronization and in accordance with the scheduling policies. 6.9 The replication Standard SHOULD NOT limit the size of a replica. The unit of replication is defined to be the naming context. Incremental replication SHOULD be allowed to attempt to keep the amount of data replicated to a minimum. 6.10 Must allow updates to multiple replicas 6.11 The replication protocol MUST allow either a master or replica to initiate the replication process. Weiser & Stokes 29 October 1998 [Page 9] =0C INTERNET-DRAFT LDAP V3 Replication Requirements 29 April 1998 6.12 Additionally the initiator MUST be allowed to determine whether it will become a consumer or supplier during the synchronization startup process. This would allow a replica to be periodically connected and synchronized from remote sites at the local administrator's discretion. 6.13 Multiple LDAP changes, to a single server, SHOULD be allowed to be treated as single atomic unit of work propagated during replication.=20 6.14 An LDAP Replication Standard SHOULD NOT limit the transaction rate of a replication session. 6.15 Entry change information SHALL be purged upon completion of a synchronization cycle where all replica members have been synchronized with the master(s). 7. Schema=20 7.1 Replica knowledge SHALL be provided as DSE attributes=20 7.2 Operational Attributes=20 ????=20 7.1 The Replication Protocol documents MUST define a standard schema for representing replication agreements, and MUST define the semantics associated with modifying the attributes of replication agreements. The documents MUST also define a standard method for determining the location of these agreements. 7.2 The Replication Protocol documents MUST define a standard schema for publishing state information about a given replica, and MUST define a standard method for determining the location of this information. This state information MUST include the ID of the last update propagated to the replica. The format of this ID is to be determined.=20 7.3 Location independent management point SHALL be defined to provide authorized administrators with well known access to the replication policies, regardless of network location. 7.4 Policies for the LDAP replication shall be defined in such a manner as to allow programmatic representation; these policies SHALL be kept as replica attributes or as entries of the predetermined agreement and propagated during replication. 7.5 Replication agreements SHALL be accessible, via LDAP, to all servers containing replicated information. Weiser & Stokes 29 October 1998 [Page 10] =0C INTERNET-DRAFT LDAP V3 Replication Requirements 29 April 1998 8. Administration and Management Considerations 8.1 Replication policies SHALL allow replication of changed information to be postponed to a more convenient period , 8.2 Allowance for non scheduled replication of a replica SHALL be provided upon request such that the replica server has been down or unconnected for a period of time.=20 8.3 Each copy of a replica MUST maintain audit history of who it has replicated with and who has replicated with it. 8.4 A replica MAY store the conflicted versions of the replicated object to allow optional human review and intervention. 8.5 Access to replication predetermined agreements, topologies, and policies attributes MUST be provided through LDAP access. 8.6 The capability to check the differences between two replicas be of the same information SHOULD be provided for. =20 8.7 The capability to view the current state and replication history of each replicated copy in the replication topology, from a single server in the topology. =20 8.8 The ability to view replication conflicts, and override the resolution derived by the replication policy SHALL be provided. 9. Other for further discussion or the garbage heap 9.1 It is not realistic to assume that all vendors have cooperating schemas, but it is required that different vendors schemas allow replication from diverse schemas. and MAY define a model whereby divergent schemas can replicate non-common or extended attributes for common LDAP objects. 9.2 Propagation behavior defines the general behavior of the actual synchronization process between a consumer and a provider of replication information. 9.3 All object SHOULD BE uniquely identifiable though out the object lifetime . 9.4 Replica convergence and resurections of attributes and objects; since( tombestones, Obituaries, deathwarrants, graveyards) are used I=92ll add one more ZOMMBIES. RFW 10. Acknowledgement=20 Weiser & Stokes 29 October 1998 [Page 11] =0C INTERNET-DRAFT LDAP V3 Replication Requirements 29 April 1998 This document is based on input from IETF members interested in LDAP replication=20 11. References [RFC2251] M. Wahl, T. Howes, S. Kille "Lightweight Directory Access Protocol (v3), Standards Track , December 1997 . Availiable as RFC2251=20 [RFC2119] S.Bradner, " Key words for use in RFCs to indicate Requirement Levels", RFC 2119. [LDIF] Gordon Good, "The LDAP Data Interchange Format (LDIF)", Internet draft, draft-ietf-asid-ldif-00.txt, November 1996. [Changelog] Gordon Good, "Definitions of an Object Class to Hold LDAP Change records", Internet Draft, draft-ietf-asid-changelog-00.txt, November 1996. 12. Author's Address Russel F. Weiser Novell Inc. 122 East 1700 South Provo, Utah 84606 USA E-mail: Rweiser@novell.com Telephone: +1-801-861-7808 Fax +1-801-861-2292 Ellen J. Stokes IBM 11400 Burnet Rd. Austin, Texas 78758 USA E-mail: stokes@austin.ibm.com Telephone: +1-512-838-3725 Fax: +1-512-838-0156 Weiser & Stokes 29 October 1998 [Page 12] =0C ------=_NextPart_000_01EF_01BE239F.D566AA00-- From owner-ietf-ldup Mon Dec 14 06:38:33 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA26392 for ietf-ldup-bks; Mon, 14 Dec 1998 06:38:33 -0800 (PST) Received: from fl.dk (ns.fl.dk [193.88.152.147]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA26387 for ; Mon, 14 Dec 1998 06:38:31 -0800 (PST) Received: by gw.fl.dk id <26883-2>; Mon, 14 Dec 1998 16:41:33 +0100 Message-Id: <98Dec14.164133gmt+0100.26883-2@gw.fl.dk> From: Erik Andersen To: ietf-ldup@imc.org Subject: RE: attached please find the second revision of the ldup requirem ents doc Date: Mon, 14 Dec 1998 15:46:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-ietf-ldup@imc.org Precedence: bulk Please observe that the [LDIF] reference is old. The latest version is http://www.ietf.org/internet-drafts/draft-good-ldap-ldif-01.txt Erik Andersen, Consultant, Direct Tel. (+45) 3945 0736, Mobile: (+45) 2097 1490 E-mail: era@fl.dk FISCHER & LORENZ A/S Tuborg Parkvej 10, DK-2900 Hellerup, Copenhagen, Denmark Tel. (+45) 3945 0700, Fax (+45) 3945 0777, E-mail: fl@fl.dk , Internet: http://www.fl.dk CEN/ISSS Directory Workshop chairman, Internet: http://www.cenorm.be/isss/Workshop/DIR/Default.htm From owner-ietf-ldup Tue Dec 15 12:49:13 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA09086 for ietf-ldup-bks; Tue, 15 Dec 1998 12:49:13 -0800 (PST) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA09082 for ; Tue, 15 Dec 1998 12:49:12 -0800 (PST) From: Mike_Spreitzer.PARC@xerox.com Received: from dmsms2.OSBU_North.Xerox.xns by alpha.xerox.com via XNS id <57102(5)>; Tue, 15 Dec 1998 12:55:20 PST X-NS-Transport-ID: 0800201FCE5D39B41B00 Date: Tue, 15 Dec 1998 12:55:04 PST Subject: Be explicit about what constitutes "conflict" and "resolution" To: ietf-ldup@imc.org cc: Mike_Spreitzer.PARC@xerox.com Message-Id: <98Dec15.125520pst."57102(5)"@alpha.xerox.com> Sender: owner-ietf-ldup@imc.org Precedence: bulk I'm starting to send in comments on the requirements and architecture drafts. My first comment is on both of them. They both should explicitly talk about what kinds of situations can be detected as "conflicts" and what kinds of "resolutions" are available. The requirements draft should talk about what's needed, the architecture draft on what's available. I agree with the comment made at the WG meeting (at IETF-43) that these descriptions should be tested against actual applicaitons to see if they're sufficiently expressive. Note that the examples given in the 02 revision of the requirements draft take an administrative viewpoint, and don't actually say anything about what the actual applications are --- there's no discussion of what the data in the replicas are actually used for. As examples, let me mention a couple of examples of applications that I think the current design won't handle. This is not to say it's wrong, just to illustrate the kind of thinking I think would be helpful to make explicit. Example 1. In a few years, the Mark XII Palm Pilot runs an LDUP replica; say the radio stuff hasn't worked out well (e.g., might be expensive), so we are talking about usually-disconnected replicas. Quicken has been ported to LDUP. My wife and I share a checking account, and each run an LDUP replica for it on our own personal Pilots. We go our separate ways during the day, doing things like beaming cheques at POS terminals; each night we synchronize our LDUP replicas. We use some informal mechanism to avoid spending ourselves into the red during the course of a single day. Quicken keeps a container entry for each account. Inside is a journal of financial transactions. An attribute on the account container holds the balance. I think the current LDUP design will work well for the journal of financial transactions, but will not make it easy to keep the balance consistent with the journal. The latest-update-wins model will cause dollar deltas to that balance to simply be lost; the only correct way to get a balance would be to enumerate the whole journal and sum as you go. Example 2. I keep my appointments in LDUP, with replicas on desktop, laptop, and palmtop. Each appointment is a separate entry. A conflict is two entries that overlap in time. From owner-ietf-ldup Tue Dec 15 12:58:16 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA09150 for ietf-ldup-bks; Tue, 15 Dec 1998 12:58:16 -0800 (PST) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA09146 for ; Tue, 15 Dec 1998 12:58:15 -0800 (PST) From: Mike_Spreitzer.PARC@xerox.com Received: from dmsms2.OSBU_North.Xerox.xns by alpha.xerox.com via XNS id <57276(4)>; Tue, 15 Dec 1998 13:04:21 PST X-NS-Transport-ID: 0800201FCE5D39B41B01 Date: Tue, 15 Dec 1998 13:04:06 PST Subject: Affect on client/server interactions To: ietf-ldup@imc.org cc: Mike_Spreitzer.PARC@xerox.com Message-Id: <98Dec15.130421pst."57276(4)"@alpha.xerox.com> Sender: owner-ietf-ldup@imc.org Precedence: bulk The possibility of conflicts and resolutions may affect the applications (LDAP clients and whatnot). I can imagine at least four positions on this issue; the requirements and architecture drafts should explicitly say which is taken. 1. Completely unmodified clients and users. Clients use "plain" LDAPv3, and nothing else, to access the data. Users use only these plain clients. 2. Unmodified clients plus administrative side doors. Clients use "plain" LDAPv3 for data access. Additionally, there are administrative side doors that allow special clients to set conflict detection and resolution policies for various parts (exactly what constitutes a "part" is open to design) of the data space. 3. Modified clients tunnel extra information through LDAPv3. Using additional entries and/or attributes, clients can indicate how they want conflicts detected and resolved. 4. Modified clients use new data access protocol. My initial impression is that 3 and 4 are distinguished only by a spurrious conservatism, but that doesn't reflect a lot of thought. The above is focused on how clients affect conflicts and resolutions (supposing this is possible at all). A related issue is how information about conflicts and resolutions (if any is to be made available) gets back to the clients. Similar options present themselves. From owner-ietf-ldup Tue Dec 15 13:12:20 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA09419 for ietf-ldup-bks; Tue, 15 Dec 1998 13:12:20 -0800 (PST) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA09415 for ; Tue, 15 Dec 1998 13:12:19 -0800 (PST) From: Mike_Spreitzer.PARC@xerox.com Received: from dmsms2.OSBU_North.Xerox.xns by alpha.xerox.com via XNS id <57526(5)>; Tue, 15 Dec 1998 13:18:27 PST X-NS-Transport-ID: 0800201FCE5D39B41B03 Date: Tue, 15 Dec 1998 13:18:06 PST Subject: Replication agreements between partial replicas To: ietf-ldup@imc.org cc: Mike_Spreitzer.PARC@xerox.com Message-Id: <98Dec15.131827pst."57526(5)"@alpha.xerox.com> Sender: owner-ietf-ldup@imc.org Precedence: bulk Here I presume LDUP has no write log. If it does, these comments may also apply (e.g., if the write log at a partial replica is itself partial). Wouldn't the replication relationships of partial replicas need to be restricted, to cases where the consumer is strictly "more partial" (i.e., holds a subset of the entries, and a subset of the attributes) than the supplier? From owner-ietf-ldup Tue Dec 15 13:14:05 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA09469 for ietf-ldup-bks; Tue, 15 Dec 1998 13:14:05 -0800 (PST) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA09465 for ; Tue, 15 Dec 1998 13:14:04 -0800 (PST) From: Mike_Spreitzer.PARC@xerox.com Received: from dmsms2.OSBU_North.Xerox.xns by alpha.xerox.com via XNS id <57554(2)>; Tue, 15 Dec 1998 13:20:08 PST X-NS-Transport-ID: 0800201FCE5D39B41B04 Date: Tue, 15 Dec 1998 13:19:56 PST Subject: Dynamism of replica locations To: ietf-ldup@imc.org cc: Mike_Spreitzer.PARC@xerox.com Message-Id: <98Dec15.132008pst."57554(2)"@alpha.xerox.com> Sender: owner-ietf-ldup@imc.org Precedence: bulk Can an LDUP replica ever move from one IP address to another? If so, there are issues around keeping its peers able to locate it. From owner-ietf-ldup Tue Dec 15 13:08:34 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA09312 for ietf-ldup-bks; Tue, 15 Dec 1998 13:08:34 -0800 (PST) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA09308 for ; Tue, 15 Dec 1998 13:08:33 -0800 (PST) From: Mike_Spreitzer.PARC@xerox.com Received: from dmsms2.OSBU_North.Xerox.xns by alpha.xerox.com via XNS id <57454(1)>; Tue, 15 Dec 1998 13:14:43 PST X-NS-Transport-ID: 0800201FCE5D39B41B02 Date: Tue, 15 Dec 1998 13:14:30 PST Subject: Does LDUP use a "write log"? To: ietf-ldup@imc.org cc: Mike_Spreitzer.PARC@xerox.com Message-Id: <98Dec15.131443pst."57454(1)"@alpha.xerox.com> Sender: owner-ietf-ldup@imc.org Precedence: bulk As I read through the architecure draft, I found myself unsure of whether a "write log" (in Bayou terminology; you might also call it an "update log" or "change log") is part of the design. I found myself considering three possibilities: #1. Like Bayou, LDUP maintains a write log and derives the data state from the write log contents (by rolling the data back and reapplying writes when necessary). #2. LDUP maintains a write log, but does not ever roll back the data state. The write log might be subject to some compaction (as well as the pruning that's always necessary in a practical system). #3. LDUP maintains no write log; the only history available is the current state of the data. At the WG meeting at IETF-43 I heard #3 articulated as a tentative design goal; I also heard some doubt that it will be reached. It's no