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 ------------------------------------------------------------------------