From owner-ietf-ldup@imc.org Mon Oct 11 08:25:56 1999 Received: from mail.imc.org (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29713 for ; Mon, 11 Oct 1999 08:25:55 -0400 (EDT) Received: by mail.imc.org (8.9.3/8.9.3) id EAA27588 for ietf-ldup-bks; Mon, 11 Oct 1999 04:31:46 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.imc.org (8.9.3/8.9.3) with SMTP id EAA27584 for ; Mon, 11 Oct 1999 04:31:44 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 11 Oct 1999 05:31:44 -0600 Message-Id: X-Mailer: Novell GroupWise 5.5.2 Date: Mon, 11 Oct 1999 05:31:34 -0600 From: "Natarajan SK" To: , , "Ed Reed" Subject: LDAP Replication Architecture Document. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.imc.org id EAA27585 Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi, In the LDAP Replication Architecture document, we specify that Fractional Replicas are to be read only. Why is this? Can't it be that these replicas also get updated (without passing a referral to the Supplier) and these changes in turn are replicated across. Is there any specific reason for not allowing these Fractional Replicas to be updated. Maybe I'm overlooking something outright obvious. Regards, Natarajan S.K.Natarajan Senior Software Engineer Novell Software, Bangalore E-mail sknatarajan@novell.com Ph. no. 91-80-572-1856/58 Extn. 2213 Fx 91-80-572-1870 From owner-ietf-ldup@imc.org Mon Oct 11 08:34:18 1999 Received: from mail.imc.org (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00118 for ; Mon, 11 Oct 1999 08:34:17 -0400 (EDT) Received: by mail.imc.org (8.9.3/8.9.3) id FAA29484 for ietf-ldup-bks; Mon, 11 Oct 1999 05:06:31 -0700 (PDT) Received: from prv-mail25.provo.novell.com (prv-mail25.provo.novell.com [137.65.82.196]) by mail.imc.org (8.9.3/8.9.3) with SMTP id FAA29479 for ; Mon, 11 Oct 1999 05:06:30 -0700 (PDT) Received: from INET-PRV1-Message_Server by prv-mail25.provo.novell.com with Novell_GroupWise; Mon, 11 Oct 1999 06:07:39 -0600 Message-Id: X-Mailer: Novell GroupWise 5.5.2 Date: Mon, 11 Oct 1999 06:06:25 -0600 From: "Ed Reed" To: , , "Natarajan SK" Subject: Re: LDAP Replication Architecture Document. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.imc.org id FAA29481 Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit The specific reason is that we don't know how to specify how to manage the update vector for changes made at the fractional replica. There are ideas, but there is so little real-world experience, by any of us, with including fractional replicas which are updateable in a multi-master replica community, we chose to simplify our task by precluding them. We will gain operational experience with them as Novell deploys support for Virtual Replicas in upcoming releases of NDS, and as other vendors do, too. But, it's not the job of an IETF working group to speculate on what might work in their protocol designs, but rather to document what has been shown will work if done correctly. We're not that far along in the experience curve, yet, with updateable fractional replicas. The only operational experience we've found, to date, is for single master configurations, where read-only shadow replicas may be fractional (ala X.500 DISP). Regards, Ed ================= Ed Reed Reed-Matthews, Inc. +1 801 785 0315 eer@oncalldba.com >>> Natarajan SK 10/11/1999 05:31:34 >>> Hi, In the LDAP Replication Architecture document, we specify that Fractional Replicas are to be read only. Why is this? Can't it be that these replicas also get updated (without passing a referral to the Supplier) and these changes in turn are replicated across. Is there any specific reason for not allowing these Fractional Replicas to be updated. Maybe I'm overlooking something outright obvious. Regards, Natarajan S.K.Natarajan Senior Software Engineer Novell Software, Bangalore E-mail sknatarajan@novell.com Ph. no. 91-80-572-1856/58 Extn. 2213 Fx 91-80-572-1870 From owner-ietf-ldup@imc.org Tue Oct 12 05:10:43 1999 Received: from mail.imc.org (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07087 for ; Tue, 12 Oct 1999 05:10:42 -0400 (EDT) Received: by mail.imc.org (8.9.3/8.9.3) id BAA22883 for ietf-ldup-bks; Tue, 12 Oct 1999 01:38:12 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id BAA22869; Tue, 12 Oct 1999 01:36:47 -0700 (PDT) Received: from France.Sun.COM ([129.157.188.1]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id BAA14877; Tue, 12 Oct 1999 01:38:28 -0700 (PDT) Received: from bebop.France.Sun.COM by France.Sun.COM (SMI-8.6/SMI-SVR4-sd.fkk205) id KAA21159; Tue, 12 Oct 1999 10:37:53 +0200 Received: from France.sun.com by bebop.France.Sun.COM (8.8.8+Sun/SMI-SVR4) id KAA09315 for ; Tue, 12 Oct 1999 10:37:56 +0200 (MET DST) Message-ID: <3802F366.667B9BAE@France.sun.com> Date: Tue, 12 Oct 1999 10:37:58 +0200 From: Ludovic Poitou Organization: Sun Microsystems Inc. X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ldapext@netscape.com, ietf-ldup@imc.org, openldap-general@OpenLDAP.org, ietf-lsd@imc.org Subject: LDAP Interop. testing at Connectathon Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Sorry if you receive this message several times.. Plans for Connectathon 2000 are already under way! The 14th annual Connectathon event, an interoperability testing event for engineers only, will be held March 2-9, 2000 in San Jose, California. Connectathon, sponsored by Sun Microsystems, Inc., hosts nearly 30 companies annually in an effort to test and debug source code which utilize the following technologies and protocols: NFS versions 2, 3 and 4 NFS over TCP WebNFS Lock Manager NIS/NIS+/DNS TI-RPC Kerberos Automounter IPv6 DHCP LDAP Gigabit Ethernet Based on demand, in addition we are considering to offer: NFS over IPv6 RPC over IPv6 Service Location Protocol IPsec Mobile IPv4 If you are interested in testing any of the above 5 protocols, please send a note to Cthon@Sun.COM and we'll gauge interest. Or if you have a suggestion for another technology, feel free to contact us as well. Testing continues 24 hours per day. Technology testing coordinators will organize testing procedures and test suite material. In addition, there will be seminars with speakers addressing various topics. The registration deadline is February 14, 2000. An Early Bird Discount on booth fees is available to those who register and pay by December 31, 1999. For registration information, please see our web site at http://www.connectathon.org. If you have any questions, please feel free to contact Audrey Van Belleghem at audrey@vanb.com or (408) 358-9598. We look forward to seeing you at the 14th annual Connectathon event! Audrey Van Belleghem Connectathon Manager -- Ludovic Poitou Sun Microsystems Inc. Sun-Netscape Alliance - Directory Group - Grenoble - France From owner-ietf-ldup@imc.org Tue Oct 12 11:32:24 1999 Received: from mail.imc.org (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18843 for ; Tue, 12 Oct 1999 11:32:23 -0400 (EDT) Received: by mail.imc.org (8.9.3/8.9.3) id HAA04372 for ietf-ldup-bks; Tue, 12 Oct 1999 07:49:41 -0700 (PDT) Received: from Newman.GSC.GTE.Com (SYSTEM@Newman.GSC.GTE.Com [207.175.88.67]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id HAA04368 for ; Tue, 12 Oct 1999 07:49:36 -0700 (PDT) Received: from gscex02.gsc.gte.com ("port 1649"@gscex02.winnt.chnt.gsc.gte.com [131.131.133.151]) by Newman.GSC.GTE.Com (PMDF V5.2-30 #29038) with ESMTP id <01JH1M1K9LIK000IBA@Newman.GSC.GTE.Com> for ietf-ldup@imc.org; Tue, 12 Oct 1999 10:51:18 -0400 (EDT) Received: by gscex02.winnt.chnt.gsc.gte.com with Internet Mail Service (5.5.2448.0) id <4GGRKDV8>; Tue, 12 Oct 1999 10:51:22 -0400 Content-return: allowed Date: Tue, 12 Oct 1999 10:51:16 -0400 From: "Sweigert, David" Subject: RE: LDAP Replication Architecture Document. To: Natarajan SK , ietf-ldup@imc.org, Merrels@netscape.com, Ed Reed Message-id: <2575327B6755D211A0E100805F9FF95403B989B1@ndhmex02.ndhm.gsc.gte.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I am confused. We can this document be obtained ? Dave Sweigert http://www.gd-cs.com -----Original Message----- From: Natarajan SK [mailto:sknatarajan@novell.com] Sent: Monday, October 11, 1999 7:32 AM To: ietf-ldup@imc.org; Merrels@netscape.com; Ed Reed Subject: LDAP Replication Architecture Document. Hi, In the LDAP Replication Architecture document, we specify that Fractional Replicas are to be read only. Why is this? Can't it be that these replicas also get updated (without passing a referral to the Supplier) and these changes in turn are replicated across. Is there any specific reason for not allowing these Fractional Replicas to be updated. Maybe I'm overlooking something outright obvious. Regards, Natarajan S.K.Natarajan Senior Software Engineer Novell Software, Bangalore E-mail sknatarajan@novell.com Ph. no. 91-80-572-1856/58 Extn. 2213 Fx 91-80-572-1870 From owner-ietf-ldup@imc.org Fri Oct 15 13:16:34 1999 Received: from mail.imc.org (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17929 for ; Fri, 15 Oct 1999 13:16:33 -0400 (EDT) Received: (from majordomo@localhost) by mail.imc.org (8.9.3/8.9.3) id IAA29764 for ietf-ldup-bks; Fri, 15 Oct 1999 08:53:16 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.imc.org (8.9.3/8.9.3) with SMTP id IAA29760 for ; Fri, 15 Oct 1999 08:53:14 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 15 Oct 1999 09:54:40 -0600 Message-Id: X-Mailer: Novell GroupWise 5.5.2 Date: Fri, 15 Oct 1999 09:54:33 -0600 From: "Roger Harrison" To: Subject: Submission of draft-rharrison-lburp-00.txt Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_49107B50.1A7B01C0" Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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. --=_49107B50.1A7B01C0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In response to the discussion at IETF-45 in Oslo regarding the bulk = transmission of LDIF data from client to server, I've written the = Internet-Draft referenced below. I have attached a copy of the draft for = your convenience. I would appreciate your comments and feedback. Thanks, Roger Harrison ------------------------------------------------------ Roger G. Harrison Novell, Inc. roger_harrison@novell.com=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : LDAP Bulk Update/Replication Protocol Author(s) : R. Harrison, J. Sermersheim Filename : draft-rharrison-lburp-00.txt Pages : 10 Date : 14-Oct-99 =09 The protocol described in this document allows an LDAP client (a genuine client or an LDAP server acting as a client) to perform a bulk update to a replica on an LDAP server using standard LDAP update operations encapsulated within the LDUP Update Transfer Protocols described in [LDUP MODEL] and [LDUP RUP]. The protocol may be used to initialize all of the entries in an LDAP replica or to incrementally change the existing entries in an LDAP replica. It is suitable for client utilities that need to efficiently initialize a replica with many entries or efficiently make a substantial set of update changes to a replica. It is also suitable as a protocol for replication between a single master replica and its slave replicas. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rharrison-lburp-00.txt=20 Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rharrison-lburp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt=20 Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-rharrison-lburp-00.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail = readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. --=_49107B50.1A7B01C0 Content-Type: text/plain Content-Disposition: attachment; filename="draft-rharrison-lburp-00.txt" Content-Transfer-Encoding: quoted-printable Individual Submission to ldup working group R. Harrison Internet Draft J. Sermersheim Document: draft-rharrison-lburp-00.txt Novell, Inc. Category: Proposed Standard October, 1999 LDAP Bulk Update/Replication Protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract The protocol described in this document allows an LDAP client (a genuine client or an LDAP server acting as a client) to perform a bulk update to a replica on an LDAP server using standard LDAP update operations encapsulated within the LDUP Update Transfer Protocols described in [LDUP MODEL] and [LDUP RUP]. The protocol may be used to initialize all of the entries in an LDAP replica or to incrementally change the existing entries in an LDAP replica. It is suitable for client utilities that need to efficiently initialize a replica with many entries or efficiently make a substantial set of update changes to a replica. It is also suitable as a protocol for replication between a single master replica and its slave replicas. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [ReqsKeywords]. 3. Motivation for protocol Individual Submission - Expires April 14, 2000 Harrison & Sermersheim 1 =0C LDAP Bulk Update/Replication Protocol October, 1999 This protocol arose from the need to allow LDAP clients to efficiently present large quantities of updates to an LDAP server and have the LDAP server efficiently process them. This protocol introduces a minimum of new operational functionality to the LDAP protocol since the updates discussed in this draft are done with standard LDAP [LDAPv3] update operations. However, this protocol greatly facilitates this process by allowing the server to recognize the client=92s intent to perform a potentially large set of update operations and then to change its processing strategy to be more efficient than it otherwise could be. In effect, this protocol gives a hint to the server that the LDAP operations bracketed within it can be treated in a special way because they are related to each other. The server may then take actions that would not otherwise be practical to speed the processing of the updates. Examples of such actions include refusing to perform operations for other clients during the update sequence and grouping update operations. Additionally, this protocol deals with a common interoperability problem in this space caused by implementations having different requirements and abilities for handling linear and circular dependencies as entries are created. A common application of this protocol is anticipated to be the initialization or update of an LDAP replica from a set of records represented in an LDIF [LDIF] file. Due to the abilities of various implementations, these files often contain =93out-of-order=94 records where an entry is created before its parent or it is made a member of a group before the member=92s entry has been created. Some implementations create temporary holding objects to deal with these issues, but others do not. This protocol allows the server to reorder update operations in a limited way to deal with such cases. 4. Overview of protocol This replication update protocol utilizes standard LDAP update operations for transmitting replication information between client and server. The client brackets a stream of asynchronous LDAP update operations between two LDAP v3 extended requests: the first notifies the server that the following stream of LDAP update operations are to be treated as a unit of replication information and the second marks the end of the replication stream. This allows the LDAP server to make certain assumptions about the content of the LDAP requests in the replication stream that can be used to facilitate the rapid and efficient processing of the requests. Two styles of update--full and incremental--are defined. Full update creates a completely new set of entries in the target replica; any existing entries in that replica at the start of the replication operation are removed before the LDAP requests in the Individual Submission - Expires April 14, 2000 Harrison & Sermersheim 2 =0C LDAP Bulk Update/Replication Protocol October, 1999 replication stream are processed. The only LDAP operation allowed in a full update replication stream is add. After a server receives and acknowledges a full replication request, the LDAP server MUST not service LDAP requests other than those contained in the replication stream for the replica which is being initialized until the replication stream is completely processed. Incremental update performs a series of incremental changes to the replica; existing entries in the replica are only affected if explicitly modified in some way by the update operations contained in the replication stream. All LDAP v3 update operations defined in [LDAPv3]--add, modify, delete, and moddn--are allowed in the incremental replication stream. When a server is processing an incremental replication request, the replica which is being modified MAY service LDAP requests received on connections other than the connection on which the replication stream is being sent. The LDAP server processing the replication update operation is responsible to send a synchronous extended operation response to the client, signaling the beginning of the replication sequence. It sends an asynchronous response signifying the completion status of each LDAP operation in the replication stream. After the server has completed processing all update operations in the replication stream and has responded to each, it sends a final extended operation response to the client, which signals the end of the replication operation. No attempt is made to deal with the issues associated with multiple- master replicas or to maintain state information such as modification times of entries or attribute values in such a way that updates to the same entry on multiple master replicas can be correctly ordered. For this reason convergence of data between all replicas can only be assured in a single-master replication environment. 5. High-level Description of Protocol Flow AUTHOR'S NOTE: This section is taken, almost verbatim, from section 4 of [LDUP RUP]. It is expected that at some future point, the text in section 4 of [LDUP RUP] will be generalized in such a way that most or all of the overlapping text can be removed from this document. The following section provides a high-level overview of the replication protocol. Throughout this section, the client or server acting as supplier is indicated by the letter "S", and the server acting as consumer is indicated by the letter "C". The construct "S -> C" indicates that the supplier is sending an LDAPv3 operation to the consumer, and "C -> S" indicates that the consumer is sending an LDAPv3 operation to the supplier. Individual Submission - Expires April 14, 2000 Harrison & Sermersheim 3 =0C LDAP Bulk Update/Replication Protocol October, 1999 5.1 Supplier-initiated replication protocol S -> C: LDAP bind operation (identity and credentials used are implementation-defined) C -> S: Bind response S -> C: StartReplicationRequest LDAPv3 extended operation. The parameters are: 1) Root of replicated area (unambiguously identifies the replicated area) 2) Supplier's replicaID 3) OID of incremental or full update replication protocol as defined in this document. 4) The protocol initiation type - Supplier-Initiated =20 C -> S: StartReplicationResponse LDAPv3 extended operation. The parameters are: 1) A response code (see section 7) 2) An optional update vector that is included if and only if the response code is REPL_SUCCESS. AUTHOR'S NOTE: The RUP protocol needs to be changed here to accommodate the Bulk Update/Replication Protocol. The client will ignore any update vector sent, so I suggest making the update vector optional for this protocol as well as in cases of errors. S -> C: The supplier may send zero or more asynchronous LDAP v3 update operations. C -> S: Upon completion (successful or otherwise) of each LDAP v3 update operation, the consumer sends the appropriate LDAP response for that operation as defined in [LDAPv3]. S -> C: After all required updates have been sent to the consumer, the supplier sends an EndReplicationRequest LDAPv3 extended operation. C -> S: The consumer responds by sending an EndReplicationRequest LDAPv3 extended operation and then closes the connection. Individual Submission - Expires April 14, 2000 Harrison & Sermersheim 4 =0C LDAP Bulk Update/Replication Protocol October, 1999 5.2. Consumer-initiated replication protocol AUTHOR'S NOTE: This section has been copied from section 4.2 of [LDUP RUP]. References to "this document" in this section thus actually refer to [LDUP RUP]. It is anticipated that at some future point that this section will simply refer to section 4.2 of [LDUP RUP]. C -> S: LDAP bind operation (identity and credentials used are implementation-defined) S -> C: Bind response C -> S: StartReplicationRequest LDAPv3 extended operation. The parameters are: 1) Root of replicated area (unambiguously identifies the replicated area) 2) Consumer's replicaID 3) OID of replication protocol to be used (this document defines IETF-LDUP incremental and IETF-LDUP total update protocols) 4) The protocol initiation type - Consumer-Initiated in this case S -> C: StartReplicationResponse LDAPv3 extended operation. The parameters are: 1) A response code (see section 7) S -> C: The supplier server disconnects from the consumer server, and then connects to the consumer, beginning a Supplier- Initiated protocol session (see section 4.1). 5.3 Client-initiated replication protocol There are times when an LDAP client that doesn't have an outstanding replication agreement with a consumer server wants to initiate an update replication session as a supplier using this protocol. In this case, the following changes apply to the Supplier-initiated replication protocol: 1) The client, acting as supplier, sends the special value of [value to be determined] as the supplier's replicaID in the StartReplicationRequest. 2) The consumer, recognizing the supplier as a client, omits the update vector in the StartReplicationResponse, for every value of the response code, including REPL_SUCCESS. Individual Submission - Expires April 14, 2000 Harrison & Sermersheim 5 =0C LDAP Bulk Update/Replication Protocol October, 1999 6. Elements of Protocol The LDAP Bulk Update/Replication protocol works within the framework of the Replication Update Protocol [LDUP RUP]. Unless otherwise stated, those elements of protocol taken from the Replication Update Protocol framework are to be used precisely as described there. 6.1 StartReplicationRequest Extended Operation The StartReplicationRequest Extended Operation is defined in Section 5.1 of [LDUP RUP]. Clarification of the use of the replicaID is required for this protocol, as is the specification of the replicationProtocolOID. Other parameters of the StartReplicationRequest are as defined in Section 5.1 of [LDUP RUP]. 6.1.1 replicaID In the case where a replication agreement exists between the supplier and consumer, the replicaID is as specified in Section 5.1 of [LDUP RUP]. When a client, acting as supplier, is initiating a replication request, it MUST send the special value of [value to be determined] as the supplier's replicaID in the StartReplicationRequest. 6.1.2 replicationProtocolOID The OID for the Full Update Protocol is 2.16.840.1.113719.1.27.1.4.1. The OID for the Incremental Update Protocol is 2.16.840.1.113719.1.27.1.4.2. 6.2 StartReplicationResponse In the case where a replication agreement exists between the supplier and consumer, the updateVector is as specified in Section 5.1 of [LDUP RUP]. When a client, acting as supplier, has initiated a replication request, the updateVector SHALL NOT be returned in the StartReplicationResponse. 6.3 ReplicationUpdateOperation The ReplicationUpdateOperation is not utilized in the LDAP Bulk Update/Replication protocol. Standard LDAP update requests as defined in sections 4.6, 4.7, 4.8, and 4.9 of [LDAPv3] are used to send all update requests to the consumer server. 6.4 EndReplicationRequest Individual Submission - Expires April 14, 2000 Harrison & Sermersheim 6 =0C LDAP Bulk Update/Replication Protocol October, 1999 The EndReplicationRequest is sent as specified in section 5.4 of [LDUP RUP]. The replicaUpdateVector MUST NOT be sent by the supplier, and the returnConsumerUpdateVector MUST be set to FALSE. 6.5 EndReplicationResponse The EndReplicat1ionResponse is sent as specified in section 5.4 of [LDUP RUP]. No replicaUpdateVector will be returned due to the requirement that the supplier not request it. 7. Semantics of Full and Incremental Update Protocols Since both the full and incremental update protocols use standard LDAP operations to transmit update information, no attempt is made by the protocol to include the information needed to support full multi-master replication as defined by [LDUP RUP]. Although entries and their associated attributes and attribute values can be synchronized using this protocol, no CSNs are included in the update stream; updates made using this replication protocol are treated the same as other LDAP operations wherein they are deemed to occur at the present. Operational attributes such as modifiersTimeStamp MAY be included in the replication stream, and if they are, they SHOULD be put into the entry. The LDAP update operations that form the replication stream may be sent asynchronously by the supplier to the consumer. This means that the supplier need not wait for a response from one LDAP update operation before sending the next. Suppliers MUST NOT send the replication stream over multiple connections or do other things that could change the order of the operations in the replication sequence. The LDAP operations in the replication stream, plus the initial state of entries in the consumer replica in the case of incremental update, collectively represent the desired final state of the consumer replica. The consumer server may take any action required to efficiently achieve this desired final state of the replica. Examples of such actions include reordering LDAP requests to ensure that linear dependencies within the replication stream are correctly ordered, breaking an LDAP modification request into two or more separate modification requests to adequately resolve a circular dependency within the replication stream, and aggregating LDAP update operations to process them more efficiently. When taking actions of this sort, the server MUST NOT reorder LDAP requests in such a way that the desired final state is different from that which would have been achieved before the action was taken. 7.1 Semantics of the Full Replication Protocol Individual Submission - Expires April 14, 2000 Harrison & Sermersheim 7 =0C LDAP Bulk Update/Replication Protocol October, 1999 Full replication creates a completely new set of entries in that replica; any existing entries in that replica at the start of the replication operation are removed before the LDAP requests in the replication stream are processed. The only LDAP operation allowed in a full replication stream is add. If any other LDAP operation is received as part of the replication stream, the server MUST return unwillingToPerform as the response for the operation. While a server is processing a full replication request, the consumer server MUST not service LDAP requests for the replica involved in the replication operation other than those contained in the replication stream including LDAP requests on other connections. This requirement is designed to allow implementers the freedom to implement highly-efficient methods of handling the replication stream without being constrained by the need to maintain a live, working database while doing so. If the full update sequence fails for some reason (e.g. a connection is abruptly broken in the middle of an otherwise-successful update sequence) the server MUST remove any entries created during the update sequence, thereby leaving the replica in a known state. 7.2 Semantics of the Incremental Replication Protocol Incremental replication performs a series of incremental changes to the replica; existing entries in the replica are only affected if explicitly modified in some way by the update operations contained in the replication stream. All LDAP v3 update operations--add, modify, delete, and moddn--are allowed in the incremental replication stream. If a non-update operation is received as part of the replication stream, the server MUST return unwillingToPerform as the response for the operation. When a server is processing an incremental replication request, the consumer server MAY service LDAP requests for the replica involved in the replication operation on connections other than that being used to transmit the replication stream. 8. Notes To Implementers It is RECOMMENDED that, if possible, the consumer LDAP server refer non-replication requests for the replica being updated to another server containing that replica during the time that consumer LDAP server has the replica off-line for replication. Implementations MAY choose to perform the operations in the replication stream with special permissions to improve performance. Individual Submission - Expires April 14, 2000 Harrison & Sermersheim 8 =0C LDAP Bulk Update/Replication Protocol October, 1999 9. Security Considerations Implementations should ensure that a supplier making a Bulk Update/Replication request is bound with appropriate permissions. There is a potential for loss of data, especially with the full update protocol, which removes all entries in a replica as part of its operation. Second, forcing the removal of all entries in a replica may consume large amounts of server resources. Third, unlike other replication protocols, no existing replication agreement between supplier and consumer is required. These risks increase if the consumer server also processes the replication stream with special permissions to improve performance. For these reasons, implementers should carefully consider which identities or permissions are required to perform Bulk Update/Replication Protocol operations and take steps to ensure that only connections bound with appropriate permissions are allowed to perform them. The data contained in the replication stream may contain passwords and other sensitive data. Care should be taken to properly safeguard this information while in transit between supplier and consumer. 10. References [LDAPv3] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [LDIF] Gordon Good, "LDAP Data Interchange Format (LDIF)", INTERNET- DRAFT: draft-good-ldap-ldif-04.txt, 22 June 1999. [LDUP MODEL] John Merrells, Ed Reed, and Uppili Srinivasan, "LDAP Replication Architecture", INTERNET-DRAFT: draft-ietf-ldup- model-01.txt, June 25, 1999. [LDUP RUP] Ellen Stokes and Gordon Good, "The LDUP Replication Update Protocol", UNPUBLISHED INTERNET-DRAFT: draft-ietf-ldup- protocol-00.txt. [ReqsKeywords] Scott Bradner. "Key Words for use in RFCs to Indicate Requirement Levels". RFC 2119. 11. Author's Addresses Roger Harrison Novell, Inc. Individual Submission - Expires April 14, 2000 Harrison & Sermersheim 9 =0C LDAP Bulk Update/Replication Protocol October, 1999 122 E. 1700 S. Provo, UT 84606 +1 801 861 2642 roger_harrison@novell.com Jim Sermersheim Novell, Inc. 122 E. 1700 S. Provo, UT 84606 +1 801 861 3088 jimse@novell.com Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Individual Submission - Expires April 14, 2000 Harrison & Sermersheim 10 =0C --=_49107B50.1A7B01C0-- From owner-ietf-ldup@imc.org Tue Oct 19 19:38:43 1999 Received: from mail.imc.org (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04242 for ; Tue, 19 Oct 1999 19:38:37 -0400 (EDT) Received: by mail.imc.org (8.9.3/8.9.3) id QAA10753 for ietf-ldup-bks; Tue, 19 Oct 1999 16:01:37 -0700 (PDT) Received: from dir1.control.att.com ([135.207.251.15]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id QAA10749 for ; Tue, 19 Oct 1999 16:01:36 -0700 (PDT) Received: from att.com (pest.control.att.com [135.207.251.76]) by dir1.control.att.com (Postfix) with ESMTP id 63DE071C2; Tue, 19 Oct 1999 19:07:57 -0400 (EDT) Message-ID: <380CF544.C9F33C03@att.com> Date: Tue, 19 Oct 1999 18:48:36 -0400 From: Chris Apple Organization: AT&T Labs X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ldup@imc.org Subject: WG Meeting Agenda Items Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Please send proposed agenda items for the LDUP WG meeting at the DC IETF. Document editors: this is a friendly reminder to get your drafts in by the 10/22/1999 deadline. Chris Apple From owner-ietf-ldup@imc.org Wed Oct 20 03:55:32 1999 Received: from mail.imc.org (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21219 for ; Wed, 20 Oct 1999 03:55:31 -0400 (EDT) Received: by mail.imc.org (8.9.3/8.9.3) id AAA01053 for ietf-ldup-bks; Wed, 20 Oct 1999 00:09:28 -0700 (PDT) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id AAA01044 for ; Wed, 20 Oct 1999 00:09:23 -0700 (PDT) X-Envelope-Sender-Is: Helmut.Volpers@icn.siemens.de (at relayer david.siemens.de) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.9.3/8.9.3) with ESMTP id JAA06011; Wed, 20 Oct 1999 09:11:53 +0200 (MET DST) Received: from pinguin.mch.sni.de (pinguin.mch.sni.de [192.103.27.50]) by mail1.siemens.de (8.9.3/8.9.3) with ESMTP id JAA25956; Wed, 20 Oct 1999 09:11:52 +0200 (MET DST) Received: from icn.siemens.de (snoopy.mch.sni.de [192.103.27.15]) by pinguin.mch.sni.de (8.8.8/8.8.8) with ESMTP id JAA06170; Wed, 20 Oct 1999 09:11:52 +0200 Message-ID: <380D6AF3.84A7BCA5@icn.siemens.de> Date: Wed, 20 Oct 1999 09:10:43 +0200 From: Helmut Volpers Organization: Siemens X-Mailer: Mozilla 4.6 [de] (WinNT; I) X-Accept-Language: de MIME-Version: 1.0 To: "Reed, Ed" , ietf-ldup@imc.org, ietf-ldapext@netscape.com Subject: draft-ietf-ldup-subentry-01.txt Content-Type: multipart/mixed; boundary="------------FD5297C4FC59256275532987" Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dies ist eine mehrteilige Nachricht im MIME-Format. --------------FD5297C4FC59256275532987 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Ed, I have a question to your draft "LDAP Subentry Schema". If I understand it correct this draft offers the possibility to store operational entries in a Directory Server which were not shown in normal browsing operations only if a client explicit request for them. They were uses for Replication agreements and perhaps for any other kind of operational objects. What is the reason this draft is located in the LDUP group and not LDAPEXT ? Is it because we will need this first time for replication ? Regards Helmut --------------FD5297C4FC59256275532987 Content-Type: text/x-vcard; charset=us-ascii; name="Helmut.Volpers.vcf" Content-Description: Visitenkarte für Helmut Volpers Content-Disposition: attachment; filename="Helmut.Volpers.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Volpers;Helmut tel;work:+49-89-636-46713 x-mozilla-html:FALSE url:http://www.siemens.com/bus-com org:Siemens AG adr:;;;;;; version:2.1 email;internet:Helmut.Volpers@icn.siemens.de title:Directory Server Architect fn:Helmut Volpers end:vcard --------------FD5297C4FC59256275532987-- From owner-ietf-ldup@imc.org Wed Oct 20 10:46:11 1999 Received: from mail.imc.org (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05050 for ; Wed, 20 Oct 1999 10:46:10 -0400 (EDT) Received: (from majordomo@localhost) by mail.imc.org (8.9.3/8.9.3) id GAA10090 for ietf-ldup-bks; Wed, 20 Oct 1999 06:54:17 -0700 (PDT) Received: from mail.oncalldba.com (reed.oncalldba.com [166.70.104.61]) by mail.imc.org (8.9.3/8.9.3) with SMTP id GAA10085 for ; Wed, 20 Oct 1999 06:54:15 -0700 (PDT) Received: from RMINC_DOM-Message_Server by mail.oncalldba.com with Novell_GroupWise; Wed, 20 Oct 1999 07:47:34 -0600 Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Wed, 20 Oct 1999 07:47:09 -0600 From: "Ed Reed" To: , , , Subject: Re: draft-ietf-ldup-subentry-01.txt Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_7C2544E6.28492546" Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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. --=_7C2544E6.28492546 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Correct. I discussed putting it under LDAPEXT with Tim and Mark, but they allowed as how it might as well go under LDUP since (1) that's where it will be used first, and (2) LDAPEXT has enough on it's plate already ;-) So yes, LDUP WG is just a "flag of convenience" for the draft. The Subentry object class is intended to be generally useful to the community, and not just to the LDUP efforts. Ed =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ed Reed Reed-Matthews, Inc. +1 801 785 0315 http://www.OnCallDBA.COM >>> Helmut Volpers 10/20/99 01:10AM >>> Hi Ed, I have a question to your draft "LDAP Subentry Schema". If I understand it=20 correct this draft offers the possibility to store operational entries=20 in a Directory Server which were not shown in normal browsing operations=20= only if a client explicit request for them. They were uses for Replication=20 agreements and perhaps for any other kind of operational objects. What is the reason this draft is located in the LDUP group and not=20 LDAPEXT ? Is it because we will need this first time for replication ? Regards Helmut --=_7C2544E6.28492546 Content-Type: text/plain Content-Disposition: attachment; filename="TEXT.htm"
Correct.
 
I discussed putting it under LDAPEXT with Tim and Mark, but they allowed
as how it might as well go under LDUP since (1) that's where it will be
used first, and (2) LDAPEXT has enough on it's plate already ;-)
 
So yes, LDUP WG is just a "flag of convenience" for the draft.  The
Subentry object class is intended to be generally useful to the
community, and not just to the LDUP efforts.
 
Ed
 
=================
Ed Reed
Reed-Matthews, Inc.
+1 801 785 0315
http://www.OnCallDBA.COM

>>> Helmut Volpers <Helmut.Volpers@icn.siemens.de> 10/20/99 01:10AM >>>
Hi Ed,

I have a question to your draft "LDAP Subentry Schema". If I understand
it
correct this draft offers the possibility to store operational entries
in a Directory Server which were not shown in normal browsing operations
only if a client explicit request for them. They were uses for
Replication
agreements and perhaps for any other kind of operational objects.
What is the reason this draft is located in the LDUP group and not
LDAPEXT ? Is it because we will need this first time for replication ?

Regards

Helmut
--=_7C2544E6.28492546-- From owner-ietf-ldup@imc.org Wed Oct 20 12:45:23 1999 Received: from mail.imc.org (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12092 for ; Wed, 20 Oct 1999 12:45:22 -0400 (EDT) Received: by mail.imc.org (8.9.3/8.9.3) id IAA12563 for ietf-ldup-bks; Wed, 20 Oct 1999 08:53:46 -0700 (PDT) Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.imc.org (8.9.3/8.9.3) with SMTP id IAA12559 for ; Wed, 20 Oct 1999 08:53:44 -0700 (PDT) Received: id LAA07975; Wed, 20 Oct 1999 11:52:57 -0400 Received: by gateway id <43HH3FJ6>; Wed, 20 Oct 1999 11:55:37 -0400 Message-ID: <01E1D01C12D7D211AFC70090273D20B10139D6F2@sothmxs06.entrust.com> From: Mike Just To: "'Chris Apple'" Cc: ietf-ldup@imc.org Subject: RE: WG Meeting Agenda Items Date: Wed, 20 Oct 1999 11:55:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: When is the group meeting? I notice that it's not on the current IETF agenda yet (as of Oct. 19). Mike J. > ---------- > From: Chris Apple[SMTP:capple@att.com] > Sent: Tuesday, October 19, 1999 6:48 PM > To: ietf-ldup@imc.org > Subject: WG Meeting Agenda Items > > Please send proposed agenda items for the LDUP WG meeting at the > DC IETF. > > Document editors: this is a friendly reminder to get your drafts in by > the > 10/22/1999 deadline. > > Chris Apple > From owner-ietf-ldup@imc.org Thu Oct 21 13:29:40 1999 Received: from mail.imc.org (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07418 for ; Thu, 21 Oct 1999 13:29:39 -0400 (EDT) Received: by mail.imc.org (8.9.3/8.9.3) id JAA04834 for ietf-ldup-bks; Thu, 21 Oct 1999 09:42:11 -0700 (PDT) Received: from mail.oncalldba.com (reed.oncalldba.com [166.70.104.61]) by mail.imc.org (8.9.3/8.9.3) with SMTP id JAA04830 for ; Thu, 21 Oct 1999 09:42:09 -0700 (PDT) Received: from RMINC_DOM-Message_Server by mail.oncalldba.com with Novell_GroupWise; Thu, 21 Oct 1999 10:36:03 -0600 Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Thu, 21 Oct 1999 10:35:27 -0600 From: "Ed Reed" To: , Subject: Re: WG Meeting Agenda Items Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_FCA5C6E3.4B2A4624" Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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. --=_FCA5C6E3.4B2A4624 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Chris - I'm looking for ldup on the ietf agenda...but it's not there. Do = we have a date/time for the meeting, yet? Uppili and I would like some time to discuss the profiles documents we're = preparing, their organization and our approach to writing them...10-15 = minutes would be enough, unless there's lots of discussion. As for the schema doc, I'll have a new draft posted by the deadline = tomorrow, and possibly another before the meeting. =20 Ed =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ed Reed Reed-Matthews, Inc. +1 801 785 0315 http://www.OnCallDBA.COM >>> Chris Apple 10/19/99 04:48PM >>> Please send proposed agenda items for the LDUP WG meeting at the DC IETF. Document editors: this is a friendly reminder to get your drafts in by the 10/22/1999 deadline. Chris Apple --=_FCA5C6E3.4B2A4624 Content-Type: text/plain Content-Disposition: attachment; filename="TEXT.htm"
Chris - I'm looking for ldup on the ietf agenda...but it's not there.  Do we have a date/time for the meeting, yet?
 
Uppili and I would like some time to discuss the profiles documents we're preparing, their organization and our approach to writing them...10-15 minutes would be enough, unless there's lots of discussion.
 
As for the schema doc, I'll have a new draft posted by the deadline tomorrow, and possibly another before the meeting. 
 
Ed
 
 
 
=================
Ed Reed
Reed-Matthews, Inc.
+1 801 785 0315
http://www.OnCallDBA.COM

>>> Chris Apple <capple@att.com> 10/19/99 04:48PM >>>
Please send proposed agenda items for the LDUP WG meeting at the
DC IETF.

Document editors: this is a friendly reminder to get your drafts in by
the
10/22/1999 deadline.

Chris Apple

--=_FCA5C6E3.4B2A4624-- From owner-ietf-ldup@imc.org Thu Oct 21 13:37:23 1999 Received: from mail.imc.org (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07783 for ; Thu, 21 Oct 1999 13:37:23 -0400 (EDT) Received: by mail.imc.org (8.9.3/8.9.3) id JAA05189 for ietf-ldup-bks; Thu, 21 Oct 1999 09:55:49 -0700 (PDT) Received: from dir1.control.att.com ([135.207.251.15]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id JAA05185 for ; Thu, 21 Oct 1999 09:55:47 -0700 (PDT) Received: from att.com (pest.control.att.com [135.207.251.76]) by dir1.control.att.com (Postfix) with ESMTP id 6DC9771C2; Thu, 21 Oct 1999 13:02:24 -0400 (EDT) Message-ID: <380F4298.836BA617@att.com> Date: Thu, 21 Oct 1999 12:43:04 -0400 From: Chris Apple Organization: AT&T Labs X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Ed Reed Cc: ietf-ldup@imc.org Subject: Re: WG Meeting Agenda Items References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Meeting time/day is not set yet. The deadline for scheduling the meetings blew right by me. Problems with e-mail delivery so I never got the usual reminder notices. Ed Reed wrote: > Chris - I'm looking for ldup on the ietf agenda...but it's not there. Do we have a date/time for the meeting, yet? > > Uppili and I would like some time to discuss the profiles documents we're preparing, their organization and our approach to writing them...10-15 minutes would be enough, unless there's lots of discussion. Will you have documents submitted to the I-D editor for them by the deadline? > > > As for the schema doc, I'll have a new draft posted by the deadline tomorrow, and possibly another before the meeting. Great! Chris. > > > Ed > > ================= > Ed Reed > Reed-Matthews, Inc. > +1 801 785 0315 > http://www.OnCallDBA.COM > > >>> Chris Apple 10/19/99 04:48PM >>> > Please send proposed agenda items for the LDUP WG meeting at the > DC IETF. > > Document editors: this is a friendly reminder to get your drafts in by > the > 10/22/1999 deadline. > > Chris Apple > > ------------------------------------------------------------------------ > > TEXT.htmName: TEXT.htm > Type: Plain Text (text/plain) From owner-ietf-ldup@imc.org Fri Oct 22 03:42:06 1999 Received: from mail.imc.org (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03711 for ; Fri, 22 Oct 1999 03:42:05 -0400 (EDT) Received: by mail.imc.org (8.9.3/8.9.3) id AAA01859 for ietf-ldup-bks; Fri, 22 Oct 1999 00:02:47 -0700 (PDT) Received: from webo.vtcif.telstra.com.au (webo.vtcif.telstra.com.au [202.12.144.19]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id AAA01854 for ; Fri, 22 Oct 1999 00:02:45 -0700 (PDT) Received: (from uucp@localhost) by webo.vtcif.telstra.com.au (8.8.2/8.6.9) id RAA10303; Fri, 22 Oct 1999 17:04:55 +1000 (EST) Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by webo.vtcif.telstra.com.au, id smtpdanbEZ_; Fri Oct 22 17:04:43 1999 Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id RAA01726; Fri, 22 Oct 1999 17:04:42 +1000 (EST) Received: from mail.cdn.telstra.com.au(144.135.138.138) via SMTP by maili.vtcif.telstra.com.au, id smtpd0mo2nr; Fri Oct 22 17:03:21 1999 Received: from odin.trl.oz.au (odin.trl.oz.au [137.147.242.2]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with SMTP id RAA22272; Fri, 22 Oct 1999 17:03:20 +1000 (EST) Received: (from slegg@localhost) by odin.trl.oz.au (8.6.9/8.6.12) id RAA03853; Fri, 22 Oct 1999 17:03:22 +1000 From: Steven Legg Message-Id: <199910220703.RAA03853@odin.trl.oz.au> Subject: Re: WG Meeting Agenda Items To: capple@att.com (Chris Apple) Date: Fri, 22 Oct 1999 17:03:21 +1000 (EST) Cc: ietf-ldup@imc.org In-Reply-To: <380CF544.C9F33C03@att.com> from "Chris Apple" at Oct 19, 99 06:48:36 pm 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 List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Chris, I've just posted off a revised draft of URP. Please reserve a 15 minute slot at the meeting for me to go over the latest changes. Regards, Steven Legg Chris Apple wrote: > > Please send proposed agenda items for the LDUP WG meeting at the > DC IETF. > > Document editors: this is a friendly reminder to get your drafts in by > the > 10/22/1999 deadline. > > Chris Apple > > From owner-ietf-ldup@imc.org Fri Oct 22 15:35:49 1999 Received: from mail.imc.org (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03424 for ; Fri, 22 Oct 1999 15:35:46 -0400 (EDT) Received: (from majordomo@localhost) by mail.imc.org (8.9.3/8.9.3) id LAA23903 for ietf-ldup-bks; Fri, 22 Oct 1999 11:02:05 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id LAA23897 for ; Fri, 22 Oct 1999 11:02: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 LAA07372 for ; Fri, 22 Oct 1999 11:04:14 -0700 (PDT) Received: from netscape.com ([208.12.63.197]) by tintin.mcom.com (Netscape Messaging Server 4.1) with ESMTP id FK0NJ600.MQO for ; Fri, 22 Oct 1999 11:04:18 -0700 Message-ID: <3810A69A.4A2F4994@netscape.com> Date: Fri, 22 Oct 1999 11:02:02 -0700 From: merrells@netscape.com (John Merrells) Organization: Netscape Communications X-Mailer: Mozilla 4.6 [en]C-NSCP (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: LDUP Subject: ldup arch draft - part 1 of 2 Content-Type: multipart/mixed; boundary="------------669A73EF38F256CED4313CBC" Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------669A73EF38F256CED4313CBC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I just submitted a new revision of the the ldup architecture draft. The only changes have been a couple of clarifications and language fixes. I'm sorry this is in two parts. The remailer imposes a silly size limit. John --------------669A73EF38F256CED4313CBC Content-Type: text/plain; charset=iso-8859-1; name="draft-ietf-ldup-model-02-part1.txt" Content-Disposition: inline; filename="draft-ietf-ldup-model-02-part1.txt" Content-Transfer-Encoding: 8bit INTERNET-DRAFT draft-ietf-ldup-model-02.txt John Merrells Netscape Communications Corp. Ed Reed Novell, Inc. Uppili Srinivasan Oracle, Inc. October 22, 1999 LDAP Replication Architecture Copyright (C) The Internet Society (1998,1999). All Rights Reserved. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or made obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This draft, file name draft-ietf-ldup-model-01.txt, is intended to be become a Proposed Standard RFC, to be published by the IETF Working Group LDUP. Distribution of this document is unlimited. Comments should be sent to the LDUP Replication mailing list or to the authors. This Internet-Draft expires on 22 March 2000. Merrells, Reed, Srinivasan [Page 1] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 1. Abstract This architectural document outlines a suite of schema and protocol extensions to LDAPv3 that enables the robust, reliable, server-to- server exchange of directory content and changes. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. The sections below reiterate these definitions and include some additional ones. Merrells, Reed, Srinivasan [Page 2] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 2. Table of Contents 1. Abstract 2 2. Table of Contents 3 3. Introduction 5 3.1 Scope 5 3.2 Document Objectives 6 3.3 Document Non-Objectives 7 3.4 Existing Implementations 7 3.4.1 Replication Log Implementations 8 3.4.2 State-Based Implementations 8 3.5 Terms and Definitions 8 3.6 Consistency Models 9 3.7 LDAP Constraints 10 4. Directory Model 11 4.1 Replica Type 11 4.1.1 Primary Replica 11 4.1.2 Updatable Replica 12 4.1.3 Read-Only Replica 12 4.1.4 Fractional Replicas 12 4.2 Sub-Entries 12 4.3 Glue Entries 12 4.4 Unique Identifiers 12 4.5 Change Sequence Number 13 4.5.1 CSN Composition 13 4.5.2 CSN Representation 13 4.5.3 CSN Generation 14 4.5.3.1 CSN Generation - Log Based Implementation 14 4.5.3.2 CSN Generation - State Based Implementation 14 4.6 State Change Information 15 4.6.1 Entry Change State Storage and Representation 15 4.6.2 Attribute Change State Storage 16 4.6.3 Attribute Value Change State Storage 16 4.7 LDAP Update Operations 16 5. Information Model 16 5.1 Entries, Semantics and Relationships 17 5.2 Root DSE Attributes 17 5.3 Naming Context Auxiliary Object Class and Entries 17 5.4 Replica Object Class and Entries 18 5.5 Lost and Found Entry 18 5.6 Replication Agreement Object Class and Entries 18 5.6.1 Replication Schedule 19 6. Policy Information 20 6.1 Access Control 20 6.2 Schema Knowledge 21 7. LDUP Update Transfer Protocol Framework 21 Merrells, Reed, Srinivasan [Page 3] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 7.1 Replication Session Initiation 21 7.1.1 Authentication 22 7.1.2 Consumer Initiated 22 7.1.3 Supplier Initiated 22 7.2 Start Replication Session 22 7.2.1 Start Replication Request 22 7.2.2 Start Replication Response 23 7.2.3 Consumer Initiated, Start Replication Session 23 7.3 Update Transfer 23 7.4 End Replication Session 24 7.4.1 End Replication Request 24 7.4.2 End Replication Response 24 7.5 Integrity & Confidentiality 24 8. LDUP Update Protocols 24 8.1 Replication Updates and Update Primitives 25 8.2 Fractional Updates 25 9. LDUP Full Update Transfer Protocol 25 9.1 Supplier Initiated, Full Update, Start Replication Session 25 9.2 Full Update Transfer 26 9.3 Replication Update Generation 26 9.4 Replication Update Consumption 26 9.5 Full Update, End Replication Session 26 9.6 Interrupted Transmission 27 10. LDUP Incremental Update Transfer Protocol 27 10.1 Update Vector 27 10.2 Supplier Initiated, Incremental Update, Start Replication Session 28 10.3 Replication Update Generation 29 10.3.1 Replication Log Implementation 29 10.3.2 State-Based Implementation 29 10.4 Replication Update Consumption 29 10.5 Update Resolution Procedures 30 10.5.1 URP: Distinguished Names 30 10.5.2 URP: Orphaned Entries 30 10.5.3 URP: Distinguished Not Present 31 10.5.4 URP: Schema - Single Valued Attributes 31 10.5.5 URP: Schema - Required Attributes 31 10.5.6 URP: Schema - Extra Attributes 31 10.5.7 URP: Duplicate Attribute Values 31 10.5.8 URP: Ancestry Graph Cycle 32 10.6 Incremental Update, End Replication Session 32 10.7 Interrupted Transmission 32 11. Purging State Information 33 11.1 Purge Vector 33 11.2 Purging Deleted Entries, Attributes, and Attribute Values 33 12. Replication Configuration and Management 34 13. Time 35 14. Security Considerations 36 Merrells, Reed, Srinivasan [Page 4] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 15. Acknowledgements 36 16. References 37 17. Intellectual Property Notice 38 18. Copyright Notice 38 19. Authors' Address 39 20. Appendix B - LDAP Constraints 40 20.1 LDAP Constraints Clauses 40 20.2 LDAP Data Model Constraints 41 20.3 LDAP Operation Behaviour Constraints 42 20.4 New LDAP Constraints 43 20.4.1 New LDAP Data Model Constraints 43 20.4.2 New LDAP Operation Behaviour Constraints 43 3. Introduction 3.1 Scope This architectural document provides an outline of an LDAP based replication scheme. Further detailed design documents will draw guidance from here. The design proceeds from prior work in the industry, including concepts from the ITU-T Recommendation X.525 (1993, 1997) Directory Information Shadowing Protocol (DISP) [X525], experience with widely deployed distributed directories in network operating systems, electronic mail address books, and other database technologies. The emphasis of the design is on: 1. Simplicity of operation. 2. Flexibility of configuration. 3. Manageability of replica operations among mixed heterogeneous vendor LDAP servers under common administration. 4. Security of content and configuration information when LDAP servers from more than one administrative authority are interconnected. A range of deployment scenarios are supported, including multi-master and single-master topologies. Replication networks may include transitive and redundant relationships between LDAP servers. The controlling framework used to define the relationships, types, and state of replicas of the directory content is defined. In this way the Merrells, Reed, Srinivasan [Page 5] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 directory content can itself be used to monitor and control the replication network. The directory schema is extended to define object classes, auxiliary classes, and attributes that describe areas of the namespace which are replicated, LDAP servers which hold replicas of various types for the various partitions of the namespace, LDAP Access Points (network addresses) where such LDAP servers may be contacted, which namespaces are held on given LDAP servers, and the progress of replication operations. Among other things, this knowledge of where directory content is located will provide the basis for dynamic generation of LDAP referrals. [REF] An update transfer protocol, which actually brings a replica up to date with respect to changes in directory content at another replica, is defined using LDAPv3 protocol extensions. The representation of directory content and changes will be defined by the LDAP Replication Update Transfer Protocol sub-team. Incremental and full update transfer mechanisms are described. Replication protocols are required to include initial population, change updates, and removal of directory content. Security information, including access control policy will be treated as directory content by the replication protocols. Confidentiality and integrity of replication information is required to be provided by lower-level transport/session protocols such as IPSEC and/or TLS. 3.2 Document Objectives The objectives of this document are: a) To define the architectural foundations for LDAP Replication, so that further detailed design documents may be written. For instance, the Information Model, Update Transfer Protocol, and Update Resolution Procedures documents. b) To provide an architectural solution for each clause of the requirements document [LDUP Requirements]. c) To preserve the LDAP Data Model and Operation Behaviour constraints defined for LDAP in RFC 2251. d) To avoid tying the LDUP working group to the schedule of any other working group. e) Not to infringe upon known registered intellectual property rights. Merrells, Reed, Srinivasan [Page 6] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 3.3 Document Non-Objectives This document does not address the following issues, as they are considered beyond the scope of the Working Group. a) How LDAP becomes a distributed directory. There are many issues beyond replication that should be considered. Such as, support for external references, algorithms for computing referrals from the distributed directory knowledge, etc. b) Specifying management protocols to create naming contexts or new replicas. LDAP may be sufficient for this. The document describes how new replicas and naming contexts are represented, in the directory, as entries, attributes, and attribute values. c) How transactions will be replicated. However, the architecture should not knowingly prevent or impede them, given the Working Group's incomplete understanding of the issues at this time. d) The mapping or merging of disparate Schema definitions. e) Support of overlapping replicated regions. f) The case where separate attributes of an entry may be mastered by different LDAP servers. This might be termed a 'Split Primary'. Replica roles are defined in section 4.1. g) The specification of a replication system that supports Sparse Replication. A Sparse Replica contains a subset of the naming context entries, being modified by an Entry Selection Filter criteria associated with the replica. An Entry Selection Filter is an LDAP filter expression that describes the entries to be replicated. The design and implementation of this functionality is not yet well enough understood to specify here. 3.4 Existing Implementations In order to define a standard replication scheme that may be readily implemented we must consider the architectures of current LDAP server implementations. Existing systems currently support proprietary replication schemes based on one of two general approaches: log-based or state-based. Some sections of this text may specifically address the concerns of one approach. They will be clearly marked. Merrells, Reed, Srinivasan [Page 7] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 3.4.1 Replication Log Implementations Implementations based on the original University of Michigan LDAP server code record LDAP operations to a operation log. During a replication session operations are replayed from this log to bring the Consumer replica up to date. Example implementations of this type at this time are the Innosoft, Netscape, and Open LDAP Directory Servers. 3.4.2 State-Based Implementations Directory Server implementations from Novell and Microsoft at this time do not replay LDAP operations from a operation log. When a replication session occurs each entry in the Replicated Area is considered in turn, compared against the update state of the Consumer, and any resultant changes transmitted. These changes are a set of assertions about the presence or absence of entries, attributes, and their values. 3.5 Terms and Definitions The definitions from the Replication Requirements document have been copied here and extended. For brevity, an LDAP server implementation is referred to throughout as 'the server'. The LDAP update operations; Add, Delete, Modify, Modify RDN (LDAPv2) and Modify DN (LDAPv3), are collectively referred to as LDAP Update Operations. A Naming Context is a subtree of entries in the Directory Information Tree (DIT). There may be multiple Naming Contexts stored on a single server. Naming Contexts are defined in section 17 of [X501]. A Replica is an instance of a replicated Naming Context. A replicated Naming Context is said to be single-mastered if there is only one Replica where it may be updated, and multi-mastered if there is more than one Replica where it may be updated. A Replication Relationship is established between two or more Replicas that are hosted on servers that cooperate to service a common area of the DIT. A Replication Agreement is defined between two parties of a Replication Relationship. The properties of the agreement codify the Merrells, Reed, Srinivasan [Page 8] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 Unit of Replication, the Update Transfer Protocol to be used, and the Replication Schedule of a Replication Session. A Replication Session is an LDAP session between the two servers identified by a replication agreement. Interactions occur between the two servers, resulting in the transfer of updates from the supplier replica to the consumer replica. The Initiator of a Replication Session is the initiating server. A Responder server responds to the replication initiation request from the Initiator server. A Supplier server is the source of the updates to be transferred. A Consumer server is the recipient of the update sequence. The Update Transfer Protocol is the means by which the Replication Session proceeds. It defines the protocol for exchanging updates between the Replication Relationship partners. A Replication Update is an LDAP Extended Operation that contains updates to be applied to the DIT. The Update Transfer Protocol carries a sequence of these messages from the Supplier to the Consumer. The Update Resolution Procedures repair constraint violations that occur when updates to a multi-mastered Replica collide. A Fractional Entry Specification is a list of entry attributes to be included, or a list of attributes to be excluded in a replica. An empty specification implies that all entry attributes are included. A Fractional Entry is an entry that contains only a subset of its original attributes. It has been modified by a Fractional Entry Specification. A Fractional Replica is a replica that holds Fractional Entries of its naming context. 3.6 Consistency Models This replication architecture supports a loose consistency model between replicas of a naming context. It does not attempt to provide the appearance of a single copy of a replica. The contents of each replica may be different, but over time they will be converging towards the same state. This architecture is not intended to support Merrells, Reed, Srinivasan [Page 9] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 LDAP Clients that require a tight consistency model, where the state of all replicas is always equivalent. Three levels of consistency are available to LDAP Clients, which are characterised by their deployment topologies. Single-Server, where there is just the naming context and no replicas. Single-master, where there are replicas, but only one may be updated. And, multi-master, where there is more than one replica to which LDAP update operations may be directed. The consistency properties of each model are rooted in their serialization of read and write operations. 1) A single-server deployment of a naming context provides tight consistency to LDAP applications. LDAP Clients have no choice but to direct all their operations to a single server, serializing both read and write operations. 2) A single-mastered deployment of a naming context provides both tight and loose consistency to LDAP applications. LDAP Clients must direct all write operations to the single updateable replica, but may direct their reads to any of the replicas. A client experiences tight consistency by directing all its operations to the single updatable replica, and loose consistency by directing any read operations to any other replica. 3) A multi-mastered deployment of a naming context can provide only loose consistency to LDAP applications. Across the system writes and reads are not serialized. An LDAP Client could direct their read and write operations to a single updatable replica, but they will not receive tight consistency as interleaved writes could be occurring at another replica. Tight consistency can be achieved in a multi-master deployment for a particular LDAP application if and only if all instances of its client are directed towards the same updatable replica, and the application data is not updated by any other LDAP application. Introducing these constraints to an application and deployment of a naming-context ensures that writes are serialized providing tight consistency for the application. Future work could make use of the architecture proposed in this document as a basis for allowing clients to request session guarantees from a server when establishing a connection. 3.7 LDAP Constraints The LDAP Internet-Draft [LDAPv3] defines a set of Data Model and Operation Behaviour constraints that a compliant LDAP server must Merrells, Reed, Srinivasan [Page 10] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 enforce. The server must reject an LDAP Update Operation if its application to the target entry would violate any one of these LDAP Constraints. [Appendix B contains the original text clauses from RFC 2251, and also a summary.] In the case of a single-server or single-mastered naming context all LDAP Constraints are immediately enforced at the single updateable replica. An error result code is returned to an LDAP Client that presents an operation that would violate the constraints. In the case of a multi-mastered naming context not all LDAP Constraints can be immediately enforced at the updateable replica to which the LDAP Update Operation is applied. This loosely consistent replication architecture ensures that at each replica all constraints are imposed, but as updates are replicated constraint violations arise that can not be reported to the appropriate client. Any constraint violations that occur are repaired by a set of update resolution procedures. Any LDAP client that has been implemented to expect immediate enforcement of all LDAP Constraints may not behave as expected against a multi-mastered naming context. 4. Directory Model This section describes extensions to the LDAP Directory Model that are required by this replication architecture. 4.1 Replica Type Each Replica is characterized with a replica type. This may be Primary, Updatable, or Read-Only. A Read-Only Replica may be further defined as being Fractional. 4.1.1 Primary Replica The Primary Replica is a full copy of the Replica, to which all applications that require tight consistency should direct their LDAP Operations. There can be only one Primary Replica within the set of Replicas of a given Naming Context. It is also permissible for none of the Replicas to be designated the Primary. The Primary Replica must not be a Fractional Replica. Merrells, Reed, Srinivasan [Page 11] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 4.1.2 Updatable Replica An Updatable Replica is a Replica that accepts all the LDAP Update Operations, but is not the Primary Replica. There could be none, one, or many Updatable Replicas within the set of Replicas of a given Naming Context. An Updatable Replica must not be a Fractional Replica. 4.1.3 Read-Only Replica A Read-Only Replica will accept only non-modifying LDAP operations. All modification operations shall be referred to an updateable Replica. The server referred to would usually be a Supplier of this Replica. 4.1.4 Fractional Replicas Fractional Replicas must always be Read-Only. All LDAP Update Operations must be referred to an Updatable Replica. The server referred to would usually be a Supplier of this Fractional Replica. 4.2 Sub-Entries Replication management entries are to be stored at the base of the replicated naming context. They will be of a ‘subentry’ objectclass to exclude them from regular searches. Entries with the objectclass subentry are not returned as the result of a search unless the filter component "(objectclass=subentry)" is included in the search filter. 4.3 Glue Entries A glue entry is an entry that contains knowledge of its name only. No other information is held with it. They are distinguished by a ‘glueEntry’ objectclass. Glue entries may be created during a replication session to repair a constraint violation. 4.4 Unique Identifiers Distinguished names can change, so are therefore unreliable as identifiers. A Unique Identifier must therefore be assigned to each entry as it is created. This identifier will be stored as an operational attribute of the entry, named ‘entryUUID’. The entryUUID attribute is single valued. The unique identifier is to be generated by the UUID (Universally Unique IDentifier) algorithm, also known as GUID (Globally Unique IDentifier) [UUID]. An example UUID would be, 58DA8D8F-9D6A-101B-AFC0-4210102A8DA7. Merrells, Reed, Srinivasan [Page 12] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 4.5 Change Sequence Number Change Sequence Numbers (CSNs) are used to impose a total ordering upon the causal sequence of updates applied to all the replicas of a naming context. Every LDAP Update Operation is assigned at least one CSN. A Modify operation may be assigned one CSN per modification. 4.5.1 CSN Composition A CSN is formed of four components. In order of significance they are; the time, a change count, a Replica Identifier, and a modification number. The CSN is composed thus to ensure the uniqueness of every generated CSN. When CSNs are compared to determine their ordering they are compared component by component. First the time, then the change count, then the replica identifier, and finally the modification number. The time component is a year-2000-safe representation of the real world time, with a granularity of one second. Should LDAP Update Operations occur at different replicas, to the same data, within the same single second, then the change count is used to further order the changes. Because many LDAP Update Operations, at a single replica, may be applied to the same data in a single second, the change count component of the CSN is provided to further order the changes. Each replica maintains a count of LDAP update operations applied against it. It is reset to zero at the start of each second, and is monotonically increasing within that second, incremented for each and every update operation. Should LDAP Update Operations occur at different replicas, to the same data, within the same single second, and happen to be assigned the same change count number, then the Replica Identifier is used to further order the changes. The Replica Identifier is the value of the RDN attribute on the Replica Subentry. The Replica Identifier could be assigned programmatically or administratively, in either case short values are advised to minimise resource usage. The IA5CaseIgnoreString syntax is used to compare and order Replica Identifier values. The fourth and final CSN component, the modification number, is used for ordering the modifications within an LDAP Modify operation. 4.5.2 CSN Representation The preferred CSN representation is: yyyy mm dd hh:mi:ssz # 0xSSSS # replica id # 0xssss Merrells, Reed, Srinivasan [Page 13] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 The ‘z’ in the time stipulates that the time is expressed in GMT without any daylight savings time offsets permitted, and the 0xssss represents the hexadecimal representation of an unsigned integer. Implementations must support 16 bit change counts and should support longer ones (32, 64, or 128 bits). An example CSN would be " 1998081018:44:31z#0x000F#1#0x0000 ". The update assigned this CSN would have been applied at time 1998081018:44:31z happened to be the 16th operation which was applied in that second, was made against the replica with identifier ‘1’, and was the first modification of the operation that caused the change. 4.5.3 CSN Generation Because Change Sequence Numbers are primarily based on timestamps, clock differences between servers can cause unexpected change ordering. The synchronization of server clocks is not required, though it is preferable that clocks are accurate. If timestamps are not accurate, and a server consistently produces timestamps which are significantly older than those of other servers, its updates will not have effect and the real world time ordering of updates will not be maintained. However, an implementation may choose to require clock synchronisation. The Network Time Protocol [NTP] [SNTP] offers a protocol means by which heterogeneous server hosts may be time synchronised. The modifications which made up an LDAP Modify operation are presented in a sequence. This must be preserved when the resultant changes of this operation are replicated. 4.5.3.1 CSN Generation - Log Based Implementation The modification number component may not be required, since the ordering of the modifications within an LDAP Modify operation have been preserved in the operation log. 4.5.3.2 CSN Generation - State Based Implementation The modification number component may be needed to ensure that the order of the modifications within an LDAP Modify operation are faithfully replicated. Merrells, Reed, Srinivasan [Page 14] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 4.6 State Change Information State changes can be introduced via either LDAP Update Operations or via Replication Updates. A CSN is included with all changes made to an entry, its attributes, and attribute values. This state information must be recorded for the entry to enable a total ordering of updates. The CSN recorded is the CSN assigned to the state change at the server where the state change was first made. CSNs are only assigned to state changes that originate from LDAP Update Operations. Each of the LDAP Update Operations change their target entry in different ways, and record the CSN of the change differently. The state information for the resultant state changes are recorded at three levels. The entry level, attribute level, and attribute value level. The state change may be shown through. 1) The creation of a deletion CSN for the entry, an attribute, or an attribute value. 2) In the addition of a new entry, attribute or attribute value, and its existence CSN. 3) An update to an existing attribute, attribute value, entry distinguished name, or entry superior name, and its update CSN. 4.6.1 Entry Change State Storage and Representation When an entry is created, with the LDAP Add operation, the CSN of the change is added to the entry as the value of an operational attribute named 'createdEntryCSN', of syntax type LDAPChangeSequenceNumber. createdEntryCSN ::= csn Deleted entries are marked as deleted by the addition of the object class 'deletedEntry'. The attribute 'deletedEntryCSN', of syntax type LDAP Change Sequence Number, is added to record where and when the entry was deleted. Deleted entries are not visible to LDAP clients - they may not be read, they don't appear in lists or search results, and they may not be changed once deleted. Names of deleted entries are available for reuse by new entries immediately after the deleted entry is so marked. It may be desirable to allow deleted entries to be accessed and manipulated by management and data recovery applications, but that is outside the scope of this document. deletedEntryCSN ::= csn A CSN is recorded for both the RDN, and the Superior DN of the entry. Merrells, Reed, Srinivasan [Page 15] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 4.6.2 Attribute Change State Storage When all values of an attribute have been deleted, the attribute is marked as deleted and the CSN of the deletion is recorded. The deleted state and CSN are stored by the server, but have no representation on the entry, and may not be the subject of a search operation. This state information must be stored to enable the Update Resolution Procedures to be performed. 4.6.3 Attribute Value Change State Storage The Modification CSN for each value is to be set by the server when it accepts a modification request to the value, or when a new value with a later Modification CSN is received via Replication. The modified value and the Modification CSN changes are required to be atomic, so that the value and its Modification CSN cannot be out of synch on a given server. The state information is stored by the server, but it has no representation on the entry, and may not be the subject of a search operation. When the value of an attribute is deleted the state of its deletion must be recorded, with the CSN of the modifying change. It must be stored to enable the Update Resolution Procedures to be performed. 4.7 LDAP Update Operations The server must reject LDAP client update operations with a CSN that is older than the state information that would be replaced if the operation were performed. This could occur in a replication topology where the difference between the clocks of updateable replicas was too large. Result code 72, serverClocksOutOfSync, is returned to the client. 5. Information Model This section describes the object classes of the entries that represent the replication topology. The where, when and how of Naming Context replication is administered through these entries. The LDUP Working Group will publish an Internet Draft to fully detail all these schema elements. [LDUP Info] Merrells, Reed, Srinivasan [Page 16] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 5.1 Entries, Semantics and Relationships A hierarchy of entries is defined that describe a Naming Context, its Replicas, and its Replication Agreements. The Naming Context Auxiliary Class is added to container entries that may have separately defined replication policy. [LDUP Info] Immediately subordinate to a Naming Context entry are the Replica Subentry container entries that identify its LDAP Access Point, its Replica Type, and if it is a Fractional Replica, the attributes it does or does not hold. The attribute value of the entry’s Relative Distinguished Name (RDN) is termed the Replica Identifier and is used as a component of each CSN. Immediately subordinate in the namespace to a Replica Subentry are Replication Agreement leaf entries which each identify another Replica, the scheduling policy for replication operations, including times when replication is to be performed, when it is not to be performed, or the policies governing event-driven replication initiation. 5.2 Root DSE Attributes The Root DSE attribute 'replicaRoot', publishes the names of the Replicas that are held on that server. Each value of the attribute is the Distinguished Name of the root entry of the Replicated Area. 5.3 Naming Context Auxiliary Object Class and Entries Each Naming Context contains attributes which hold common configuration and policy information for all replicas of the Naming Context. A Naming Context Creation attribute records when and where the Naming Context was created. The Access Control Policy OID attribute defines the syntax and semantics of Access Control Information for entries within the Naming Context. The Naming Context is based at the entry given the auxiliary class, and continues down the tree until another Naming Context is encountered. Merrells, Reed, Srinivasan [Page 17] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 5.4 Replica Object Class and Entries Each Replica is characterized by a replica type. This may be Primary, Updatable, or Read-Only. The latter two types may be further defined as being Fractional. The Replica entry will include a Fractional Entry Specification for a Fractional Replica. There is a need to represent network addresses of servers holding replicas and participating in Replication Agreements. The X.501 Access Point syntax is not sufficient, in that it is tied specifically to OSI transports. Therefore, a new syntax will be defined for LDAP which serves the same purpose, but uses IETF-style address information. [LDUP Info] An Update Vector describes the point to which the Replica has been updated, in respect to all the other Replicas of the Naming Context. The vector is used at the initiation of a replication session to determine the sequence of updates that should be transferred. The intent is to enable distributed operations in LDAP with the replica information stored there, but not to complete the process of turning LDAP into a fully distributed service. 5.5 Lost and Found Entry When replicating operations between servers, conflicts may arise that cause a parent entry to be removed causing its child entries to become orphaned. In this case the Update Resolution Procedures will make the Lost and Found Entry the child’s new superior. Each Replica Entry names it’s Lost and Found Entry, which would usually be an entry below the Replica Entry itself. This well known place allows administrators, and their tools, to find and repair abandoned entries. 5.6 Replication Agreement Object Class and Entries The Replication Agreement defines: 1. The schedule for Replication Sessions initiation. 2. The server that initiates the Replication Session, either the Consumer or the Supplier. 3. The authentication credentials that will be presented between servers. Merrells, Reed, Srinivasan [Page 18] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 4. The network/transport security scheme that will be employed in order to ensure data confidentiality. 5. The replication protocols and relevant protocol parameters to be used for Full and Incremental updates. An OID is used to identify the update transfer protocol, thus allowing for future extensions or bilaterally agreed upon alternatives. 6. If the Replica is Fractional, the Fractional Entry Specification. Permission to participate in replication sessions will be controlled, at least in part, by the presence and content of replica agreements. The Supplier must be subject to the access control policy enforced by the Consumer. Since the access control policy information is stored and replicated as directory content, the access control imposed on the Supplier by the Consumer must be stored in the Consumer's Replication Agreement. 5.6.1 Replication Schedule There are two broad mechanisms for initiating replication sessions: (1) scheduled event driven and (2) change event driven. The mechanism used to schedule replication operations between two servers is determined by the Schedule information that is part of the Replication Agreement governing the Replicas on those two servers. Because each Replication Agreement describes the policy for one direction of the relationship, it is possible that events propagate via scheduled events in one direction, and by change events in the other. Change event driven replication sessions are, by their nature, initiated by suppliers of change information. The server, which the change is made against, schedules a replication session in response to the change itself, so that notification of the change is passed on to other Replicas. Scheduled event driven replication sessions can be initiated by either consumers or suppliers of change information. The schedule defines a calendar of time periods during which Replication Sessions should be initiated. Schedule information may include both scheduled and change event driven mechanisms. For instance, one such policy may be to begin replication within 15 seconds of any change event, or every 30 minutes if no change events are received. Merrells, Reed, Srinivasan [Page 19] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 6. Policy Information Administrative policy information governs the behavior of the server This policy information needs to be consistently known and applied by all replicas of a Naming Context. It may be represented in the DIT as sub-entries, attributes, and attribute values. As such, the Naming Context Auxiliary Class provides a convenient way to define attributes which can communicate those policies among all replicas and users of the directory. When replicating a naming context that is itself a subtree of another naming context, there may be policy information stored in its antecedent entries. The most common examples are prescriptive access control information and inherited schema definition. Implementations may also define other policy attributes, or sub-entries, that apply to a whole subtree. For a naming context to be faithfully reproduced, this generational information must also be replicated. In all cases the policy information is transmitted as if it were an element of the Replica root entry. Policy information is always replicated in the same manner as any other entries, attributes, and attribute values. 6.1 Access Control The Access Control Models supported by a server are identified by the 'accessControlScheme' multi-valued attribute of the Root DSE entry. Each model is assigned an OID so that Consumers and Suppliers can determine if their access control policy will be faithfully imposed when replicated. An access control policy must be consistently applied by all servers holding replicas of the same Naming Context. Therefore, the Access Control Policy attribute is to be an operational attribute of the Naming Context Auxiliary Class. Thus, any consumer of the directory, and any server which would replicate a Naming Context, will know that an Access Control Policy is defined for the Naming Context, and by reference to the OID value of this attribute, know what policy mechanism to invoke to enforce that policy. Administrators are strongly cautioned against placing replicas of naming contexts on servers that cannot enforce the policy required by the Access Control Policy OID. Servers should refuse to accept replicas with policies they are unable to properly interpret. Merrells, Reed, Srinivasan [Page 20] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 6.2 Schema Knowledge Schema subentries should be subordinate to the naming contexts to which they apply. Given our model, a single server may hold replicas of several naming contexts. It is therefore essential that schema should not be considered to be a server-wide policy, but rather to be scoped by the namespace to which it applies. Schema modifications replicate in the same manner as other directory data. Given the strict ordering of replication events, schema modifications will naturally be replicated prior to entry creations which use them, and subsequent to data deletions which eliminate references to schema elements to be deleted. Servers should not replicate information about entries which are not defined in the schema. Servers should not replicate modifications to existing schema definitions for which there are existing entries and/or attributes which rely on the schema element. Should a schema change cause an entry to be in violation of the new schema, it is recommended that the server preserve the entry for administrative repair. The server could add a known object class to make the entry valid and to mark the entry for maintenance. 7. LDUP Update Transfer Protocol Framework A Replication Session occurs between a Supplier server and Consumer server over an LDAP connection. This section describes the process by which a Replication Session is initiated, started and stopped. The session initiator, termed the Initiator, could be either the Supplier or Consumer. The Initiator sends an LDAP extended operation to the Responder identifying the replication agreement being acted on. The Supplier then sends a sequence of updates to the Consumer. All transfers are in one direction only. A two way exchange requires two replication sessions; one session in each direction. 7.1 Replication Session Initiation The Initiator starts the Replication Session by opening an LDAP connection to its Responder. The Initiator binds using the authentication credentials provided in the Replication Agreement. The extended LDAP operation Start Replication is then sent by the Initiator to the Responder. This operation identifies which role each server will perform, and what type of replication is to be performed. Merrells, Reed, Srinivasan [Page 21] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 One server is to be the Consumer, the other the Supplier, and the replication may be either Full or Incremental. If the Responder does not support the requested type of replication then an error is returned. 7.1.1 Authentication The initiation of a Replication Session is to be restricted to only permitted clients. The identity and credentials of a connected server are determined via the bind operation. Access control on the Replication Agreement determines if the Replication Session may proceed. Otherwise, the insufficientAccessRights error is returned. 7.1.2 Consumer Initiated The Consumer binds to the Supplier using the authentication credentials provided in the Replication Agreement. The Consumer sends the Start Replication extended request to begin the Replication Session. The Supplier returns a Start Replication extended response containing a response code. The Consumer then disconnects from the Supplier. If the Supplier has agreed to the replication session initiation, it binds to the Consumer and behaves just as if the Supplier initiated the replication. 7.1.3 Supplier Initiated The Supplier binds to the Consumer using the authentication credentials provided in the Replication Agreement. The Supplier sends the Start Replication Request extended request to begin the Replication Session. The Consumer returns a Start Replication extended response containing a response code, and possibly its Update Vector. If the Consumer has agreed to the Replication Session initiation, then the transfer protocol begins. 7.2 Start Replication Session 7.2.1 Start Replication Request The LDUP Protocol document [LDUP Protocol] defines an LDAP Extended Request, Start Replication Request, that is sent from the Initiator to the Responder. The parameters of the Start Replication Request include: the Distinguished Name of the entry at the root of the Naming Context, the Replica Identifier of the Initiator, the Update Transfer Protocol OID, Replica Number Table, and an Ordering flag. Merrells, Reed, Srinivasan [Page 22] Expires 22 March 2000 --------------669A73EF38F256CED4313CBC-- From owner-ietf-ldup@imc.org Fri Oct 22 15:54:22 1999 Received: from mail.imc.org (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04069 for ; Fri, 22 Oct 1999 15:54:21 -0400 (EDT) Received: (from majordomo@localhost) by mail.imc.org (8.9.3/8.9.3) id LAA23931 for ietf-ldup-bks; Fri, 22 Oct 1999 11:02:30 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id LAA23927 for ; Fri, 22 Oct 1999 11:02: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 LAA09954 for ; Fri, 22 Oct 1999 11:04:42 -0700 (PDT) Received: from netscape.com ([208.12.63.197]) by tintin.mcom.com (Netscape Messaging Server 4.1) with ESMTP id FK0NJV00.EOJ for ; Fri, 22 Oct 1999 11:04:43 -0700 Message-ID: <3810A6B3.E2D6024C@netscape.com> Date: Fri, 22 Oct 1999 11:02:27 -0700 From: merrells@netscape.com (John Merrells) Organization: Netscape Communications X-Mailer: Mozilla 4.6 [en]C-NSCP (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: LDUP Subject: ldup arch draft - part 2 of 2 Content-Type: multipart/mixed; boundary="------------6C5050DB3DDE15703861E574" Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------6C5050DB3DDE15703861E574 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------6C5050DB3DDE15703861E574 Content-Type: text/plain; charset=iso-8859-1; name="draft-ietf-ldup-model-02-part2.txt" Content-Disposition: inline; filename="draft-ietf-ldup-model-02-part2.txt" Content-Transfer-Encoding: 8bit INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 The DN and Replica Identifier allow the Responder to determine which Replication Agreement is being acted on. The Update Transfer Protocol OID identifies the Update Transfer Protocol that the Initiator wishes to be used. This document defines two Protocols, one for full update and one for incremental update. The Replica Number Table provides a mapping from Replica Identifiers (the RDN of the Replica Sub-Entry) to Replica Numbers (a small integer). The Supplier sends Replica Numbers instead of Replica Identifiers to reduce network bandwidth requirements. The Supplier server uses the Ordering flag to inform the Consumer of the ordering of the Replication Update sequence transferred during the Replication Session. The Consumer can make use of this knowledge should the session be interrupted. 7.2.2 Start Replication Response The LDUP Protocol document [LDUP Protocol] defines an LDAP Extended Response, Start Replication Response, that is sent in reply to a Start Replication Request, from the Responder to the Initiator. The parameters of the Start Replication Response include an response code, and an optional Update Vector. 7.2.3 Consumer Initiated, Start Replication Session The Supplier Responder need not return its Update Vector to the Consumer Initiator, as it is not needed in this case. 7.3 Update Transfer Each Update Transfer Protocol is identified by an OID. An LDUP conformant server implementation must support the two update protocols defined here, and may support many others. A server will advertise its protocols in the Root DSE multi-valued attribute 'supportedReplicationProtocols'. The details of the two mandatory to implement protocols are defined by the LDUP Protocol Internet Draft [LDUP Protocol]. One protocol provides a Full Update for initialisation and re-initialisation of a replica, and the other protocol maintains that replica via an Incremental Update. Merrells, Reed, Srinivasan [Page 23] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 7.4 End Replication Session A Replication Session is terminated by the Supplier by sending an End Replication LDAP extended request, see section 7.4.1. The purpose of the request and response operations is to carry the Update Vector from the Supplier to the Consumer in the Full Update case, and to convey the Update Vector from the Consumer to the Supplier in the Incremental Update case. 7.4.1 End Replication Request The LDUP Protocol document [LDUP Protocol] defines an LDAP Extended Request, End Replication Request, that is sent from the Initiator to the Responder. The End Replication Request includes a flag for the Supplier to request the Consumers Update Vector. When the update has completed the Supplier sends this extended request to inform the Consumer that all updates have been sent, and to advise the Consumer if its Update Vector should be returned. 7.4.2 End Replication Response The LDUP Protocol document [LDUP Protocol] defines an LDAP Extended Response, End Replication Response, that is sent in reply to an End Replication Request, from the Responder to the Supplier. The Response can optionally include an Update Vector. If the ‘return update vector’ flag in the request was set then the Consumer should return its Update Vector to the Supplier. 7.5 Integrity & Confidentiality Data integrity (ie, protection from unintended changes) and confidentiality (ie, protection from unintended disclosure to eavesdroppers) SHOULD be provided by appropriate selection of underlying transports, for instance TLS, or IPSEC. Replication MUST be supported across TLS LDAP connections. Servers MAY be configured to refuse replication connections over unprotected TCP connections. 8. LDUP Update Protocols This Internet-Draft defines two transfer protocols for the supplier to push changes to the consumer. Other protocols could be defined to Merrells, Reed, Srinivasan [Page 24] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 transfer changes, including those which pull changes from the supplier to the consumer, but those are left for future work. 8.1 Replication Updates and Update Primitives Both LDUP Update Protocols define how Replication Updates are transferred from the Supplier to the Consumer. Each Replication Update consists of a set of Update Primitives that describe the state changes that have been made to a single entry. Each Replication Update contains a single Unique Identifier that addresses the entry to which the Update Primitives are to be applied. There are seven types of Update Primitive each of which codifies an assertion about the state of an entry. They assert the presence or absence of an entry, the name of the entry, the presence or absence of its attributes, and the presence or absence its attribute values. An assertion based approach has been chosen so that the Primitives are idempotent. Meaning that re-application of a Primitive to an Entry will cause no change to the entry. This is desirable as it provides some resilience against some kinds of system failures. Each Update Primitive contains a CSN that denotes the unique point in the total ordering of primitives that this primitive appears. The Supplier maps the Replica Identifier component of the CSN onto a Replica Number before transmission. The Consumer uses the provided Replica Number Table to map this back onto the Replica Identifier. The Update Primitives are fully defined in the LDUP Update Reconciliation Procedures Internet Draft [LDUP URP]. 8.2 Fractional Updates When fully populating or incrementally bringing up to date a Fractional Replica each of the Replication Updates must only contain updates to the attributes in the Fractional Entry Specification. 9. LDUP Full Update Transfer Protocol 9.1 Supplier Initiated, Full Update, Start Replication Session The Consumer Responder need not return its Update Vector to the Supplier Initiator, as it is not needed in this case. Merrells, Reed, Srinivasan [Page 25] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 9.2 Full Update Transfer This Full Update Protocol provides a bulk transfer of the replica contents for the initial population of new replicas, and the refreshing of existing replicas. The Consumer must replace its entire replica contents with that sent from the Supplier. The Consumer need not service any requests for this Naming Context whilst the full update is in progress. The Consumer could return a referral to another replica, possibly the supplier. [REF] 9.3 Replication Update Generation The entire state of a Replicated Area can be mapped onto a sequence of Replication Updates, each of which contains a sequence of Update Primitives that describe the entire state of a single entry. The sequence of Replication Updates must be ordered such that no entry is created before its parent. 9.4 Replication Update Consumption A Consumer will receive the Replication Updates, extract the sequence of Update Primitives, and must apply them to the DIB in the order provided. 9.5 Full Update, End Replication Session Since the Full Update also replicates the sub-entry that represents the Supplier Replica the Consumer will have received the Update Vector that represents the update state of the Consumer. After a Full Update transfer the Supplier sends the Update Vector that reflects the update state of the full replica information sent. The Consumer records this as its Update Vector. The Supplier could be accepting updates whilst the update is in progress. Once the Full Update has completed, an Incremental Update should be performed to transfer these changes. Merrells, Reed, Srinivasan [Page 26] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 9.6 Interrupted Transmission If the Replication Session terminates before the End Replication Request is sent, then the Replica is invalid and must be re- initialised. The Consumer must not permit LDAP Clients to access the incomplete replica. The Consumer could refer the Client to the Supplier Replica, or return an error result code. 10. LDUP Incremental Update Transfer Protocol For efficiency, the Incremental Update Protocol transmits only those changes that have been made to the Supplier replica that the Consumer has not already received. In a replication topology with transitive redundant replication agreements, changes may propagate through the replica network via different routes. The Consumer must not support multiple concurrent replication sessions with more than one Supplier for the same Naming Context. A Supplier that attempts to initiate a Replication Session with a Consumer already participating as a Consumer in another Replication Session will receive the busy error code. 10.1 Update Vector The Supplier uses the Consumer's Update Vector to determine the sequence of updates that should be sent to the Consumer. Each Replica entry includes an Update Vector to record the point to which the replica has been updated. The vector is a set of CSN values, one value for each known updateable Replica. Each CSN is the most recent change, made at that Replica, that has been replicated to this Replica. For example, consider two updatable replicas of a naming context, one is assigned replica identifier ‘1’, the other replica identifier ‘2’. Each is responsible for maintaining its own update vector, which will contain two CSNs, one for each replica. So, if both replicas are identical they will have equivalent update vectors. Both Update Vectors = {1998081018:44:31z#0x000F#1#0x0000, 1998081018:51:20z#0x0001#2#0x0000} Subsequently, at 7pm, an update is applied to replica ‘2’, so its update vector is updated. Merrells, Reed, Srinivasan [Page 27] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 Replica ‘1’ Update Vector = {1998081018:44:31z#0x000F#1#0x0000, 1998081018:51:20z#0x0001#2#0x0000} Replica ‘2’ Update Vector = {1998081018:44:31z#0x000F#1#0x0000, 1998081019:00:00z#0x0000#2#0x0000} Since the Update Vector records the state to which the replica has been updated, a supplier server, during Replication Session initiation, can determine the sequence of updates that should be sent to the consumer. From the example above no updates need to be sent from replica ‘1’ to replica ‘2’, but there is an update pending from replica ‘2’ to replica ‘1’. Because the Update Vector embodies knowledge of updates made at all known replicas it supports replication topologies that include transitive and redundant connections between replicas. It ensures that changes are not transferred to a consumer multiple times even though redundant replication agreements may exist. It also ensures that updates are passed across the replication network between replicas that are not directly linked to each other. It may be the case that a CSN for a given replica is absent, for one of two reasons. 1. CSNs for Read-Only replicas might be absent because no changes will have ever been applied to that Replica, so there are no changes to replicate. 2. CSNs for newly created replicas may be absent because no changes to that replica have yet been propagated. An Update Vector might also contain a CSN for a replica that no longer exists. The replica may have been temporarily taken out of service, or may have been removed from the replication topology permanently. An implementation may choose to retire a CSN after some configurable time period. 10.2 Supplier Initiated, Incremental Update, Start Replication Session The Consumer Responder must return its Update Vector to the Supplier Initiator. The Supplier uses this to determine the sequence of Replication Updates that need to be sent to the Consumer. Merrells, Reed, Srinivasan [Page 28] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 10.3 Replication Update Generation The Supplier generates a sequence of Replication Updates to be sent to the consumer. To enforce LDAP Constraint 20.1.6, that the LDAP Modify must be applied atomically, each Replication Update must contain the entire sequence of Update Primitives for all the LDAP Operations for which the Replication Update contains Update Primitives. Stated less formally, for each primitive the update contains, it must also contain all the other primitives that came from the same operation. 10.3.1 Replication Log Implementation A log-based implementation might take the approach of mapping LDAP Operations onto an equivalent sequence of Update Primitives. A systematic procedure for achieving this is fully described in the LDUP Update Reconciliation Procedures Internet Draft [LDUP URP]. The Consumer Update Vector is used to determine the sequence of LDAP Operations in the operation log that the Consumer has not yet seen. 10.3.2 State-Based Implementation A state-based implementation might consider each entry of the replica in turn using the Update Vector of the consumer to find all the state changes that need to be transferred. Each state change (entry, attribute, or value - creation, deletion, or update) is mapped onto the equivalent Update Primitive. All the Update Primitives for a single entry might be collected into a single Replication Update. Consequently, it could contain the resultant primitives of many LDAP operations. 10.4 Replication Update Consumption A Consumer will receive Replication Updates, extract the sequence of Update Primitives, and must apply them to the DIB in the order provided. LDAP Constraint 20.1.6 states that the modifications within an LDAP Modify operation must be applied in the sequence provided. Those Update Primitives must be reconciled with the current replica contents and any previously received updates. In broad outline, updates are compared to the state information associated with the item being operated on. If the change has a more recent CSN, then it is applied to the directory contents. If the change has an older CSN it is no longer relevant and its change must not be effected. Merrells, Reed, Srinivasan [Page 29] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 If the consumer acts as a supplier to other replicas then the updates are retained for forwarding. 10.5 Update Resolution Procedures The LDAP Update Operations must abide by the constraints imposed by the LDAP Data Model and LDAP Operational Behaviour, Appendix B. An operation that would violate at least one of these constraints is rejected with an error result code. The loose consistency model of this replication architecture and its support for multiple updateable replicas of a naming context means that LDAP Update Operations may be accepted at one replica, which would not be at another. At the time of acceptance, the accepting replica may not have received other updates that would cause a constraint to be violated, and the operation to be rejected. Replication Updates must never be rejected because of a violation of an LDAP Constraint. If the result of applying the Replication Update causes a constraint violation to occur, then some remedial action must be taken to satisfy the constraint. These Update Resolution Procedures are introduced here, and fully described in the LDAP Update Resolution Procedures Internet-Draft [LDUP URP]. 10.5.1 URP: Distinguished Names LDAP Constraints 20.1.1 and 20.1.10 ensure that each entry in the replicated area has a unique DN. A Replication Update could violate this constraint producing two entries, with different unique identifiers, but with the same DN. The resolution procedure is to rename the most recently named entry so that its RDN includes its own unique identifier. This ensures that the new DN of the entry shall be unique. 10.5.2 URP: Orphaned Entries LDAP Constraints 20.1.11 ensures that every entry must have a parent entry. A Replication Update could violate this constraint producing an entry with no parent entry. The resolution procedure is to create a Glue Entry to take the place of the absent parent. The Glue Entry’s superior will be the Lost and Found Entry. This well known place allows administrators and their tools to find and repair abandoned entries. Merrells, Reed, Srinivasan [Page 30] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 10.5.3 URP: Distinguished Not Present LDAP Constraints 20.1.8 and 20.1.9 ensure that the components of an RDN appear as attribute values of the entry. A Replication Update could violate this constraint producing an entry without its distinguished values. The resolution procedure is to add the missing attribute values, and mark them as distinguished not present, so that they can be deleted when the attribute values are no longer distinguished. 10.5.4 URP: Schema - Single Valued Attributes LDAP Constraint 20.1.7 enforces the single-valued attribute schema restriction. A Replication Update could violate this constraint creating a multi-value single-valued attribute. The resolution procedure is to consider the value of a single-valued attribute as always being equal. In this way the most recently added value will be retained, and the older one discarded. 10.5.5 URP: Schema - Required Attributes LDAP Constraint 20.1.7 enforces the schema objectclass definitions on an entry. A Replication Update could violate this constraint creating an entry that does not have attribute values for required attributes. The resolution procedure is to ignore the schema violation and mark the entry for administrative repair. 10.5.6 URP: Schema - Extra Attributes LDAP Constraint 20.1.3 and 20.1.7 enforces the schema objectclass definitions on an entry. A Replication Update could violate this constraint creating an entry that has attribute values not allowed by the objectclass values of the entry. The resolution procedure is to ignore the schema violation and mark the entry for administrative repair. 10.5.7 URP: Duplicate Attribute Values LDAP Constraint 20.1.5 ensures that the values of an attribute constitute a set of unique values. A Replication Update could violate this constraint. The resolution procedure is to enforce this constraint, recording the most recently assigned CSN with the value. Merrells, Reed, Srinivasan [Page 31] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 10.5.8 URP: Ancestry Graph Cycle LDAP Constraint 20.4.2.1 prevents against a cycle in the DIT. A Replication Update could violate this constraint causing an entry to become it’s own parent, or for it to appear even higher in it’s ancestry graph. The resolution procedure is to break the cycle by changing the parent of the entry closest to be the lost and found entry. 10.6 Incremental Update, End Replication Session If the Supplier sent none of its own updates to the Consumer, then the Supplier's CSN within the Supplier's update vector should be updated with the earliest possible CSN that it could generate, to record the time of the last successful replication session. The Consumer will have received the Supplier's Update Vector in the replica sub-entry it holds for the Supplier replica. The Consumer's resultant Update Vector CSN values will be at least as great as the Supplier's Update Vector. The Supplier may request that the Consumer return its resultant Update Vector so that the Supplier can update its replica sub-entry for the Consumer Replica. The Supplier requests this by setting a flag in the End Replication Request. The default flag value is TRUE meaning the Consumer Update Vector must be returned. 10.7 Interrupted Transmission If the Replication Session terminates before the End Replication Request is sent then the Consumer’s Update Vector may or may not be updated to reflect the updates received. The Start Replication request includes a Replication Update Ordering flag which states whether the updates were sent in CSN order per replica. If updates are sent in CSN order per replica then it is possible to update the Consumer Update Vector to reflect that some portion of the updates to have been sent have been received and successfully applied. The next Incremental Replication Session will pick up where the failed session left off. If updates are not sent in CSN order per replica then the Consumer Update can not be updated. The next Incremental Replication Session will begin where the failed session began. Some updates will be replayed, but because the application of Replication Updates is idempotent they will not cause any state changes. Merrells, Reed, Srinivasan [Page 32] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 11. Purging State Information The state information stored with each entry need not be stored indefinitely. A server implementation may choose to periodically, or continuously, remove state information that is no longer required. The mechanism is implementation-dependent, but to ensure interoperability between implementations, the state information must not be purged until all known replicas have received and acknowledged the change associated with a CSN. This is determined from the Purge Vector [11.1]. All the CSNs stored that are lower than the Purge Vector may be purged, because no changes with older CSNs can be replicated to this replica. 11.1 Purge Vector The Purge Vector is an Update Vector constructed from the Update Vectors of all known replicas. Each replica has a sub-entry for each known replica stored below its naming context. Each of those entries contains the last known update vector for that replica. The lowest CSN for each replica are taken from these update vectors to form the Purge Vector. The Purge Vector is used to determine when state information and updates need no longer be stored. 11.2 Purging Deleted Entries, Attributes, and Attribute Values The following conditions must hold before an item can be deleted from the Directory Information Base. 1) The LDAP delete operation has been propagated to all replication agreement partners. 2) All the updates from all the other replicas with CSNs less than the CSN on the deletion have been propagated to the server holding the deleted entry (similarly for deleted attributes and attribute values). 3) The CSN generator of the other Replicas must have advanced beyond the deletion CSN of the deleted entry. Otherwise, it is possible for one of those Replicas to generate operations with CSNs earlier than the deleted entry. Merrells, Reed, Srinivasan [Page 33] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 12. Replication Configuration and Management Replication management entries, such as replica or replication agreement entries, can be altered on any updateable replica. These entries are implicitly included in the directory entries governed by any agreement associated with this naming context. As a result, all servers with a replica of a naming context will have access to information about all other replicas and associated agreements. The deployment and maintenance of a replicated directory network involves the creation and management of all the replicas of a naming context and replication agreements among these replicas. This section outlines, through an example, the administrative actions necessary to create a new replica and establish replication agreements. Typically, administrative tools will guide the administrator and facilitate these actions. The objective of this example is to illustrate the architectural relationship among various replication related operational information. A copy of an agreement should exist on both the supplier and consumer side for the replication update transfer protocol to be able to start. For this purpose, the root of the naming context, replica objects and the replication agreement objects are created first on one of the servers. A copy of these objects are then manually created on the second server associated with the agreement. The scenario below starts with a server (named DSA1) that holds an updateable replica of a naming context NC1. Procedures to establish an updateable replica of the naming context on a second server (DSA2) are outlined. On DSA1: 1) Add the context prefix for NC1 to the Root DSE attribute 'replicaRoot' if it does not already exist. 2) Alter the 'ObjectClass' attribute of the root entry of NC1 to include the "namingContext" auxiliary class. 3) Create a replica object, NC1R1, (as a child of the root of NC1) to represent the replica on DSA1. The attributes include replica type (updateable, read-only etc.) and DSA1 access point information. 4) Create a copy of the replica object NC1R2 (after it is created on DSA2) 5) Create a replication agreement, NC1R1-R2 to represent update transfer from NC1R1 to NC1R2. This object is a child of NC1R1. Merrells, Reed, Srinivasan [Page 34] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 On DSA2: 1) Add NC1's context prefix to the Root DSE attribute 'replicaRoot'. 2) Create a copy of the root entry of NC1 as a copy of the one in DSA1 (including the namingContext auxiliary class) 3) Create a copy of the replica object NC1R1 4) Create a second replica object, NC1R2 (as a sibling of NC1R1) to represent the replica on DSA2. 5) Create a copy of the replication agreement, NC1R1-R2 6) Create a replication agreement, NC1R2-R1, to represent update transfer from NC1R2 to NC1R1. This object is a sibling of NC1R1- R2. After these actions update transfer to satisfy either of the two agreements can commence. If data already existed in one of the replicas, the update transfer protocol should perform a complete update of the data associated with the agreement before normal replication begins. 13. Time The server assigns a CSN for every LDAP update operation it receives. Since the CSN is principally based on time, the CSN is susceptible to the Replica clocks drifting in relation to each other (either forwards or backwards). The server must never assign a CSN older than or equal to the last CSN it assigned. The server must reject update operations, from any source, which would result in setting a CSN on an entry or a value which is earlier than the one that is there. The error code serverClocksOutOfSync (72) should be returned. Merrells, Reed, Srinivasan [Page 35] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 14. Security Considerations The preceding architecture discussion covers the server authentication, session confidentiality, and session integrity in sections 7.1.1 and 7.5 The internet draft "Authentication Methods" for LDAP, provides a detailed LDAP security discussion. Its introductory passage is paraphrased below. [AUTH] A Replication Session can be protected with the following security mechanisms. 1) Authentication by means of the SASL mechanism set, possibly backed by the TLS credentials exchange mechanism, 2) Authorization by means of access control based on the Initiators authenticated identity, 3) Data integrity protection by means of the TLS protocol or data- integrity SASL mechanisms, 4) Protection against snooping by means of the TLS protocol or data- encrypting SASL mechanisms, The configuration entries that represent Replication Agreements may contain authentication information. This information must never be replicated between replicas. Updates to a multi-mastered entry may collide causing the Update Resolution Procedures [10.5] to reject or reverse one of the changes to the entry. The URP algorithms resolve conflicts by using the total ordering of updates imposed by the assignment of CSNs for every operation. As a consequence updates originating from system administrators have no priority over updates originating from regular system users. 15. Acknowledgements This document is a product of the LDUP Working Group of the IETF. The contributions of its members is greatly appreciated. Merrells, Reed, Srinivasan [Page 36] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 16. References [AUTH] - M. Wahl, H. Alvestrand, J. Hodges, RL "Bob" Morgan, "Authentication Methods for LDAP", Internet Draft, draft-ietf-ldapext- authmeth-02.txt, June 1998. [BCP-11] - R. Hovey, S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. [LDAPv3] - M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access Protocol (v3)", RFC 2251, December1997. [LDUP Info.] - E. Reed, "LDUP Replication Information Model", Internet Draft, draft-reed-ldup-infomod-00-1.txt, August 1998. [LDUP Protocol] - G. Good, E. Stokes 'The LDUP Replication Update Protocol' , Internet Draft, draft-ietf-ldup-protocol-00.txt, May 1999. [LDUP Requirements] - R. Weiser, E. Stokes 'LDAP Replication Requirements', Internet Draft, draft-weiser-replica-req-02.txt, April 1998. [LDUP URP] - S. Legg 'LDUP Update Reconciliation Procedures', Internet Draft, draft-legg-ldup-urp-00.txt, February 1999. [NTP] - D. L. Mills, "Network Time Protocol (Version 3)", RFC 1305, March, 1992. [REF] - T. Howes, Mark Wahl, "Referrals and Knowledge References in LDAP Directories", Internet draft, draft-ietf-ldapext-referral-00.txt, March 1998. [RFC2119] - S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119. [RFC2252] - M. Wahl, A. Coulbeck, T. Howes, S. Kille, 'Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions', RFC 2252, December 1997. [SNTP] - D. L. Mills, "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030, University of Delaware, October 1996. [TLS] - J. Hodges, R. L. "Bob" Morgan, M. Wahl, "Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security", Internet draft, draft-ietf-ldapext-ldapv3-tls-01.txt, June 1998. Merrells, Reed, Srinivasan [Page 37] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 [UUID] - P. Leach, R. Salz, "UUIDs and GUIDs", Internet draft, draft- leach-uuids-guids-01.txt, February 1998. [X501] - ITU-T Recommendation X.501 (1993), ) | ISO/IEC 9594-2:1993, Information Technology - Open Systems Interconnection - The Directory: Models [X680] - ITU-T Recommendation X.680 (1994) | ISO/IEC 8824-1:1995, Information technology - Abstract Syntax Notation One (ASN.1): Specification of Basic Notation [X525] - ITU-T Recommendation X.525 (1997) | ISO/IEC 9594-9:1997, Information Technology - Open Systems Interconnection - The Directory: Replication 17. Intellectual Property Notice The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. [BCP-11] Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 18. Copyright Notice Copyright (C) The Internet Society (1998,1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and Merrells, Reed, Srinivasan [Page 38] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 19. Authors' Address John Merrells Netscape Communications, Inc. 501 East Middlefield Road Mountain View CA 94043 E-mail: merrells@netscape.com Phone: +1 650-937-5739 Edwards E. Reed Reed-Matthews, Inc. E-mail: eer@oncalldba.com Phone: +1 801-785-0315 Uppili Srinivasan Oracle, Inc. Redwood Shores E-mail: usriniva@us.oracle.com Phone: +1 650 506 3039 Merrells, Reed, Srinivasan [Page 39] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 LDUP Engineering Mailing List: ldup-repl@external.cisco.com LDUP Working Group Mailing List: ietf-ldup@imc.org 20. Appendix B - LDAP Constraints 20.1 LDAP Constraints Clauses This is an enumeration of the Data Model and Operation Behaviour constraint clauses defined in RFC 2251. [LDAPv3] 1) Data Model - Entries have names: one or more attribute values from the entry form its relative distinguished name (RDN), which MUST be unique among all its siblings. (p5) 2) Data Model - Attributes of Entries - Each entry MUST have an objectClass attribute. (p6) 3) Data Model - Attributes of Entries - Servers MUST NOT permit clients to add attributes to an entry unless those attributes are permitted by the object class definitions. (p6) 4) Relationship to X.500 - This document defines LDAP in terms of X.500 as an X.500 access mechanism. An LDAP server MUST act in accordance with the X.500 (1993) series of ITU recommendations when providing the service. However, it is not required that an LDAP server make use of any X.500 protocols in providing this service, e.g. LDAP can be mapped onto any other directory system so long as the X.500 data and service model as used in LDAP is not violated in the LDAP interface. (p8) 5) Elements of Protocol - Common Elements - Attribute - Each attribute value is distinct in the set (no duplicates). (p14) 6) Elements of Protocol - Modify Operation - The entire list of entry modifications MUST be performed in the order they are listed, as a single atomic operation. (p33) 7) Elements of Protocol - Modify Operation - While individual modifications may violate the directory schema, the resulting entry after the entire list of modifications is performed MUST conform to the requirements of the directory schema. (p33) 8) Elements of Protocol - Modify Operation - The Modify Operation cannot be used to remove from an entry any of its distinguished Merrells, Reed, Srinivasan [Page 40] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 values, those values which form the entry's relative distinguished name. (p34) 9) Elements of Protocol - Add Operation - Clients MUST include distinguished values (those forming the entry's own RDN) in this list, the objectClass attribute, and values of any mandatory attributes of the listed object classes. (p35) 10) Elements of Protocol - Add Operation - The entry named in the entry field of the AddRequest MUST NOT exist for the AddRequest to succeed. (p35) 11) Elements of Protocol - Add Operation - The parent of the entry to be added MUST exist. (p35) 12) Elements of Protocol - Delete Operation - ... only leaf entries (those with no subordinate entries) can be deleted with this operation. (p35) 13) Elements of Protocol - Modify DN Operation - If there was already an entry with that name [the new DN], the operation would fail. (p36) 14) Elements of Protocol - Modify DN Operation - The server may not perform the operation and return an error code if the setting of the deleteoldrdn parameter would cause a schema inconsistency in the entry. (p36) 20.2 LDAP Data Model Constraints The LDAP Data Model Constraint clauses as written in RFC 2251 [LDAPv3] may be summarised as follows. a) The parent of an entry must exist. (LDAP Constraint 11 & 12.) b) The RDN of an entry is unique among all its siblings. (LDAP Constraint 1.) c) The components of the RDN must appear as attribute values of the entry. (LDAP Constraint 8 & 9.) d) An entry must have an objectclass attribute. (LDAP Constraint 2 & 9.) e) An entry must conform to the schema constraints. (LDAP Constraint 3 & 7.) Merrells, Reed, Srinivasan [Page 41] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 f) Duplicate attribute values are not permitted. (LDAP Constraint 5.) 20.3 LDAP Operation Behaviour Constraints The LDAP Operation Behaviour Constraint clauses as written in RFC 2251 [LDAPv3] may be summarised as follows. A) The Add Operation will fail if an entry with the target DN already exists. (LDAP Constraint 10.) B) The Add Operation will fail if the entry violates data constraints: a - The parent of the entry does not exist. (LDAP Constraint 11.) b - The entry already exists. (LDAP Constraint 10.) c - The entry RDN components appear as attribute values on the entry. (LDAP Constraint 9.) d - The entry has an objectclass attribute. (LDAP Constraint 9.) e - The entry conforms to the schema constraints. (LDAP Constraint 9.) f - The entry has no duplicated attribute values. (LDAP Constraint 5.) C) The modifications of a Modify Operation are applied in the order presented. (LDAP Constraint 6.) D) The modifications of a Modify Operation are applied atomically. (LDAP Constraint 6.) E) A Modify Operation will fail if it results in an entry that violates data constraints: c - If it attempts to remove distinguished attribute values. (LDAP Constraint 8.) d - If it removes the objectclass attribute. (LDAP Constraint 2.) e - If it violates the schema constraints. (LDAP Constraint 7.) f - If it creates duplicate attribute values. (LDAP Constraint 5.) Merrells, Reed, Srinivasan [Page 42] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 F) The Delete Operation will fail if it would result in a DIT that violates data constraints: a - The deleted entry must not have any children. (LDAP Constraint 12.) G) The ModDN Operation will fail if it would result in a DIT or entry that violates data constraints: b - The new Superior entry must exist. (Derived LDAP Data Model Constraint A) c - An entry with the new DN must not already exist. (LDAP Constraint 13.) c - The new RDN components do not appear as attribute values on the entry. (LDAP Constraint 1.) d - If it removes the objectclass attribute. (LDAP Constraint 2.) e - It is permitted for the operation to result in an entry that violates the schema constraints. (LDAP Constraint 14.) 20.4 New LDAP Constraints The introduction of support for multi-mastered entries, by the replication scheme presented in this document, necessitates the imposition of new constraints upon the Data Model and LDAP Operation Behaviour. 20.4.1 New LDAP Data Model Constraints 1) Each entry shall have a unique identifier generated by the UUID algorithm available through the ‘entryUUID’ operational attribute. The entryUUID attribute is single valued. 20.4.2 New LDAP Operation Behaviour Constraints 1) The LDAP Data Model Constraints do not prevent cycles in the ancestry graph. Existing constraints Data Model Constraint - 20.4.1 - (a) and Operation Constraint - 20.4.2 - (B) would prevent this in the single master case, but not in the presence of multiple masters. Merrells, Reed, Srinivasan [Page 43] Expires 22 March 2000 INTERNET-DRAFT LDAP Replication Architecture October 22, 1999 2) The LDAP Data Model Constraints state that only the LDAP Modify Operation is atomic. All other LDAP Update Operations are also considered to be atomically applied to the DIB. Merrells, Reed, Srinivasan [Page 44] Expires 22 March 2000 --------------6C5050DB3DDE15703861E574-- From owner-ietf-ldup@imc.org Sun Oct 24 14:20:41 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11766 for ; Sun, 24 Oct 1999 14:20:40 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA07544 for ietf-ldup-bks; Sun, 24 Oct 1999 10:36:15 -0700 (PDT) Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA07539 for ; Sun, 24 Oct 1999 10:36:12 -0700 (PDT) Received: from alden ([10.128.167.143]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id TAA13367; Sun, 24 Oct 1999 19:38:02 +0200 Message-Id: <4.2.0.58.19991024193424.01cbf540@dokka.maxware.no> X-Sender: hta@dokka.maxware.no X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sun, 24 Oct 1999 19:40:11 +0200 To: directory@apps.ietf.org, ietf-ldapext@netscape.com, ietf-ldup@imc.org, namedroppers@internic.net, policy@raleigh.ibm.com From: Harald Tveit Alvestrand Subject: FYI: Directory definitions document Cc: iab@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: FYI, the following draft just came out: Title : Definitions for talking about directories Author(s) : H. Alvestrand Filename : draft-alvestrand-directory-defs-00.txt Pages : 6 Date : 21-Oct-99 When discussing systems for making information accessible through the Internet in standardized ways, it may be useful if the people discussing have a common understanding of the terms they use. This document is not intended to be either comprehensive or definitive, but is intended to give some aid in mutual comprehension when discussing information access methods to be incorporated into Internet Standards-Track documents. This is NOT intended to be a BOF in Washington, but I'd enjoy talking to people about it; its intended target is an informational IAB-sanctioned RFC. Keith Moore has suggested that "directory@apps.ietf.org" (open list, subscription at directory-request@apps.ietf.org) is an appropriate place to talk about this topic. Comments welcome! NOTE: This note is spread rather widely. Please do NOT reply to it, but rather to directory@apps.ietf.org or to me personally. Harald A -- Harald Tveit Alvestrand, Maxware, Norway Harald.Alvestrand@maxware.no From owner-ietf-ldup@imc.org Sun Oct 24 14:56:54 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12144 for ; Sun, 24 Oct 1999 14:56:53 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA07663 for ietf-ldup-bks; Sun, 24 Oct 1999 10:44:36 -0700 (PDT) Received: from monet.digsigtrust.com ([208.30.69.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA07659 for ; Sun, 24 Oct 1999 10:44:34 -0700 (PDT) Received: from digsigtrust.com (91.salt-lake-city-03-04rs.ut.dial-access.att.net [12.72.137.91]) by monet.digsigtrust.com (8.9.3/8.9.3) with SMTP id LAA22774; Sun, 24 Oct 1999 11:45:13 -0600 (MDT) Message-ID: <38134380.9E784F39@digsigtrust.com> Date: Sun, 24 Oct 1999 11:36:01 -0600 From: "Russel F. Weiser" X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ellen Stokes , internet-drafts@ietf.org, ietf-ldup@imc.org CC: Chris Apple , rvh@qsun.ho.att.com Subject: Revised Draft-ietf-ldup-replica-req-02.txt X-Priority: 1 (Highest) Content-Type: multipart/mixed; boundary="------------8E93B23E13618DC0FD3311B0" Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------8E93B23E13618DC0FD3311B0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I made several revisions that were requested and missed in the last revision. I hope that this will be accepted for last call if not I am also submitting it to the LDUP list for consideration to moving to LAST CALL as an information draft. cheers RFW --------------8E93B23E13618DC0FD3311B0 Content-Type: text/plain; charset=iso-8859-1; name="draft-ietf-ldup-replica-req-02.txt" Content-Disposition: inline; filename="draft-ietf-ldup-replica-req-02.txt" Content-Transfer-Encoding: 8bit INTERNET-DRAFT Russel F. Weiser Informational Draft Digital Signature Trust Co. Expires 21 April 2000 Ellen Stokes IBM 21 October 1999 LDAP V3 Replication Requirements Status of this Memo This document is am Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Drafts Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document discusses the fundamental requirements for replication of data accessible via the LDAPv3 [RFC2251] protocol. It is intended to be a gathering place for general replication requirements needed to provide interoperability between informational directories. The key words MUST, MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Weiser & Stokes 21 April 2000 [PAGE 1] INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 Table of Contents 1.Introduction.....................................................3 2. Terminology.....................................................3 3. Objective.......................................................5 4. Applicability Statement.........................................5 5. Replication Model..............................................10 6. Replication Protocol...........................................12 7. Schema.........................................................13 8. Administration and Management Considerations...................13 9. Acknowledgement................................................14 10. References....................................................15 11. Author's Address..............................................15 Weiser & Stokes 21 April 2000 [Page 2] INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 1. Introduction The ability to distribute directory information throughout the network provides a two fold benefit to the network: (1) increasing the reliability of the directory through fault tolerance, and (2) brings the directory content closer to the clients using the data. LDAP’s acceptance as an access protocol for directory information is driving the need to distribute LDAP directory content among servers within enterprise and Internet. Currently LDAP does not define a replication mechanism and only generally mentions LDAP shadow servers (see [RFC2251] and [Changelog]) in passing. The requirements for replication are critical to the successful deployment and acceptance of LDAP in the market place. 2. Terminology For the purposes of this document, the following terminology definitions are used: Area of replication - A whole or portion of a directory tree(DIT) making up a distinct unit of data to be replicated. This may also be known as "unit of replication". Atomic operation - The ability to treat and contain several updates or attribute changes as a single operation for replication purposes to guarantee that the several updates or attribute changes are propagated to a replica as a single unit. Authoritative Master Replica - The Primary updateable replica of the replicated information. Conflict resolution - Deterministic procedures within replication protocols, utilized to resolve change information conflicts that may arise due to conflicting changes affecting a directory entry. Fractional replication - The capability to replicate a subset of attributes of any given entry. Incremental Update - The process of updating a replica, or copy, of a naming context, by updating only those fields or objects which have changed. Master Slave, or Single Master Replication - Replication model that assumes only one server, the master, allows write access to the replicated data. Note that Master-Slave replication can be considered a proper subset of multi-master replication. Weiser & Stokes 21 April 2000 [Page 3] INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 Multi-Master Replication - A replication model where entries can be written and updated on any of several updateable replica copies without requiring communication with other updateable replicas before the write or update is performed. Naming Context - Suffix of a Sub-tree. A sub-tree of entries held in a single server [X.500]. One-way Replication - The process of synchronization in a single direction where the authoritative source information is provided to a replica. Partial Replication - The capability to replicate some subset of entries in a naming context. Propagation behavior - The general behavior of the actual synchronization process between a consumer and a provider of replication information. Read-only Replica - A read-only copy of a replicated directory. A read-only replica is assumed to be a slave replica of master slave or single master replication definition. Replica - A single instance of a whole or portion of the Directory tree (DIT) as defined by area of replication. Replica Ring - A set of servers, which hold in common the same DIT information as, defined by “Area of replication”. These servers may be managed under a single replication agreement that handles all members of the set of servers as a group. Replica Cycle - When a change or groups of changes need to be propagated to the other member of a replica ring. The process of contacting a replica member would be considered the beginning of a replication cycle; the termination of communications with a replica is the end of the cycle whether its due to an error or successful exchange of update records. Replication - The process of copying portions of naming context information and content between multiple LDAP servers, such that certain predefined portions of the information are available from different servers. Replication can occur between either homogeneous implementations across heterogeneous platforms (operating systems) or heterogeneous implementations supporting identical replication across heterogeneous platforms (operating systems). Sparse Replica - A incomplete copy of a sub-tree which maybe inclusive with updateable, or Read-only. See Partial replication and Weiser & Stokes 21 April 2000 [Page 4] INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 Fractional replication. Topology - Refers to the shape of the directed graph describing the relationships between replicas, as in the replicated directory topology. Two-way Replication - The process of synchronization where change information may flow bi-directionally between two replica. Update Propagation - Protocol-based process by which directory replicas are reconciled. Updateable Replica - A Non-authoritative read-writeable copy of the replicated information. Such that during conflict resolution a authoritative master takes precedents in resolving conflicts. 3. Objective The major objective is to provide an interoperable LDAP V3 directory synchronization protocol which is simple, highly efficient and flexible enough to support both multi-master and master-slave replication operations to meet the needs of both the internet and enterprise environments. 4. Applicability Statement Generally replication can be characterized by looking at data consistency models across existing technologies. This may provide insight to LDAP v3 replication requirements. The following is a brief examination of the following data models. Model 1: Tight Consistency -- Includes environments where all replicas must always contain exactly the same directory content. Two phase commit transaction models may be used to preserve transaction consistency. Model 2: Eventual Consistency or Transient Consistency -- Includes X.500 Directories, Bayou [XEROX], and NDS (Novell Directory Services) names service where definite knowledge of the global replica topology is provided through predetermined replication agreements. Such that every update propagates to every replica that it can reach via a path of stepwise eventual connectivity. Transaction consistency is preserved for transactions directed at the master server in X.500 implementations. NDS additionally provides deterministic consistency over time to all replicas due to its inherent replication policies. Weiser & Stokes 21 April 2000 [Page 5] INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 Model 3: Limited Effort Eventual Consistency -- Includes Xerox Clearinghouse [XEROX] that provides a statistical probability of convergence with global knowledge of replica topology. Similar to "Eventual Consistency", except where replicas may purge updates therefore dropping propagation changes when some replica time boundary is exceeded, thus leaving some changes replicated to a portion of the replica topology. Transactional consistency is not preserved, though some weaker constraints on consistency are available. Model 4: Loosest Consistency -- Includes opportunistic or simple cache where information is provided from the cache until stale. Model 5: Ad hoc -- A copy of a date store where no follow up checks are made for the accuracy/freshness of the data. Consistency models 2, and 3 involve the use of prearranged replication agreements or "Predefined Replication Agreements" between cooperating servers. The complexity of Model 1's use of 2- phase commit adds additional overhead that should not considered at this time. Models 4 and 5 involve unregistered replicas which "pull" updates from another directory server without that server's knowledge. These models can be considered to violate a directory's security policies. Therefore models 1, 4, and 5 are declared to be out of scope of this working group. So through further review of these consistency models two application areas can then be derived with even further characterizations of the data types usages. Eventual Consistency or Transient Consistency (Model 2) - This model provides policy configuration through security management parameters; the data is more dynamic and utilizes dynamic address information. Limited Effort Eventual Consistency (Model 3) - This model matches a white-pages environment which contains fairly static data and address information. This model mainly replicates message attributes. Therefore it is believed an LDAP replication should be flexible enough to cover the above range of capabilities. The generalized use of LDUP replication environment is to provide for the distribution of LDAP directory information in order to improve accessibility and consistency of the information held by the directory. 4.1 Replication Scenarios Weiser & Stokes 21 April 2000 [Page 6] INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 The following directory deployment examples are intended to substantiate and validate our replication requirements. It is assumed in all cases that directory implementations from different vendors are involved. 4.1.1 Extranet Example A company has a trading partner to whom it wishes to provide directory information. This information may be as simple as a corporate telephone directory, or as complex as an extranet work flow application. For performance reasons the company may wish to have a replica of its directory within the Partner Company, rather than simply exposed beyond its firewall. The requirements, which follow from this scenario, are: - One-way replication, single mastered. - Authentication of clients. - Common access control and access control identification. - Secure transmission of updates. - Selective attribute replication (Fractional Replication), so that only partial entries can be replicated. 4.1.2 Consolidation Example Company A acquires company B. In the transition period, whilst the organizations are merged, both directory services must coexist. Company A may wish to attach company B's directory to its own. The requirements, which follow from this scenario, are: - Multi-Master replication. - Common access control model. Access control model identification. - Secure transmission of updates. - Replication between DITs with potentially differing schema. 4.1.3 Replication Heterogeneous Deployment Example An organization may deliberately deploy multiple directory services within their enterprise to employ the differing benefits of each service. In this case multi-master replication will be required to ensure that the multiple updateable replicas of the DIT are synchronized. Some vendors may provide directory clients, which are tied to their own directory service. The requirements, which follow from this scenario, are: - Multi-Master replication Weiser & Stokes 21 April 2000 [Page 7] INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 - Common access control model and Access control model identification. - Secure transmission of updates. - Replication between DITs with potentially differing schemas. 4.1.4 Shared Name Space Example Two organizations may choose to cooperate on some venture and need a shared name space to manage their operation. Both organizations will require administrative rights over the shared name space. The requirements, which follow from this scenario, are: - Multi-Master replication. - Common access control model and Access control model identification. - Secure transmission of updates. 4.1.5 Supplier Initiated Replication A single master environment, which maintains a number of replicas of the DIT by pushing changes, based on a defined schedule. The requirements, which follow from this scenario, are: - Single-master environment. - Supplier-initiated replication. - Secure transmission of updates. 4.1.6 Consumer Initiated Replication Again a single mastered replication topology, but the replica initiates the replication exchange rather than the master. An example of this is a replica that resides on a laptop computer that may run disconnected for a period of time. The requirements, which follow from this scenario, are: - Single-master environment. - Consumer initiated replication. - Open scheduling (anytime). 4.1.7 Prioritized attribute replication The password attribute can provide an example of the requirement for prioritized attribute replication. A user is working in Utah and the administrator resides in California. The user has forgotten his password. So the user calls or emails the administrator to request a new password. The administrator provides the updated password (a change). Policy states that this attribute is critical and must be Weiser & Stokes 21 April 2000 [Page 8] INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 available to the user for login immediately (e.g. shortly) after the administrator changed it. Replication needs to occur immediately for critical attributes/objects. The requirements, which follow from this scenario, are: - Incremental replication of changes. - Automatic replication on change of certain attributes. - Replicate based on time/attribute semantics. 4.1.8 Bandwidth issues The replication of Server (A) R/W replica (a) in Katmandu is handled via a dial up phone link to Paris where server (B) R/W replica of (a) resides. Server (C) R/W replica of(a) is connected by a T1 connection to server (B). Each connection has a different performance characteristic. The requirements, which follow from this scenario, are: - Minimize repetitive updates when replicating from multiple replication paths. - Incremental replication of changes. - Provide replication cycles to delay and/or retry when connections can not be reached. - Allowances for consumer initiated or supplier initiated replication. 4.1.9 Interoperable Administration and Management The administrator with administrative authority of the corporate directory which is replicated by numerous geographically dispersed LDAP servers from different vendors notices that the replication process is not completing correctly as the change log is continuing to grow and/or error message informs him. The administrator uses his $19.95 RepCo LDAP directory replication diagnostics tools to look at Root DSE replica knowledge on server 17 and determines that server 42 made by LDAP’RUS Inc. is not replicating properly due to an Object conflict. Using his Repco Remote repair tools he connects to server 42 and resolves the conflict on the remote server. The requirements, which follow from this scenario, are: - Provides replication audit history. - Provisions for managing conflict resolution. - Provide LDAP access to predetermined agreements, topology and policy attributes. - Provide operations for comparing replica’s content for validity. - Provide LDAP access to status and audit information. Weiser & Stokes 21 April 2000 [Page 9] INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 4.1.10 Enterprise Directory Replication Mesh A Corporation builds a mesh of directory servers within the enterprise utilizing LDAP servers from various vendors. Five servers are holding the same area of replication. The predetermined replication agreement(s) for the enterprise mesh are under a single management, and the security domain allows a single predetermined replication agreement to manage the 5 servers replication. The requirements, which follow from this scenario, are: - Predefined replication agreements that manage more than a single area of replication that is held on numerous servers. - Common support of replication management knowledge across vendor implementation. - Rescheduling and continuation of a replication cycle when one server in a replica ring is busy and/or unavailable. 5. Replication Model 5.1 LDAP Replication MUST be allowed to span different vendors directory services in order to provide interoperability. 5.2 All replicas MUST eventually be updated with the changed information, if specified by the replication policy. 5.3 Replication schedules MUST be configurable to allow for periodic replication, with the replication period determined by administrator of the replicated system. 5.4 Replication Model MUST enable replication cycle to be initiated on change or based on the number of pending changes. 5.5 The replication model MUST allow for administrative initiation of replication cycle for any replica that may have just come back online or was during unavailable previously replication cycles. 5.6 The replication model MUST support both master-slave and authoritative multi-updateable replica relationships. 5.7 All replicated information between the master database and its replica databases MUST be identical including all non-user modify operational attributes such as time stamps. Note this does not imply that the entire database is identical from replica to replica, but that the subset of data, chosen to replicate is identical from replica to replica. Some operational attributes may be dynamically evaluated; these attributes will not necessarily appear to be identical. Weiser & Stokes 21 April 2000 [Page 10] INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 5.8 In distributed multi-vendor environment, LDAP replication MUST NOT require all copies of the replicated information be complete copies of the replicated object. 5.9 LDAP replication MUST encompass common schema objects and attributes, access control, and name space information. 5.10 Sub-tree Replication MUST be defined to allow for greater flexibility in replication topologies of the DIT as defined by the area of replication called partial replication. 5.11 Replication of critical values MUST be synchronized and have priority over non-critical values. An example of a critical value might be a password or certificate value. 5.12 Replication activities MUST occur within the context of a predefined replication agreement that addresses proper knowledge of access requirements and credentials between the synchronizing directories. Currently X.525 DISP [X.525] discusses this as a shadowing agreement including such information as unit of replication, update mode, and access point defining many of the policies between the master and a replica. 5.13 The acceptance and usage of the Internet requires that LDAP replication be available across disparate vendor directory services. 5.14 LDAP replication MUST provide scalability to both enterprise and Internet environments, e.g. an LDAP server may provide replication services to replicas within an enterprise as well as across the Internet. 5.15 The replication model MUST define deterministic policy such that replication cycle startup time conflicts between two or more competing master replicas may be resolved programmatically. An example might be automatic submission and rescheduling by one of the masters. In such a case, these replication "conflicts" MUST be resolved by the replication policy. 5.16 Any replication capable LDAP server MUST allow replication where the 2 replicating servers agree they can replicate. This may be accomplished through administrative agreements assuming compatible access control model and common schema are provided. 5.17 The replication model MUST be able to handle convergence and resurrection of attributes and objects. This is a consequence of delete and move with respect to the replication process. Weiser & Stokes 21 April 2000 [Page 11] INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 5.18 It is not realistic to assume that all vendors have cooperating schemas, but that replication may be allowed between diverse schema. The Model MAY allow for replication between divergent schema of objects. 6. Replication Protocol 6.1 The act of replication SHOULD have minimal impact on both the system and network performance. 6.2 The replica synchronization SHOULD be handled in such a manner as to not saturate network with repetitive entry replication from multiple synchronization providers points. 6.3 Replication MUST only be allowed after the authentication and verification of authorization of both the replica and the source directory. 6.4 The transport for LDAP synchronization MUST allow for the integrity and confidentiality of each replicated server. 6.5 Replicated data MUST be transferable in a secure manner. 6.6 Replication protocol MUST provide for recovery and rescheduling of a replication cycle due to a replication initiation conflicts (e.g. consumer busy replicating with other servers) and or loss of connection(e.g. supplier cannot reach a replica). The replication protocol MUST include restarting at the last acknowledged update prior to interruption rather than re-sending updates it had already sent to a consuming replica. 6.7 LDAP replication MUST allow for full update to facilitate replica initialization and reset loading utilizing a standardized format such as LDIF [LDIF] format. 6.8 The replication standard SHOULD NOT limit the size of a replica. The area of replication is defined to be a whole or portion of a DIT, also allowing a portion of a naming context to be replicated. Incremental replication SHOULD be allowed. 6.9 The replication agreements MUST accommodate multiple servers receiving the same replica under a single predefined agreement. 6.10 The replication protocol MUST allow either a master or replica to initiate the replication process. 6.11 Additionally the initiator MUST be allowed to determine whether it will become a consumer or supplier during the synchronization startup process. This would allow a replica to Weiser & Stokes 21 April 2000 [Page 12] INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 be periodically connected and synchronized from remote sites at the local administrator's discretion. 6.12 Multiple LDAP changes to a single server: If transactional consistency is propagated during replication, then multiple LDAP changes submitted to a single server SHOULD BE treated as a single 'atomic unit of work'. 6.13 An LDAP Replication Standard SHOULD NOT limit the transaction rate of a replication session. 6.14 Entry change information MUST be purged or discarded in a timely manner when change information becomes outdated due to propagated to all replica members. 7. Schema 7.1 Replica knowledge MUST be provided as DSE attributes. 7.2 The Replication Protocol documents MUST define standard schema for representing replication agreements, and MUST define the semantics associated with modifying the attributes of replication agreements. The documents MUST also define a standard method for determining the location of these agreements accessible utilizing LDAP. 7.3 The Replication Protocol documents MUST define standard schema for publishing state information about a given replica, and MUST define a standard method for determining the location of this information. 7.4 A location independent management point MUST be defined to provide authorized administrators with well known access to the replication policies, regardless of network location. 7.5 Replication agreements of all servers containing replicated information MUST be accessible via LDAP. 7.6 All objects MUST be uniquely identifiable throughout the object lifetime . 8. Administration and Management Considerations 8.1 Replication policies MUST allow replication of changed information to be administratively postponed to a more Weiser & Stokes 21 April 2000 [Page 13] INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 convenient period. 8.2 Allowance for non-scheduled replication of a replica MUST be provided upon request such that the replica server has been down or unconnected for a period of time. 8.3 Each copy of a replica MUST maintain audit history information of which servers it has replicated with and which servers have replicated with it. 8.4 A replica MUST store conflicted versions of the replicated object to allow optional human review and intervention. 8.5 Access to replication predetermined agreements, topologies, and policies attributes MUST be provided through LDAP access. 8.6 The capability to check the differences between two replicas for the same information SHOULD be provided for. This should entail a client invoking an operation at some server, which causes that server to extract the contents from some other server it has a replication agreement with and report the differences back to the client as the result. 8.7 Authenticated access SHOULD be provided so that Administrative LDAP clients may query a server for the current state and replication history for each replica that the server maintains replication agreements with. 8.8 The ability to view replication conflicts, and override the resolution derived by the replication policy MUST be provided. 8.9 The deletion of sensitive data MUST be handled in an orderly manner so that at no time will that data be available without proper access control. That is, access control information (ACI) associated with sensitive data must be deleted after or simultaneously with the delete of the sensitive data. Likewise, when adding sensitive data, ACI MUST be added first or simultaneously with the addition of that data. 9. Acknowledgement This document is based on input from IETF members interested in LDUP Replication. Weiser & Stokes 21 April 2000 [Page 14] INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 10. References [RFC2251] M. Wahl, T. Howes, S. Kille "Lightweight Directory Access Protocal", RFC 2251. [RFC2119] S.Bradner, " Key words for use in RFCs to indicate Requirement Levels", RFC 2119. [LDIF] Gordon Good, "The LDAP Data Interchange Format (LDIF)", Internet draft, draft-ietf-asid-ldif-00.txt, November 1996. [Changelog] Gordon Good, "Definitions of an Object Class to Hold LDAP Change records", Internet Draft, draft-ietf-asid-changelog- 00.txt, November 1996. [X.501] ITU-T Recommendation X.501 (1993), | ISO/IEC 9594-2: 1993, Information Technology - Open Systems Interconnection - The Directory: Models [XEROX] Hauser, C. "Managing update conflicts in Bayou, a weakly connected replicated storage system". Palo Alto, CA: Xerox PARC, Computer Science Laboratory; 1995 August; CSL-95-4. [CSL-95-04] 11. Author's Address Russel F. Weiser Digital Signature Trust Co. One South Main Street Salt Lake City, Utah 84111 USA E-mail: rweiser@digsigtrust.com Telephone: +1-801-983-4415 Fax +1-801-983-4408 Ellen J. Stokes IBM 11400 Burnet Rd. Austin, Texas 78758 USA E-mail: stokes@austin.ibm.com Telephone: +1-512-838-3725 Fax: +1-512-838-0156 Weiser & Stokes 21 April 2000 [Page 15] --------------8E93B23E13618DC0FD3311B0-- From owner-ietf-ldup@imc.org Mon Oct 25 00:43:18 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18840 for ; Mon, 25 Oct 1999 00:43:17 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA28115 for ietf-ldup-bks; Sun, 24 Oct 1999 21:09:28 -0700 (PDT) Received: from dir1.control.att.com ([135.207.251.15]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA28111 for ; Sun, 24 Oct 1999 21:09:27 -0700 (PDT) Received: from master.control.att.com (master.control.att.com [135.207.251.13]) by dir1.control.att.com (Postfix) with SMTP id C8A8571C2; Mon, 25 Oct 1999 00:16:37 -0400 (EDT) Date: Mon, 25 Oct 1999 00:13:22 -0400 (EDT) From: Chris Apple To: "Russel F. Weiser" Cc: Ellen Stokes , internet-drafts@ietf.org, ietf-ldup@imc.org, Chris Apple , rvh@qsun.ho.att.com Subject: Re: Revised Draft-ietf-ldup-replica-req-02.txt In-Reply-To: <38134380.9E784F39@digsigtrust.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ, Thanks! Since this made it in by the deadline, we'll talk about it at the meeting. The only step left is to mention that we plan to send it to the ADs to present for IESG consideration for an IETF Last Call of the document as a deliverable of the working group. We can deal with any remaining comments during IETF Last Call. Chris. On Sun, 24 Oct 1999, Russel F. Weiser wrote: > I made several revisions that were requested and missed in the last > revision. I hope that this will be accepted for last call if not I am > also submitting it to the LDUP list for consideration to moving to LAST > CALL as an information draft. > > cheers > RFW ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Service Internet Directory Group http://www.anywho.com AT&T Labs capple@control.att.com +1 973 236 6470 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ From owner-ietf-ldup@imc.org Mon Oct 25 04:36:11 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01400 for ; Mon, 25 Oct 1999 04:36:10 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id AAA00229 for ietf-ldup-bks; Mon, 25 Oct 1999 00:18:00 -0700 (PDT) Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA00221 for ; Mon, 25 Oct 1999 00:17:53 -0700 (PDT) Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id RAA06093 for ; Mon, 25 Oct 1999 17:20:20 +1000 (EST) Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpd0UGUa0; Mon Oct 25 17:19:42 1999 Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id RAA15749 for ; Mon, 25 Oct 1999 17:19:41 +1000 (EST) Received: from mail.cdn.telstra.com.au(144.135.138.138) via SMTP by maili.vtcif.telstra.com.au, id smtpd0aoXx4; Mon Oct 25 17:18:51 1999 Received: from bifrost.trl.oz.au (bifrost.trl.oz.au [137.147.242.75]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id RAA18231 for ; Mon, 25 Oct 1999 17:18:50 +1000 (EST) Received: from bifrost.trl.oz.au (bifrost.trl.oz.au [137.147.242.75]) by bifrost.trl.oz.au (8.8.8/8.6.12) with SMTP id RAA18387 for ; Mon, 25 Oct 1999 17:18:49 +1000 (EST) Message-Id: <199910250718.RAA18387@bifrost.trl.oz.au> Date: Mon, 25 Oct 1999 17:18:49 +1000 (EST) From: Steven Legg Reply-To: Steven Legg Subject: Latest Draft of URP To: ietf-ldup@imc.org MIME-Version: 1.0 Content-Type: MULTIPART/mixed; BOUNDARY=Drove_of_Sheep_422_000 X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4m sparc Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Drove_of_Sheep_422_000 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: MWmhLOZ1ShFBBe8lLGyQrw== All, Attached is a copy of the latest draft for URP. Go to section 12.2 for a summary of the changes since the previous draft. Regards, Steven Legg --Drove_of_Sheep_422_000 Content-Type: TEXT/plain; name="draft-ietf-ldup-urp-02.txt"; charset=us-ascii; x-unix-mode=0640 Content-Description: draft-ietf-ldup-urp-02.txt Content-MD5: KYJ9nwGrUELa2sOch4UAGQ== INTERNET-DRAFT S. Legg draft-ietf-ldup-urp-02.txt Telstra A. Payne PricewaterhouseCoopers October 22, 1999 LDUP Update Reconciliation Procedures Copyright (C) The Internet Society (1999). All Rights Reserved. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This draft is published by the IETF LDUP Working Group. Distribution of this document is unlimited. Comments should be sent to the LDUP Replication mailing list or to the authors. This Internet-Draft expires on 22 April 2000. 1. Abstract This document describes the procedures used by directory servers to reconcile updates performed by autonomously operating directory servers in a distributed, replicated directory service. Legg & Payne Expires 22 April 2000 [Page 1] INTERNET-DRAFT LDUP Update Reconciliation Procedures October 22, 1999 2. Table of Contents 1. Abstract 1 2. Table of Contents 2 3. Introduction 2 4. Model Extensions 3 4.1 Unique Identifier 3 4.2 Timestamps & Existence 3 4.3 Replication Primitives 4 4.4 Lost & Found 5 5. Replication Procedures 6 5.1 Processing LDAP, DAP or DSP Operations on the DIT 6 5.1.1 Add Entry 7 5.1.2 Remove Entry 7 5.1.3 Modify Entry 7 5.1.4 Modify DN 9 5.2 Generating Replication Primitives 9 5.3 Processing Replication Primitives on the DIT 11 5.3.1 Saving Deletion Records 12 5.3.2 Glue Entries 13 5.3.3 Generating Change Sequence Numbers 13 5.3.4 Comparison of Attribute Values 14 5.3.5 Entry Naming 14 5.3.6 Processing Add Attribute Value Primitive 17 5.3.7 Processing Remove Attribute Value Primitive 17 5.3.8 Processing Remove Attribute Primitive 19 5.3.9 Processing Add Entry Primitive 19 5.3.10 Processing Remove Entry Primitive 20 5.3.11 Processing Move Entry Primitive 21 5.3.12 Processing Rename Entry Primitive 22 6. Security Considerations 23 7. Acknowledgements 23 8. References 23 9. Intellectual Property Notice 23 10. Copyright Notice 24 11. Authors' Address 25 12. Appendix A - Changes From Previous Drafts 25 12.1 Changes in Draft 01 25 12.2 Changes in Draft 02 26 13. Appendix B - Open Issues 26 3. Introduction Each DAP, LDAP or DSP operation successfully performed by a DSA is subsequently reported to other DSAs with which it has a replication agreement as a set of one or more simple timestamped replication primitives. These primitives reflect the intended final state of an Legg & Payne Expires 22 April 2000 [Page 2] INTERNET-DRAFT LDUP Update Reconciliation Procedures October 22, 1999 update operation rather than the specific changes required to achieve that state. A DSA will receive replication primitives from its various agreement partners according to the agreement schedules. Those primitives must be reconciled with the current DSA contents. In broad outline, received replication primitives are compared to the timestamp information associated with the directory data item being operated on. If the primitive has a more recent timestamp a change in the directory contents is made (which may involve only the revision of the timestamp). If the DSA has other replication agreements then the change will be reflected in primitives sent during replication sessions for those other agreements. If the primitive has an older timestamp it is no longer relevant and is simply ignored. The update reconciliation procedures are designed to produce a consistent outcome at all participating DSAs regardless of the order in which the primitives are received. The primitives can also be safely replayed in the event that an exchange of replication information with another DSA is interrupted. This greatly simplifies the recovery mechanisms required in the replication protocol. 4. Model Extensions This section describes the extensions to the data model required to effect multiple master replication. 4.1 Unique Identifier A Unique Identifier is associated with each entry in the global DIT. This Unique Identifier must be globally unique for all time in the Directory. This can be achieved by defining a unique DSA prefix for each DSA and then ensuring that the suffix of the Unique Identifier is locally unique. Some pre-allocated global Unique Identifier values will be used to indicate the X.500 global root entry, and the Lost & Found entry (see Section 4.4). 4.2 Timestamps & Existence The timestamp for a replication primitive or directory data item is in the form of a Change Sequence Number (CSN). The components of the CSN are, from most significant to least significant, a time in seconds, a change count, a Replica Identifier and a modification number. Notionally a CSN is associated with an entry's Relative Distinguished Name (the Name CSN), the reference to its superior entry (the Parent CSN) and each of its attribute values (including Legg & Payne Expires 22 April 2000 [Page 3] INTERNET-DRAFT LDUP Update Reconciliation Procedures October 22, 1999 the distinguished values), to record the time of the most recent action on that part of the entry. The entry itself has a CSN (the Entry CSN) asserting the most recent time at which the entry was added. An entry is permitted to be removed and then re-added at one or more DSAs. In this context re- adding an entry means reusing the Unique Identifier of a removed entry and does not refer to the case of reusing the RDN of a removed entry. The reuse of a Unique Identifier can arise by the explicit action of a directory administrator to restore an entry that was mistakenly removed. The mechanism by which an administrator adds an entry with a reused Unique Identifier is outside the scope of the X.500 and LDAP standards since the Unique Identifier of an entry is not a user modifiable attribute. Note that from the perspective of a consumer DSA of a partial area of replication an entry may appear to be removed and added several times because modifications to the entry change whether the entry satisfies the replication agreement specification for the area of replication. Additionally, a deletion record is kept for each of the recently deleted entries, attributes, or attribute values. The deletion record contains a CSN and asserts that the associated directory object no longer existed at the particular time. 4.3 Replication Primitives Each update operation performed on an entry in a part of the DIT subject to one or more replication agreements must be subsequently reported as replication primitives to the replication partner DSAs of those agreements. The collection of primitives sent by a DSA to a replication partner may reflect both the results of locally processed user update requests and also of replicated updates received from other DSAs. A single update operation will decompose in one or more primitives. Common to all update primitives is an entry identifier argument, uid, containing the Unique Identifier of the target entry of the change, and a CSN argument, csn, to indicate the time of the change. In the case of adding a new entry, the Unique Identifier for the entry is allocated by the DSA in the course of processing the operation. Additional arguments are present depending on the type of replication primitive. The p-add-entry(uid, csn, superior, rdn) primitive is used to add a new entry with minimal contents. The superior argument contains the Unique Identifier of the immediate superior entry of the added entry. The rdn argument contains the Relative Distinguished Name of the added entry. Legg & Payne Expires 22 April 2000 [Page 4] INTERNET-DRAFT LDUP Update Reconciliation Procedures October 22, 1999 The p-move-entry(uid, csn, superior) primitive is used to change the immediate superior of an entry. The superior argument contains the Unique Identifier of the new superior entry. The p-rename-entry(uid, csn, rdn) primitive is used to change the Relative Distinguished Name of an entry. The rdn argument contains the new RDN for the entry. The p-remove-entry(uid, csn) primitive is used to remove an entry. The p-add-attribute-value(uid, csn, type, value) primitive is used to add a single attribute value to an entry. The type argument contains the attribute type of the value and the value argument contains the attribute value. The p-remove-attribute-value(uid, csn, type, value) primitive is used to remove a single attribute value from an entry. The type argument contains the attribute type of the value and the value argument contains the attribute value. The p-remove-attribute(uid, csn, type) primitive is used to remove all values of an attribute from an entry. The type argument contains the attribute type to be removed. These primitives reflect the intended final state of an update operation rather than the specific changes required to achieve that state. 4.4 Lost & Found Each connected set of mastering DSAs have a Lost & Found entry nominated. As a result of conflicting updates at two or more master DSAs, an entry may be left with a reference to a non-existent superior entry. Such an entry is called an orphaned entry. When this situation arises, the DSA creates a glue entry for the missing superior entry. This glue entry is made a subordinate of the Lost & Found entry and the orphaned entry becomes a subordinate of the glue superior entry (see Section 5.3.2). Entries that exist in the Lost & Found subtree may still be modified by actions of the replication protocol since entries are identified by Unique Identifiers in the protocol, independent of their positioning in the global DIT. Entries will also be explicitly moved to become immediate subordinates of the Lost & Found entry to prevent the formation of a loop in the superior-subordinate relationships in the DIT. This situation can only arise through conflicting move entry operations at two or more master DSAs. Legg & Payne Expires 22 April 2000 [Page 5] INTERNET-DRAFT LDUP Update Reconciliation Procedures October 22, 1999 Entries that exist under the Lost & Found entry may be returned to a suitable position in the DIT by an administrator or user with appropriate access rights. 5. Replication Procedures The procedures defined in this section ensure the consistent and correct application of the results of DAP, LDAP or DSP operations across all multi-master replication DSAs. 5.1 Processing LDAP, DAP or DSP Operations on the DIT A successful DAP, LDAP or DSP operation applied to a part of the DIT subject to a replication agreement will create or replace one or more CSNs on an entry or its contents, and create zero, one or more deletion records referencing the entry or its contents. The CSNs and deletion records generated from an operation are atomic with that operation. That is, either the operation succeeds, the CSNS are revised and the deletion records are stored, or the operation fails, no CSNs are revised and no deletion records are stored. In all cases, all current error conditions (i.e. reasons for rejecting an LDAP, DAP or DSP update operation) remain. At some later time, possibly immediately following the update or concurrently with it, the CSNs on entry contents and deletion records are used to generate the replication primitives that will report the update to other DSAs via a replication session. All the CSNs generated from a single update operation must use the same time, change count and Replica Identifier. The modification number is permitted to vary but must be assigned such that when the CSNs resulting from the operation, including those in the deletion records, are compared to the CSNs resulting from any other operation they are all strictly greater than or all strictly less than those other CSNs (i.e. in a global CSN ordering of the primitives resulting from all operations the primitives of each operation must be contiguous in that ordering). In order for the update to be consistently applied when replicated to other DSAs the CSNs generated during that update must generally be greater than any pre-existing CSNs on the updated entry's contents. It is expected that DSAs will normally use the current time according to their system clocks in generating the CSNs for an operation. However in an environment where DSA clocks are not necessarily synchronized the current time may be older than existing CSNs on entry contents. The constraints the new CSNs must satisfy with respect to pre-existing CSNs on entry data are covered in the sections on each type of update operation. The current LDUP architecture draft [LDUP Model] requires client update operations to be rejected if the current time does not satisfy the Legg & Payne Expires 22 April 2000 [Page 6] INTERNET-DRAFT LDUP Update Reconciliation Procedures October 22, 1999 constraints on the generation of the CSNs. As written, URP allows a DSA to generate CSNs in advance of its current time to satisfy the constraints and proceed with the update. The LDUP Update Vector mechanism imposes the additional constraint that the CSN generated for an update operation must also be greater than the highest CSN generated by the DSA that has already been seen by any other DSA. An implementation that generates successively greater CSNs for each operation will satisfy this constraint. The following sections describe the additional actions to support replication carried out in processing each particular type of update operation. 5.1.1 Add Entry The LDAP Add operation or DAP addEntry operation is used to add a leaf entry to the DIT. A successful request will generate a CSN for the entry. The CSN on the entry's RDN, the CSN on the entry's superior reference, and the CSN on each distinguished and non- distinguished value added to the entry by the add entry operation are set to this same value. The affected values include any operational attributes automatically generated by the DSA. The Unique Identifier generated for an entry created by a user request is required to be globally unique for all time, so there cannot be a pre-existing entry deletion record for the same Unique Identifier. However it is recognized that, in practice, Directory administrators may need to restore a deleted entry using its original Unique Identifier (the mechanism used to achieve this is undefined and outside the scope of this specification). In this case the CSN for the entry must be generated such that it is greater than or equal to the CSN of any existing entry, attribute or value deletion records and greater than any of the CSNs contained in an existing glue entry, for the same Unique Identifier. 5.1.2 Remove Entry The LDAP Delete operation or DAP removeEntry operation is used to remove a leaf entry from the DIT. If the request succeeds then an entry deletion record is stored containing the Unique Identifier of the removed entry. The CSN for the entry deletion record must be generated such that it is greater than the entry CSN of the removed entry. 5.1.3 Modify Entry The LDAP Modify operation (ModifyRequest) or DAP modifyEntry Legg & Payne Expires 22 April 2000 [Page 7] INTERNET-DRAFT LDUP Update Reconciliation Procedures October 22, 1999 operation is used to perform a series of one or more modifications to an entry. If the request succeeds then zero, one or more new values with CSNs are added to the entry contents, and zero, one or more value or attribute deletion records are stored. The modifications described by the modification argument of the LDAP ModifyRequest have the following additional effects: a) The add alternative associates a CSN with each of the added attribute values. b) The delete alternative with no listed values generates an attribute deletion record for the removed attribute type. c) The delete alternative with listed values generates a value deletion record for each of the removed values. d) The replace alternative first generates an attribute deletion record for the removed attribute type. A CSN is then associated with each of the added values. The modifications described by the changes argument of the X.500 modifyEntry operation have the following additional effects: a) The addAttribute and addValues alternatives associate a CSN with each of the added attribute values. These two alternatives are equivalent from the point of view of URP since there is no CSN associated specifically with the attribute type. b) The removeAttribute alternative generates an attribute deletion record for the removed attribute type. c) The removeValues alternative generates a value deletion record for each of the removed values. d) The alterValues alternative first generates a value deletion record for each of the old values. Secondly, a CSN is associated with each of the new values. e) The resetValues alternative generates a value deletion record for each value actually removed. The CSNs generated by a modify operation must be greater than the CSN of any pre-existing attribute value that is removed, greater than or equal to the CSN of any pre-existing attribute deletion record or value deletion record applying to an added attribute value, and greater than or equal to the CSN of the entry. Legg & Payne Expires 22 April 2000 [Page 8] INTERNET-DRAFT LDUP Update Reconciliation Procedures October 22, 1999 A further constraint applies to the modification number component of the CSNs generated by a single modify operation. The CSN generated for an added attribute value must be greater than or equal to the CSN on any applicable value deletion record or attribute deletion record already created by this same operation. This constraint is satisfied if the same modification number is used in all the CSNs generated by a single modify operation, or if the CSNs generated as the sequence of modifications in the operation are applied in order use monotonically increasing modification numbers. The modification numbers need not be consecutive in this case. Whenever a new value is added to the entry contents any value deletion record for the same entry, attribute type and attribute value may be discarded. 5.1.4 Modify DN The LDAP Modify DN operation and DAP modifyDN operation are used to change the Relative Distinguished Name of an entry and/or to move an entry to a new superior in the DIT. If the entry is moved to a new superior in the DIT then the CSN on the entry's superior reference is replaced. If the entry's RDN is changed then the CSN on the entry's RDN is replaced. A value deletion record is stored for each of the formally distinguished attribute values removed from the entry as a consequence of the deleteOldRDN (modifyDN) flag or deleteoldrdn (ModifyDNRequest) flag being set. If the CSN on the entry's superior reference is revised then the new value must be greater than the previous value. If the CSN on the entry's RDN is revised then the new value must be greater than the previous value of the CSN on the RDN. The CSNs for any value deletion records must be greater than the CSNs on the removed attribute values. 5.2 Generating Replication Primitives Each time a replication session is invoked, the supplier DSA must generate and send replication primitives for updates known to the supplier but not yet known to the consumer DSA. The supplier uses the Update Vector of the consumer to determine what to send. Conceptually, the supplier scans all the glue and non-glue entries and deletion records covered by the replication agreement with the consumer and generates primitives where the CSNs held by the supplier are greater than the CSN for the corresponding identified replica in the consumer's Update Vector. A p-add-entry primitive is generated for each entry whose entry CSN is greater than the Update Vector CSN for the same replica. The Legg & Payne Expires 22 April 2000 [Page 9] INTERNET-DRAFT LDUP Update Reconciliation Procedures October 22, 1999 superior argument of the p-add-entry primitive contains the Unique Identifier of the immediate superior entry of the added entry. The rdn argument of the p-add-entry primitive contains the Relative Distinguished Name of the created entry except that the Unique Identifier, if distinguished, is always omitted from the RDN. The superior and rdn arguments are provided even if the CSN on the superior reference or the RDN are greater than the CSN on the entry. A p-add-attribute-value primitive is generated for each distinguished value that has a CSN greater than the Update Vector CSN for the same replica and greater than the CSN on the RDN of its entry, and for each non-distinguished value that has a CSN greater than the Update Vector CSN for the same replica. The p-add-attribute-value primitive uses the CSN of the corresponding value. There are no separate primitives generated for the distinguished values that have the same CSN as the CSN on their entry's RDN. If the CSN on an entry's RDN is greater than the Update Vector CSN for the same replica and greater than the CSN on the entry then a p- rename-entry primitive is generated. The CSN for this primitive is the CSN on the entry's RDN and the rdn argument contains the Relative Distinguished Name of the entry. If the CSN on the entry's superior reference is greater than the Update Vector CSN for the same replica and greater than the CSN on the entry then a p-move-entry primitive is generated. The CSN for this primitive is the CSN on the entry's superior reference and the superior argument of the contains the Unique Identifier of the immediate superior entry. A p-remove-attribute-value primitive is generated for each value deletion record having a CSN greater than the Update Vector CSN for the same replica. The primitive uses exactly the same arguments as the value deletion record. A p-remove-attribute primitive is generated for each attribute deletion record having a CSN greater than the Update Vector CSN for the same replica. The primitive uses exactly the same arguments as the attribute deletion record. A p-remove-entry primitive is generated for each entry deletion record having a CSN greater than the Update Vector CSN for the same replica. The primitive uses exactly the same arguments as the entry deletion record. Rather than scanning the DIT, an implementation may choose to generate replication primitives as the user update requests are being processed and put these primitives into a replication log in Legg & Payne Expires 22 April 2000 [Page 10] INTERNET-DRAFT LDUP Update Reconciliation Procedures October 22, 1999 preparation for sending during the next replication session. Any replication primitives generated from an operation in this way MUST be atomic with that operation. That is, either the operation succeeds, and primitives are added to the replication log, or the operation fails, and no primitives are added to the log. The replication log may be filtered prior to sending to eliminate any primitives that are superseded by later primitives in the log, and any primitives having CSNs less than or equal to the relevant CSNs contained in a consumer DSA's Update Vector. In a log based implementation, the p-add-attribute-value primitive supersedes a p-remove-attribute-value primitive for the same entry, attribute type, attribute value and equal or older CSN. It supersedes another p-add-attribute-value primitive for the same entry, attribute type, attribute value and older CSN. The p-remove-attribute-value primitive supersedes a p-add-attribute- value primitive for the same entry, attribute type, attribute value and older CSN. It supersedes another p-remove-attribute-value primitive for the same entry, attribute type, attribute value and equal or older CSN. The p-remove-attribute primitive supersedes a p-add-attribute-value primitive for the same entry, attribute type and older CSN. It supersedes a p-remove-attribute-value or another p-remove-attribute primitive for the same entry, attribute type and equal or older CSN. The p-remove-entry primitive supersedes a p-add-attribute-value, p- add-entry, p-move-entry or p-rename-entry primitive for the same entry and older CSN. It supersedes a p-remove-attribute-value or p- remove-attribute or another p-remove-entry primitive for the same entry and equal or older CSN. The p-move-entry primitive supersedes another p-move-entry primitive for the same entry and older CSN. 5.3 Processing Replication Primitives on the DIT Each replication primitive received from another DSA during a replication session is processed against the DIT. This section defines some commonly used sub-procedures and the algorithms for processing each of the primitives. Components of primitives, entries, attributes and values are referenced with the . operator. In particular the notation X.csn refers to the CSN of the directory object X. The operators, < and > when applied to CSNs, use the convention of CSNs becoming greater with the progression of time, so older CSNs are less than younger CSNs. In the case where the CSN Legg & Payne Expires 22 April 2000 [Page 11] INTERNET-DRAFT LDUP Update Reconciliation Procedures October 22, 1999 for object X has been discarded through the purging mechanism, X.csn is assumed to have the least possible CSN value. In some of the procedures a CSN will be explicitly purged. An implementation may instead keep the CSN but set it to some value that is old enough for it to be eligible for purging (e.g. the least possible CSN value) without affecting the correctness of the procedures. For an entry, E, the notation E.rdn refers to the entry's Relative Distinguished Name, E.dn refers to the entry's Distinguished Name, and E.superior refers to the Unique Identifier of the entry's superior in the DIT. 5.3.1 Saving Deletion Records It is necessary for a DSA to remember that some entry, attribute or attribute value has been deleted, for a period after the processing of the update operation or primitive causing the deletion. These records are called deletion records in the sections that follow and are of three kinds: entry deletion records, attribute deletion records and value deletion records. Value deletion records result from, and have the same parameters as, the p-remove-attribute-value primitive. The StoreValueDeletion procedure creates a value deletion record from the actual arguments and stores it for later access by the various primitive processing procedures. When an attribute value is added to an entry, a value deletion record for the same entry, attribute type and value, and with an older CSN, may be discarded. Attribute deletion records result from, and have the same parameters as, the p-remove-attribute primitive. The StoreAttributeDeletion procedure creates an attribute deletion record from the actual arguments and stores it for later access. When an attribute deletion record is stored any value deletion records for the same entry and attribute type, and with equal or older CSNs, may be discarded. Entry deletion records result from, and have the same parameters as, the p-remove-entry primitive. The StoreEntryDeletion procedure creates an entry deletion record from the actual arguments and stores it for later access. When an entry deletion record is stored any value deletion records and attribute deletion records for the same entry, and with equal or older CSNs, may be discarded. Since the deletion records have the same components as their associated remove primitives an implementation may choose to use the same internal structures for both. Legg & Payne Expires 22 April 2000 [Page 12] INTERNET-DRAFT LDUP Update Reconciliation Procedures October 22, 1999 5.3.2 Glue Entries Entries are permitted to be re-added and this can lead to situations where applicable primitives are received in the period after an entry is removed but before the arrival of the notification of it being re-added. In these cases a glue entry is created for the Unique Identifier to preserve relevant updates in the event that a p-add- entry primitive with an older CSN is later received for the same entry. A glue entry is upgraded to a normal entry by a subsequent p- add-entry primitive. A glue entry with no subordinate entries and containing only CSNs (on itself or its component parts) that are eligible to be purged (according to the Purge Vector in LDUP, or the Oldest Time in DMRP) may be removed. A glue entry is discarded if its contents are completely superseded by another p-remove-entry primitive. The CreateGlueEntry function is called when required to create a glue entry as a subordinate of Lost & Found. CreateGlueEntry takes a single parameter which is the Unique Identifier for the glue entry. The Unique Identifier also becomes the RDN for the glue entry. No CSNs are associated with the entry, the entry's superior reference, or the entry's name (or equivalently they are set to the least possible CSN value). 5.3.3 Generating Change Sequence Numbers There are circumstances where conflicts arise in the processing of a replication primitive. It is necessary in these cases for the DSA processing the primitives to make corrective changes and emit additional primitives to ensure that all other DSAs reach the same consistent state. The GenerateNextCSN function is used to obtain a CSN for the corrective change. An implementation that generates replication primitives as the user update requests are being processed and puts them into a replication log must take the additional step of creating a primitive to convey the corrective change to other DSAs. Implementations that generate primitives by scanning entries will pick up the corrective change automatically. As is the case for CSNs generated from DAP, DSP or LDAP operations, a CSN is typically generated from the current clock time of the DSA. The conditions imposed for the correct operation of the LDUP Update Vector must also be satisfied. GenerateNextCSN takes a single CSN parameter. In addition to all other conditions the CSN generated by the function must be greater than this parameter. Since the CSN parameter passed to GenerateNextCSN is always an actual CSN from some directory object Legg & Payne Expires 22 April 2000 [Page 13] INTERNET-DRAFT LDUP Update Reconciliation Procedures October 22, 1999 stored in the local DSA, an implementation may choose to allocate CSNs from an incrementing internal CSN register that is reset after each replication session to a value greater than the largest CSN seen so far, and thereby be safely able to disregard the parameter to GenerateNextCSN. 5.3.4 Comparison of Attribute Values Values in primitives, in deletion records or in entries are compared using the equality matching rule for the associated attribute type where that type is permitted to be multi-valued. This means that two values that are considered equal may nonetheless have minor differences. For example, two commonName values may be equal, but use different letter case and have different numbers of leading or trailing spaces. Whenever a CSN for some value is refreshed the value is also refreshed using the exact value from the primitive so that all DSAs use exactly the same representation for the value. Compared values for a single-valued attribute type are all considered to be equal even though they may be significantly different according to that attribute type's equality matching rule. In effect the equality operator, '=', in the following procedures is unconditionally true when used to compare values of a single-valued attribute type. Whenever a CSN for the value of a single-valued attribute is refreshed the value is also refreshed using the value from the primitive. One significant consequence is that an entry whose RDN contains a value of a single-valued attribute type is effectively renamed by a p-add-attribute-value primitive with a more recent value for the attribute type. A value in an entry that is replaced by the exact representation from a primitive retains its distinguished or non-distinguished status. This includes replaced values of single-valued attribute types. 5.3.5 Entry Naming Independent changes at two or more DSAs can lead to the situation of two distinct entries having the same name. The procedure, CheckUniqueness(E, S, R), takes an entry and determines whether it is uniquely named. If not, it disambiguates the names of the entries by adding the Unique Identifier of each of the conflicting entries to their own RDN. The procedure CheckUniqueness is called in each circumstance where the Relative Distinguished Name of an entry might conflict with another entry, either because the entry has been renamed or because it has been moved to a new superior. An entry can be renamed directly by a p-rename-entry primitive, or as a side-effect of other Legg & Payne Expires 22 April 2000 [Page 14] INTERNET-DRAFT LDUP Update Reconciliation Procedures October 22, 1999 primitives causing changes to distinguished values. While each move or rename of an entry potentially causes a conflict with some other entry already having the new Distinguished Name, it also potentially removes a previous conflict on the old Distinguished Name. The enable the CheckUniqueness function to remove the Unique Identifier from an entry's RDN when it is no longer needed the old name for an entry is passed through the second and third parameters. The parameter, S, is the Unique Identifier of the old superior entry of E, and the parameter, R, is the old RDN of E. CheckUniqueness needs to ignore distinguished UniqueIdentifiers when comparing entry RDNs. The function BaseRDN(rdn) returns its argument minus any distinguished UniqueIdentifiers to support these comparisons. CheckUniqueness(E, S, R) { make E.uid non-distinguished IF there exists exactly one subordinate entry, C, of S where BaseRDN(C.rdn) = BaseRDN(R) make C.uid non-distinguished IF E.rdn is empty make C.uid distinguished ELSE IF there exists a subordinate entry, C, of E.superior where E <> C AND BaseRDN(C.rdn) = BaseRDN(E.rdn) { make C.uid distinguished make E.uid distinguished } } Because updates are performed in isolation at multiple DSAs in a multimaster configuration it is possible to encounter a situation where there is a request to delete a distinguished value in an entry. The recommended practice in these circumstances is to remove the distinguished value and call CheckUniqueness to correct any resulting name conflicts. An implementation may instead reassert the existence of the distinguished value with a more recent CSN to avoid altering the entry's RDN. This option is only available to updatable replicas. Read-only replicas MUST remove the distinguished value. The function ProtectDistinguished() returns true for an updatable part of the DIT in an DSA that implements this option, and false otherwise. DSAs exercising this option must generate p-add-attribute-value primitive so that other DSAs are guaranteed to also reassert the distinguished value. DSAs that implement the option will correctly interwork with servers that do not. The primitives p-add-entry and p-rename-entry contain common elements that are applied to the Relative Distinguished Name of an entry in the same way. This common processing is described in the RenameEntry Legg & Payne Expires 22 April 2000 [Page 15] INTERNET-DRAFT LDUP Update Reconciliation Procedures October 22, 1999 procedure. The parameters to this procedure are the entry, E, and the p-add-entry or p-rename-entry primitive specifying the new RDN. The procedure assumes that the entry does not currently contain any distinguished values. It is the responsibility of the calling procedure to first reset any pre-existing distinguished values to non-distinguished. The procedure then resets the CSNs and sets the distinguished flags for existing values and adds distinguished values if necessary. The CSN for the entry's RDN, as distinct from the CSNs on each of the distinguished values making up the RDN, is also set. RenameEntry(E, P) { FOREACH AttributeTypeAndValue, N, in P.rdn IF there exists an attribute value, V, in E of type N.type where V = N.value { IF P.csn > V.csn { replace V with N.value if they are not identical V.csn := P.csn } make V distinguished } ELSE IF ProtectDistinguished() { V := N.value add V to E as a distinguished value V.csn := P.csn FOREACH attribute deletion record (uid, type, csn) where (uid = P.uid AND type = N.type) IF csn > V.csn V.csn := csn FOREACH value deletion record (uid, type, value, csn) where (uid = P.uid AND type = N.type AND value = N.value) IF csn > V.csn V.csn := csn V.csn := GenerateNextCSN(V.csn) } ELSE IF no attribute deletion record (uid, type, csn) exists where (uid = P.uid AND type = N.type AND csn > P.csn) AND no value deletion record (uid, type, value, csn) exists where (uid = P.uid AND type = N.type AND value = N.value AND csn > P.csn) { V := N.value add V to E as a distinguished value V.csn := P.csn } Legg & Payne Expires 22 April 2000 [Page 16] INTERNET-DRAFT LDUP Update Reconciliation Procedures October 22, 1999 E.rdn.csn := P.csn } 5.3.6 Processing Add Attribute Value Primitive This section describes the algorithm for processing the p-add- attribute-value (P.uid, P.type, P.value, P.csn) primitive, which is responsible for adding a single attribute value. IF no value deletion record (uid, type, value, csn) exists where (uid = P.uid AND type = P.type AND value = P.value AND csn > P.csn) AND no attribute deletion record (uid, type, csn) exists where (uid = P.uid and type = P.type AND csn > P.csn) AND no entry deletion record (uid, csn) exists where (uid = P.uid AND csn > P.csn) { IF entry, E, with uid = P.uid does not exist E := CreateGlueEntry(P.uid) IF P.csn >= E.csn IF attribute value V, of type P.type where V = P.value exists in E { IF P.csn > V.csn { V.csn := P.csn R := E.rdn replace V with P.value if they are not identical IF V is distinguished AND P.type is a single-valued attribute type CheckUniqueness(E, E.superior, R) } } ELSE { V := P.value Add V to E as a non-distinguished attribute value V.csn := P.csn } } 5.3.7 Processing Remove Attribute Value Primitive This section describes the algorithm for processing the p-remove- attribute-value (P.uid, P. type, P.value, P.csn) primitive, which is responsible for removing a single attribute value. A value that is Legg & Payne Expires 22 April 2000 [Page 17] INTERNET-DRAFT LDUP Update Reconciliation Procedures October 22, 1999 distinguished is tagged as distinguished-not-present rather than being immediately removed. Such a value will be physically removed when it becomes non-distinguished. IF no value deletion record (uid, type, value, csn) exists where (uid = P.uid AND type = P.type AND value = P.value AND csn >= P.csn) AND no attribute deletion record (uid, type, csn) exists where (uid = P.uid AND type = P.type AND csn >= P.csn) AND no entry deletion record (uid, csn) exists where (uid = P.uid AND csn >= P.csn) IF entry, E, with uid = P.uid exists { IF P.csn > E.csn IF attribute value, V, of P.type where V = P.value, exists in E { IF P.csn > V.csn IF V is distinguished IF ProtectDistinguished() V.csn := GenerateNextCSN(P.csn) ELSE { R := E.rdn remove value V CheckUniqueness(E, E.superior, R) StoreValueDeletion (P.uid, P.type, P.value, P.csn) } ELSE { remove value V StoreValueDeletion (P.uid, P.type, P.value, P.csn) } } ELSE StoreValueDeletion (P.uid, P.type, P.value, P.csn) } ELSE StoreValueDeletion (P.uid, P.type, P.value, P.csn) The presence of a younger deletion record for the entry, attribute or value provides a convenient test for whether the p-remove-attribute- value primitive needs to be processed at all. If the value exists to be removed then there cannot be a deletion record affecting it that has a younger CSN. If there is a younger deletion record than the primitive then there cannot be an older value to remove. Legg & Payne Expires 22 April 2000 [Page 18] INTERNET-DRAFT LDUP Update Reconciliation Procedures October 22, 1999 5.3.8 Processing Remove Attribute Primitive This section describes the algorithm for processing the p-remove- attribute (P.uid, P.type, P.csn) primitive, which is responsible for removing all attribute values of P.type. Values that are distinguished are tagged as distinguished-not-present rather than being immediately removed. Such values will be physically removed when they become non-distinguished. IF no attribute deletion record (uid, type, csn) exists where (uid = P.uid AND type = P.type AND csn >= P.csn) AND no entry deletion record (uid, csn) exists where (uid = P.uid AND csn >= P.csn) IF entry, E, with uid = P.uid exists { IF P.csn > E.csn { FOREACH attribute value, V, of type P.type in E (if any) IF P.csn > V.csn IF V is distinguished IF ProtectDistinguished() V.csn := GenerateNextCSN(P.csn) ELSE { R := E.rdn remove value V CheckUniqueness(E, E.superior, R) } ELSE remove value V StoreAttributeDeletion (P.uid, P.type, P.csn) } } ELSE StoreAttributeDeletion (P.uid, P.type, P.csn) 5.3.9 Processing Add Entry Primitive This section describes the algorithm for processing the p-add-entry (P.uid, P.superior, P.rdn, P.csn) primitive, which is responsible for adding an entry. The CSN on an entry records the time of the latest p-add-entry primitive for the Unique Identifier. In normal circumstances there will only ever be one p-add-entry primitive associated with an entry. The entry CSN may be discarded when it becomes eligible to be purged according to the Purge Vector. IF no entry deletion record (uid, csn) exists where Legg & Payne Expires 22 April 2000 [Page 19] INTERNET-DRAFT LDUP Update Reconciliation Procedures October 22, 1999 (uid = P.uid AND csn > P.csn) IF entry, E, with uid = P.uid exists { IF P.csn > E.csn { E.csn := P.csn FOREACH attribute value, V, in E IF V.csn < P.csn remove value V process P according to p-rename-entry(P.uid, P.rdn, P.csn) process P according to p-move-entry(P.uid, P.superior, P.csn) } } ELSE { create entry E E.csn := P.csn E.uid := P.uid E.uid.csn := P.csn IF an entry with uid = P.superior does not exist CreateGlueEntry(P.superior) E.superior = P.superior E.superior.csn := P.csn RenameEntry(E, P) CheckUniqueness(E, E.superior, E.rdn) } 5.3.10 Processing Remove Entry Primitive This section describes the algorithm for processing the p-remove- entry (P.uid, P.csn) primitive, which is responsible for removing an entry. If the target entry has attribute values with CSNs greater than the primitive's CSN, a superior reference with a greater CSN, or if it has any subordinate entries, it becomes a glue entry instead of being removed. Unless it has a CSN for its superior reference that is greater than the CSN of the p-remove-entry it is also moved to Lost & Found. IF no entry deletion record (uid, csn) exists where (uid = P.uid AND csn >= P.csn) IF entry, E, with uid = P.uid exists { IF P.csn > E.csn { IF E.superior.csn >= P.csn Legg & Payne Expires 22 April 2000 [Page 20] INTERNET-DRAFT LDUP Update Reconciliation Procedures October 22, 1999 OR any value, V, with csn >= P.csn exists OR E has subordinates { R := E.rdn S := E.superior make E a glue entry purge E.csn IF E.superior.csn < P.csn { E.superior := LOST_AND_FOUND purge E.superior.csn } IF E.rdn.csn < P.csn purge E.rdn.csn FOREACH attribute value, V, in E IF V.csn < P.csn remove value V CheckUniqueness(E, S, R) } ELSE remove entry E StoreEntryDeletion (P.uid, P.csn) } } ELSE StoreEntryDeletion (P.uid, P.csn) 5.3.11 Processing Move Entry Primitive This section describes the algorithm for processing the p-move-entry (P.uid, P.superior, P.csn) primitive, which is responsible for moving an entry. If the new superior specified by the primitive does not exist or is a direct or indirect subordinate of the entry being moved then the entry is moved to Lost & Found instead. IF no entry deletion record (uid, csn) exists where (uid = P.uid AND csn > P.csn) { IF entry, E, with uid = P.uid does not exist E := CreateGlueEntry(P.uid) IF P.csn > E.superior.csn { R := E.rdn O := E.superior IF entry, S, with uid = P.superior does not exist S := CreateGlueEntry(P.superior) IF S is not in the subtree of E Legg & Payne Expires 22 April 2000 [Page 21] INTERNET-DRAFT LDUP Update Reconciliation Procedures October 22, 1999 { E.superior := P.superior E.superior.csn = P.csn } ELSE { E.superior := LOST_AND_FOUND; E.superior.csn := GenerateNextCSN(P.csn) } CheckUniqueness(E, O, R) } } 5.3.12 Processing Rename Entry Primitive This section describes the algorithm for processing the p-rename- entry (P.uid, P.rdn, P.csn) primitive, which changes the Relative Distinguished Name of an entry. A p-rename-entry primitive that is older than current name of an entry is not simply ignored since it may contain attribute values that would have been added to the entry had the primitives arrived in CSN order. These extra values would now be non-distinguished. IF no entry deletion record (uid, csn) exists where (uid = P.uid AND csn >= P.csn) { IF entry, E, with uid = P.uid does not exist E := CreateGlueEntry(P.uid) IF P.csn > E.rdn.csn { R := E.rdn FOREACH distinguished attribute value, V, in entry E make V non-distinguished RenameEntry(E, P) CheckUniqueness(E, E.superior, R) } ELSE FOREACH AttributeTypeAndValue, N, in P.rdn { IF there exists an attribute value, V, in E of type N.type AND V = N.value { IF P.csn > V.csn { replace V with N.value if they are not identical V.csn := P.csn } Legg & Payne Expires 22 April 2000 [Page 22] INTERNET-DRAFT LDUP Update Reconciliation Procedures October 22, 1999 } ELSE { IF no value deletion record (uid, type, value, csn) exists where (uid = P.uid AND type = N.type AND value = N.value AND csn > P.csn) AND no attribute deletion record (uid, type, csn) exists where (uid = P.uid AND type = N.type AND csn > P.csn) { V := N.value Add V to E V.csn := P.csn } } } } 6. Security Considerations [To be supplied] 7. Acknowledgements The authors would like to thank Suellen Faulks, Tony Robertson and Mark Ennis from Telstra Research Laboratories who contributed to the design and verification of the procedures described in this document. The authors would also like to thank the members of the LDUP architecture group for their input into the refinement of the design. 8. References [LDUP Model] - E. Reed, "LDUP Replication Architecture", Internet Draft, draft-merrells-ldup-model-01.txt, November 1998. [BCP-11] - R. Hovey, S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. 9. Intellectual Property Notice The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to Legg & Payne Expires 22 April 2000 [Page 23] INTERNET-DRAFT LDUP Update Reconciliation Procedures October 22, 1999 pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. [BCP-11] Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 10. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Legg & Payne Expires 22 April 2000 [Page 24] INTERNET-DRAFT LDUP Update Reconciliation Procedures October 22, 1999 11. Authors' Address Steven Legg Telstra Research Laboratories 770 Blackburn Road Clayton, Victoria 3168 AUSTRALIA Phone: +61 3 9253 6771 Fax: +61 3 9253 6485 EMail: s.legg@trl.telstra.com.au Alison Payne PricewaterhouseCoopers St Jakobs Strasse 25 CH-4002 Basel SWITZERLAND Phone: +41-79-458 4177 EMail: alison.b.payne@ch.pwcglobal.com 12. Appendix A - Changes From Previous Drafts 12.1 Changes in Draft 01 Some of the terminology has been changed to better align with the terminology used in the LDUP architecture draft. Descriptions on the usage of CSNs have been revised to account for the extra modification number component. The semantics of re-added entries has been simplified so that only changes after the latest re-add are preserved instead of all those after the earliest re-add. This eliminates the need for Addition CSNs in the entry. It is anticipated that new replication primitives will be introduced to manage entries that come and go from partial replicas instead of using p-add-entry and p-remove-entry. Orphaned entries are no longer moved directly to Lost & Found. Instead a glue entry is created in Lost & Found for the missing superior and the orphaned entry becomes a subordinate of that. This change eliminates the need for explicit propagated primitives for moving orphaned entries to Lost & Found. Glue entries have also been used as the mechanism for saving primitives. There are no longer any references to saved primitives though the functionality is still present. Legg & Payne Expires 22 April 2000 [Page 25] INTERNET-DRAFT LDUP Update Reconciliation Procedures October 22, 1999 The procedures for processing received replication primitives have been rearranged to follow a more consistent pattern where the presence of deletion records is tested first. 12.2 Changes in Draft 02 Multimaster replication has been dropped as a work item for the next edition of X.500 so references to the proposed X.500 multimaster replication protocol have been removed. The treatment of distinguished values has been simplified. Previously an attempt to remove a distinguished value caused the value to be tagged distinguished-not-present. Now the distinguished value is removed, and if necessary, the Unique Identifier is made distinguished to avoid an empty RDN. Optionally, the value to be removed can be reasserted by emitting an explicit p-add-attribute- value primitive. The current draft is more implementation neutral. A replication log no longer figures prominently in the specification. The previous descriptions had the user updates generating replication primitives, which in turn were used to determine the CSNs and deletion records. The new descriptions have user updates generating CSNs and deletion records and the primitives are subsequently generated from them. 13. Appendix B - Open Issues The precise location of the Lost & Found entry has not yet been decided. Extensions to the algorithms to properly deal with partial replicas are still to be decided. The draft needs some editing to use MAY, MUST, etc, in the proper way. Legg & Payne Expires 22 April 2000 [Page 26] --Drove_of_Sheep_422_000-- From owner-ietf-ldup@imc.org Mon Oct 25 10:43:12 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12509 for ; Mon, 25 Oct 1999 10:43:12 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA08980 for ietf-ldup-bks; Mon, 25 Oct 1999 06:46:57 -0700 (PDT) Received: from dir1.control.att.com ([135.207.251.15]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA08974 for ; Mon, 25 Oct 1999 06:46:46 -0700 (PDT) Received: from att.com (pest.control.att.com [135.207.251.76]) by dir1.control.att.com (Postfix) with ESMTP id 3AC5471C2; Mon, 25 Oct 1999 09:53:30 -0400 (EDT) Message-ID: <38145C3C.2C48143B@att.com> Date: Mon, 25 Oct 1999 09:33:48 -0400 From: Chris Apple Organization: AT&T Labs X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Chris Apple Cc: "Russel F. Weiser" , Ellen Stokes , ietf-ldup@imc.org, rvh@qsun.ho.att.com Subject: Re: Revised Draft-ietf-ldup-replica-req-02.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Russ, Looks like this one did not really make it in before the cut-off date. You'll have to re-submit it to the Internet-Drafts Editor after 11/7 before we can officially send it to Patrik with a request for IESG review. Chris. Chris Apple wrote: > Russ, > > Thanks! > > Since this made it in by the deadline, we'll talk about it at the > meeting. The only step left is to mention that we plan to send it > to the ADs to present for IESG consideration for an IETF Last Call > of the document as a deliverable of the working group. > > We can deal with any remaining comments during IETF Last Call. > > Chris. > > On Sun, 24 Oct 1999, Russel F. Weiser wrote: > > > I made several revisions that were requested and missed in the last > > revision. I hope that this will be accepted for last call if not I am > > also submitting it to the LDUP list for consideration to moving to LAST > > CALL as an information draft. > > > > cheers > > RFW > > ------------------------------------------------------------------------ > Chris Apple Business Site: AnyWho Directory Service > Internet Directory Group http://www.anywho.com > AT&T Labs > capple@control.att.com > +1 973 236 6470 Tired of slow directories? Try AnyWho. > ------------------------------------------------------------------------ From owner-ietf-ldup@imc.org Mon Oct 25 10:53:48 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13138 for ; Mon, 25 Oct 1999 10:53:45 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA08734 for ietf-ldup-bks; Mon, 25 Oct 1999 06:28:46 -0700 (PDT) Received: from ausmail1.austin.ibm.com (ausmail1.austin.ibm.com [192.35.232.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA08730 for ; Mon, 25 Oct 1999 06:28:42 -0700 (PDT) Received: from netmail3.austin.ibm.com (netmail3.austin.ibm.com [9.53.250.99]) by ausmail1.austin.ibm.com (8.9.1/8.8.5) with ESMTP id IAA19448 for ; Mon, 25 Oct 1999 08:29:52 -0500 Received: from dceperf.austin.ibm.com (dceperf.austin.ibm.com [9.53.94.159]) by netmail3.austin.ibm.com (8.8.5/8.8.5) with SMTP id IAA27198 for ; Mon, 25 Oct 1999 08:31:38 -0500 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 AA16800; Mon, 25 Oct 1999 08:31:38 -0500 Message-Id: <9910251331.AA16800@dceperf.austin.ibm.com> X-Sender: stokes@popmail2.austin.ibm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Mon, 25 Oct 1999 08:31:07 -0500 To: ietf-ldup@imc.org From: Ellen Stokes Subject: replication transfer protocol spec (+ more comments) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_1357647==_" Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=====================_1357647==_ Content-Type: text/plain; charset="us-ascii" Please find attached the draft for the replication transfer protocol that was submitted last week. Also, I attached a list of items that need to be addressed in that draft. Ellen **************** - As we've started working on a prototype implementation, we decided that part of the initial replication exchange should also include the supplier sending the consumer a "recent" CSN (e.g. maybe the next CSN it would generate), so that the supplier can detect excessive clock skew (either its own clock, or the supplier's). There would also be a new return code that means "your clock is messed up - go away". I think the architecture document, or some other document, ought to talk about CSNs and what happens when a server's CSN generator regresses or advances relative to another's, but that's not something we'd want to tackle in the protocol document. - We may need to state something about ordering of updates in the protocol and how that relates to the order in which the updates are processed. For example, in our server implementation, normal LDAP operations are assigned to any available worked thread, which means that two operations received in one order might actually complete in the reverse order. This may not be acceptable for replication updates, e.g. you might end up processing an entry modification before the addition of the entry. All umich-derived servers are probably going to have this issue. - Address whether the LDAP bulk update/replication protocol should be included in this draft or continue to be in its separate draft (draft submitted by Roger Harrison). - Add to semantics section: As long as consumer knows it is talking to a log-based supplier, the consumer can update its update vector at connection loss time, so this behavior needs to be expressed as a parameter - Add to semantics section: Replication status needs to be updated at end of each replication attempt - Add ordering flag to supplier init protocol flow - Use RFC 23xx (not RFC 822) for BNF - Look at constraints and use as appropriate in the protocol doc - Describe semantics with respect to access control - Describe error codes/conditions in the semantics - Rename the extended ops - Question to resolve: If the C API or Java API draft sufficient for the replication API? *************** --=====================_1357647==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="draft-ietf-ldup-protocol-00.txt" Internet-Draft Ellen Stokes LDUP Workgroup IBM Intended Category: Standards Track Gordon Good Expires: 22 April 2000 America Online/Netscape 22 October 1999 The LDUP Replication Update Protocol Filename: draft-ietf-ldup-protocol-00.txt Table of Contents 1. Status of this Memo.............................................2 2. Abstract........................................................2 3. Overview of Protocol............................................2 4. High-level Description of Protocol Flow.........................3 4.1 Supplier-initiated replication protocol.........................3 4.2. Consumer-initiated replication protocol......................4 5. Replication protocol element definitions........................5 5.1 StartReplicationRequest Extended Operation......................5 5.2 StartReplicationResponse Extended Operation.....................6 5.3 ReplicationUpdate Extended Operation............................7 5.3.1 UniqueIdentifier.............................................8 5.3.2 ReplicationPrimitive.........................................8 5.3.2.1 AddEntryPrimitive.........................................8 5.3.2.2 MoveEntryPrimitive........................................9 5.3.2.3 RenameEntryPrimitive......................................9 5.3.2.4 RemoveEntryPrimitive......................................9 5.3.2.5 AddAttributeValuePrimitive................................10 5.3.2.6 RemoveAttributeValuePrimitive.............................10 5.3.2.7 RemoveAttributePrimitive..................................10 5.4 EndReplicationRequest Extended Operation........................11 5.5 EndReplicationResponse Extended Operation.......................11 6. Semantics of Full and Incremental Update protocols..............12 7. Summary of response codes.......................................12 8. Implications for log-based and state-based servers..............13 9. Replication of access control and schema information............13 10. Security Considerations.........................................13 11. Glossary of Terms...............................................13 12. Acknowledgments.................................................13 13. References......................................................13 14. Author's Addresses..............................................14 Stokes and Good [Page 1] INTERNET-DRAFT LDUP Replication Update Protocol 22 October 1999 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. This Internet Draft expires 22 April 2000. 2. Abstract The protocol described in this document is designed to allow one LDAP server to replicate its directory content to another LDAP server. The protocol is designed to be used in a replication configuration where multiple updatable servers are present. Provisions are made in the protocol to carry information that allows the server receiving updates to apply a total ordering to all updates in the replicated system. This total ordering allows all replicas to correctly resolve conflicts that arise when LDAP clients submit changes to different servers that later replicate to one another. All protocol elements described here are LDAP Version 3 extended operations. LDAP Version 3 is described in RFC 2251 [LDAPv3]. Certain terms used in this document are defined in the document "LDAP Replication Architecture" (draft-ietf-ldup-model-00.txt). The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC 2119 [KEYWORDS]. 3. Overview of Protocol The LDAP Replication Architecture [ARCHITECTURE] describes the overall approach used in ensuring consistency of multiple updatable replicas of directory content. The protocol described in this document implements the approach desribed in that document. Stokes and Good [Page 2] INTERNET-DRAFT LDUP Replication Update Protocol 22 October 1999 LDAP Version 3 extended operations are used to carry replicated content from one server to another. The extended operations defined in this document are used to initiate and end a replication session, and to exchange updates. These updates carry with them information that allows the receiving server to apply a total ordering to all of the updates in a replicated system. All servers that receive replication updates apply a consistent set of update resolution policies, described in [URP]. Consistent application of the update resolution policies ensures that all replicas eventually converge and contain the same directory data. The protocol is intended to meet the requirements set forth in [REQ]. 4. High-level Description of Protocol Flow The following section provides a high-level overview of the replication protocol. Throughout this section, the supplier server is indicated by the letter "S" and the consumer server by the letter "C". The construct "S -> C" indicates that the supplier is sending an LDAPv3 extended operation to the consumer, and "C -> S" indicates that the consumer is sending an LDAPv3 extended operation to the supplier. 4.1 Supplier-initiated replication protocol S -> C: LDAP bind operation (identity and credentials used are implementation-defined) C -> S: Bind response S -> C: StartReplicationRequest LDAPv3 extended operation. The parameters are: 1) Root of replicated area (unambiguously identifies the replicated area) 2) Supplier's replicaID 3) OID of replication protocol to be used (this document defines IETF-LDUP incremental and IETF-LDUP total update protocols) 4) The protocol initiation type - Supplier-Initiated in this case. C -> S: StartReplicationResponse LDAPv3 extended operation. The parameters are: 1) A response code (see section 7) 2) An optional update vector that is included if and only if the response code is REPL_SUCCESS. Stokes and Good [Page 3] INTERNET-DRAFT LDUP Replication Update Protocol 22 October 1999 S -> C: The supplier may send zero or more ReplicationUpdate LDAPv3 extended operations. The parameters are: 1) The UUID of the entry being updated 2) One or more Replication Primitives (The supplier may send as many of these as required to bring the consumer up to date) C -> S: At any time, the consumer may send an unsolicited ReplicationUpdateResponse LDAPv3 extended operation. The parameters are: 1) An optional update vector. If sent, this indicates that the consumer has committed all updates whose CSNs are covered by the transmitted update vector [see glossary for a definition of "covered by"]. 2) An optional AbortUpdate boolean flag. If a supplier receives a ReplicationUpdateResponse from a consumer with the AbortUpdate flag set to true, the supplier server MUST immediately cease sending updates and terminate its connection to the consumer. S -> C: After all required updates have been sent to the consumer, the supplier sends an EndReplicationRequest LDAPv3 extended operation C -> S: The consumer responds by sending an EndReplicationRequest LDAPv3 extended operation, and then closes the connection. 4.2. Consumer-initiated replication protocol C -> S: LDAP bind operation (identity and credentials used are implementation-defined) S -> C: Bind response C -> S: StartReplicationRequest LDAPv3 extended operation. The parameters are: 1) Root of replicated area (unambiguously identifies the replicated area) 2) Consumer's replicaID 3) OID of replication protocol to be used (this document defines IETF-LDUP incremental and IETF-LDUP total update protocols) 4) The protocol initiation type - Consumer-Initiated in this case S -> C: StartReplicationResponse LDAPv3 extended operation. The Stokes and Good [Page 4] INTERNET-DRAFT LDUP Replication Update Protocol 22 October 1999 parameters are: 1) A response code (see section 7) S -> C: The supplier server disconnects from the consumer server, and then connects to the consumer, beginning a Supplier- Initiated protocol session (see section 4.1). 5. Replication protocol element definitions 5.1 StartReplicationRequest Extended Operation The StartReplicationRequest extended operation is sent by a replication initiator to a server to indicate that a replication session should commence. For supplier-initiated replication, the supplier sends this extended operation to the replication consumer to indicate that a replication session should commence. For consumer-initiated replication, the consumer sends this extended operation to the replication supplier to indicate that the supplier should initiate a replication session to the consumer as soon as possible. The StartReplicationRequest extended operation is defined as follows: StartReplicationRequest ::= [APPLICATION 23] SEQUENCE { requestName [0] LDAPOID, requestValue [1] OCTET STRING } The requestName of the StartReplicationRequest must be [OID to be assigned]. The requestValue of the StartReplicationRequest must be set to the BER-encoding of the following: requestValue ::= SEQUENCE { replicaRoot LDAPDN, replicaID LDAPString, replicationProtocolOID LDAPOID, replicationInitiator ENUMERATED { supplier (0), consumer (1) } } The parameters in the requestValue of the StartReplicationRequest are: - replicaRoot: the distinguished name of the entry at the top of the replicated area, and uniquely identifies the unit of Stokes and Good [Page 5] INTERNET-DRAFT LDUP Replication Update Protocol 22 October 1999 replication. - replicaID: the replica identifier of the replication initiator. Each replica of a given replicated area is identified by a unique identifier, described in [ARCHITECTURE]. - replicationProtocolOID: the type of replication protocol that should be used to transfer the updates. This document describes two protocols; ietf-ldup-full-update and ietf-ldup-incremental-update. See section 7 for information on the semantic behavior of these update protocols. Implementations MUST support the two update protocols defined in this document. - replicationInitiator: used to differentiate between a supplier- initiated session and a consumer-initiated session. If the replicationInitiator contains the enumerated value , then the initiator is the supplier, and the receiver of this operation should prepare to receive a set of replication updates (or should reject the operation is replication updates are not permitted for some reasonm, perhaps due to access control restrictions). If the replicationInitiator contains the enumerated value , then the receiver should prepare to establish a supplier-initiated replication session with the consumer as soon as possible, updating the replicated are given by replicaRoot and using the update protocol given by replicationProtocolOID. 5.2 StartReplicationResponse Extended Operation The StartReplicationResponse extended operation is sent in response to a StartReplicationRequest extended operation. For a supplier-initiated session, the StartReplicationResponse extended operation indicates that the consumer is or is not prepared to accept a set of updates. If the consumer is prepared to accept updates, it sends a StartReplicationResponse extended operation containing a success code and the consumer's replica update vector. If the consumer is unwilling or unable to accept updates, it sends a StartReplicationResponse extended operation containing an error code. For a consumer-initiated session, the StartReplicationResponse extended operation indicates that the supplier is or is not prepared to send a set of updates to the consumer. If the supplier is prepared to send updates to the consumer, it sends a StartReplicationResponse extended operation with a success code. If the supplier is unwilling or unable to send updates to the consumer, it sends a StartReplicationResponse extended operation containing an error code. In both cases, the supplier disconnects from the consumer. If the supplier sent a success code to the consumer, it opens a connection to the consumer as soon as possible and Stokes and Good [Page 6] INTERNET-DRAFT LDUP Replication Update Protocol 22 October 1999 initiates a supplier-initiated replication session. The StartReplicationResponse extended operation is defined as follows: StartReplicationResponse ::= [APPLICATION 23] SEQUENCE { requestName [0] LDAPOID, requestValue [1] OCTET STRING } The requestName of the StartReplicationResponse must be [OID to be assigned]. The requestValue of the StartReplicationResponse must be set to the BER-encoding of the following: requestValue ::= SEQUENCE { responseCode LDUPResponseCode, replicaUpdateVector Attribute, } LDUPResponseCodes are defined in section 8. The replicaUpdateVector contains a replica update vector, as defined in [INFOMOD]. The update vector is encoded as a normal LDAP attribute, defined in [LDAPv3]. 5.3 ReplicationUpdate Extended Operation The ReplicationUpdate extended operation carries a set of replication primitives that represent the desired final state of a single entry. The ReplicationUpdate extended operation is defined as follows: ReplicationUpdate ::= [APPLICATION 23] SEQUENCE { requestName [0] LDAPOID, requestValue [1] OCTET STRING } The requestName of the ReplicationUpdate must be [OID to be assigned]. The requestValue of the ReplicationUpdate must be set to the BER-encoding of the following: requestValue ::= SEQUENCE { uniqueID UniqueIdentifier, Stokes and Good [Page 7] INTERNET-DRAFT LDUP Replication Update Protocol 22 October 1999 updates SET OF ReplicationPrimitive } 5.3.1 UniqueIdentifier The Distinguished Name of an entry may be changed (by renaming the entry), or the entry may not have a distinguished name (if it was deleted). The Unique Identifier provides an immutable name, independent of the current name or deletion status, for an entry. All replicated operations address entries by their Unique Identifiers. UniqueIdentifier ::= LDAPString 5.3.2 ReplicationPrimitive A ReplicationPrimitive carries a single assertion about the the final state of an entry, attribute, or attribute value. There are seven types of primitives. ReplicationPrimitive ::= CHOICE { addEntryPrimitive AddEntryPrimitive, moveEntryPrimitive MoveEntryPrimitive, renameEntryPrimitive RenameEntryPrimitive, removeEntryPrimitive RemoveEntryPrimitive, addAttributeValuePrimitive AddAttributeValuePrimitive, removeAttributeValuePrimitive RemoveAttributeValuePrimitive, removeAttributePrimitive RemoveAttributePrimitive } Each primitive applies to the entry referred to by the uniqueIdentifier in the enclosing ReplicationUpdate extended operation. Each primitive carries an lLDAPChangeSequenceNumber that is used by the consumer server to correctly resolve update conflicts. [URP] describes the update reconciliation procedures. 5.3.2.1 AddEntryPrimitive The AddEntryPrimitive is used to add a new entry. AddEntryPrimitive ::= [APPLICATION 0] SEQUENCE { csn lDAPChangeSequenceNumber, superior UniqueIdentifier, rdn RelativeLDAPDN } Parameters of the AddEntryPrimitive are: Stokes and Good [Page 8] INTERNET-DRAFT LDUP Replication Update Protocol 22 October 1999 - csn: The change sequence number of the primitive. - superior: The unique identifier of the superior (parent) entry. - rdn: The relative distinguished name of the new entry. 5.3.2.2 MoveEntryPrimitive The MoveEntryPrimitive is used to move an entry to a new location in the DIT. MoveEntryPrimitive ::= [APPLICATION 1] SEQUENCE { csn lDAPChangeSequenceNumber, superior UniqueIdentifier } Parameters of the MoveEntryPrimitive are: - csn: The change sequence number of the primitive. - superior: The unique identifier of the new superior (parent) entry. 5.3.2.3 RenameEntryPrimitive The RenameEntryPrimitive is used to change the RDN of an entry. RenameEntryPrimitive ::= [APPLICATION 2] SEQUENCE { csn lDAPChangeSequenceNumber, rdn RelativeLDAPDN } Parameters of the RenameEntryPrimitive are: - csn: The change sequence number of the primitive. - rdn: The new relative distinguished name of the entry. 5.3.2.4 RemoveEntryPrimitive The RemoveEntryPrimitive is used to delete an entry from the DIT. RemoveEntryPrimitive ::= [APPLICATION 3] SEQUENCE { csn lDAPChangeSequenceNumber } Parameters of the RemoveEntryPrimitive are: - csn: The change sequence number of the primitive. Stokes and Good [Page 9] INTERNET-DRAFT LDUP Replication Update Protocol 22 October 1999 5.3.2.5 AddAttributeValuePrimitive The AddAttributeValuePrimitive is use to add a new attribute value to an entry. AddAttributeValuePrimitive ::= [APPLICATION 4] SEQUENCE { csn lDAPChangeSequenceNumber, type AttributeDescription, value AttributeValue } Parameters of the AddAttributeValuePrimitive are: - csn: The change sequence number of the primitive. - type: The type of the attribute being added. - value: The value being added. Multiple values are not permitted. 5.3.2.6 RemoveAttributeValuePrimitive The RemoveAttributeValuePrimitive is used to remove a particular attribute value from an entry. RemoveAttributeValuePrimitive ::= [APPLICATION 5] SEQUENCE { csn lDAPChangeSequenceNumber, type AttributeDescription, value AttributeValue } Parameters of the RemoveAttributeValuePrimitive are: - csn: The change sequence number of the primitive. - type: The type of the attribute being removed. - value: The value being removed. Multiple values are not permitted. 5.3.2.7 RemoveAttributePrimitive The RemoveAttributePrimitive is used to remove an attribute and all its values from an entry. RemoveAttributePrimitive ::= [APPLICATION 6] SEQUENCE { csn lDAPChangeSequenceNumber, type AttributeDescription } Stokes and Good [Page 10] INTERNET-DRAFT LDUP Replication Update Protocol 22 October 1999 Parameters of the RemoveAttributePrimitive are: - csn: The change sequence number of the primitive. - type: The type of the attribute being removed. 5.4 EndReplicationRequest Extended Operation The EndReplicationRequest extended operation is sent from the replication supplier to the replication consumer to indicate the end of the sequence of replication updates. In the event that the supplier is sending a total update, the EndReplicationRequest extended operation contains a replica update vector. The consumer server must replace its replica update vector, if present, with the one provided by the suplier. In the event that the supplier is sending an incremental update, the replica update vector is absent. The EndReplicationRequest extended operation is defined as follows: EndReplicationRequest ::= [APPLICATION 23] SEQUENCE { requestName [0] LDAPOID, requestValue [1] OCTET STRING } The requestName of the EndReplicationRequest must be [OID to be assigned]. The requestValue of the EndReplicationRequest must be set to the BER-encoding of the following: requestValue ::= SEQUENCE { replicaUpdateVector Attribute OPTIONAL, returnConsumerUpdateVector BOOLEAN } If returnConsumerUpdateVector is TRUE, the consumer server must return its current update vector to the supplier in the EndReplicationResponse extended operation. Typically, the supplier will request the consumer's update vector for read-only replicas, since the read-only replica will never initiate a replication session, and will therefore never have the opportunity to provide its update vector to other servers. 5.5 EndReplicationResponse Extended Operation The EndReplicationResponse extended operation is sent by a consumer to a supplier in response to an EndReplicationRequest extended operation. Stokes and Good [Page 11] INTERNET-DRAFT LDUP Replication Update Protocol 22 October 1999 The EndReplicationResponse extended operation is defined as follows: EndReplicationResponse ::= [APPLICATION 23] SEQUENCE { requestName [0] LDAPOID, requestValue [1] OCTET STRING } The requestName of the EndReplicationResponse must be [OID to be assigned]. The requestValue of the EndReplicationResponse must be set to the BER-encoding of the following: requestValue ::= SEQUENCE { replicaUpdateVector Attribute OPTIONAL } The replicaUpdateVector contains the consumer's current replica update vector, and is optional. The consumer server should only send the replicaUpdateVector if requested by the supplier server in the EndReplicationRequest extended operation. 6. Semantics of Full and Incremental Update protocols 7. Summary of response codes The following list describes the response codes that may be included in the StartReplicationResponse, EndReplicationResponse, and ReplicationUpdateResponse extended operations. LDUPResponseCode ::= SEQUENCE { resultCode ENUMERATED { success (0), operationsError (1), protocolError (2), insufficientAccessRights (50), busy (51), excessiveCSNSkew (200), other (80) }, errorMessage LDAPString } The meanings of the response codes are as follows: success..................... As defined in [LDAPv3]. operationsError............. As defined in [LDAPv3]. protocolError............... As defined in [LDAPv3]. Stokes and Good [Page 12] INTERNET-DRAFT LDUP Replication Update Protocol 22 October 1999 insufficientAccessRights.... Access denied. The identity that the initiator provided in the bind request does not have sufficient privileges to perform the operation. busy........................ The replica is temporarily unable to accept updates. excessiveCSNSkew............ The consumer server has detected that the CSNs being generated by the supplier are too small (perhaps because the supplier's clock was set back). Updates from the supplier will not be applied. other....................... Some other error occurred. 8. Implications for log-based and state-based servers This should be covered in the Architecture document. 9. Replication of access control and schema information This should be covered in the Architecture document? 10. Security Considerations 11. Glossary of Terms Note: This probably shouldn't appear here, but rather in the architecture document. However, this "covered by" is a new concept I introduced here, so I've temporarily defined it here. Covered by: We say that a CSN is "covered by" an update vector if and only if the CSN is less than or equal to the component of the update vector corresponding to the replica ID in the CSN. In other words, given a CSN with components and an update vector with CSNs ,..., then the CSN is covered by the RUV if and only if one of the following holds for some value i: a) r = ri and t < ti b) r = ri and t = ti and S < Si c) r = ri and t = ti and S = Si and s < si 12. Acknowledgments 13. References [KEYWORDS] S. Bradner, "Key Words for use in RFCs to Indicate Requirement Stokes and Good [Page 13] INTERNET-DRAFT LDUP Replication Update Protocol 22 October 1999 Levels", Harvard University, RFC 2119, March 1997. [ARCHITECTURE] J. Merrells, E. Reed, U. Srinivasan, "LDAP Replication Architec- ture", Internet-Draft, draft-ietf-ldup-model-00.txt, April 1999. [LDAPv3] M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [URP]S. Legg, "LDUP Update Reconciliation Procedures", Internet-Draft, draft-legg-ldup-urp-00.txt, February 1999. [INFOMOD] E. Reed, "LDAP Replication Information Model", Internet-Draft, draft-reed-ldup-infomod-00.txt, November 1998. [REQ]R. Weiser, E. Stokes, "LDAP V3 Replication Requirements", Internet-Draft, draft-ietf-ldup-replica-req-00.txt, February 1999. 14. Author's Addresses Ellen Stokes IBM 11400 Burnet Rd Austin, TX 78758 USA EMail: stokes@austin.ibm.com phone: +1 512 838 3725 fax: +1 512 838 0156 Gordon Good America Online/Netscape 501 E. Middlefield Rd. Mailstop MV068 Mountain View, CA 94043 USA EMail: ggood@netscape.com Phone: +1 650 937-3825 This Internet Draft expires 22 April 2000 Appendix A - Complete ASN.1 Definition Stokes and Good [Page 14] INTERNET-DRAFT LDUP Replication Update Protocol 22 October 1999 Appendix A - Complete ASN.1 Definition To be provided. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of develop- ing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Stokes and Good [Page 15] --=====================_1357647==_-- From owner-ietf-ldup@imc.org Mon Oct 25 23:05:11 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16038 for ; Mon, 25 Oct 1999 23:05:10 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA24958 for ietf-ldup-bks; Mon, 25 Oct 1999 19:29:14 -0700 (PDT) Received: from dfw-smtpout2.email.verio.net (dfw-smtpout2-ext.email.verio.net [129.250.36.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA24953 for ; Mon, 25 Oct 1999 19:29:12 -0700 (PDT) Received: from dfw-mmp4.email.verio.net ([129.250.38.64]) by dfw-smtpout2.email.verio.net (Netscape Messaging Server 4.04) with ESMTP id FK6V1Q00.UFR for ; Tue, 26 Oct 1999 02:32:14 +0000 Received: from nma.com ([209.21.28.126]) by dfw-mmp4.email.verio.net (Netscape Messaging Server 4.04) with ESMTP id FK6V0Y00.4TL; Tue, 26 Oct 1999 02:31:46 +0000 Message-ID: <381512BF.8B05F2AC@nma.com> Date: Mon, 25 Oct 1999 19:32:31 -0700 From: Ed Gerck X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Harald Tveit Alvestrand CC: directory@apps.ietf.org, ietf-ldapext@netscape.com, ietf-ldup@imc.org, namedroppers@internic.net, policy@raleigh.ibm.com, iab@ietf.org Subject: Re: FYI: Directory definitions document References: <4.2.0.58.19991024193424.01cbf540@dokka.maxware.no> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Harald Tveit Alvestrand wrote: > FYI, the following draft just came out: > > Title : Definitions for talking about directories > Author(s) : H. Alvestrand > Filename : draft-alvestrand-directory-defs-00.txt > Pages : 6 > Date : 21-Oct-99 > > Comments welcome! Harald: The draft says: - Information: Something for which one can imagine multiple worlds where the item in question has different values. The fact of which particular value is true for this world is information. This definition is extremely abstract, and intentionally so, but on a philosophical level, it's closely related to Shannon's signal-theory definition of "information". But, this is not correct. In particular, if "The fact of which particular value is true for this world" is information then information has zero suprise -- hence, it cannot be Shannon's information. In other words, information in Shannon's sense is that which is not expected. If the particular value is true for this world then that value is expected and has zero information. Which contradicts the draft's definition. I suggest the draft does not redefine information. I also would tend to think that notification services are built around directories, but they do not define a new class of directories. The inclusion of notification services is thus IMO not necessary. Other terms seem also not to be necessary (subscription) to define the basic functionality needed as a common building block. So, I suggest that the draft should, in general, not redefine or even define what is not needed. Cheers, Ed Gerck From owner-ietf-ldup@imc.org Tue Oct 26 08:18:46 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03090 for ; Tue, 26 Oct 1999 08:18:45 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id EAA24019 for ietf-ldup-bks; Tue, 26 Oct 1999 04:38:25 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA24014 for ; Tue, 26 Oct 1999 04:38:23 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02401; Tue, 26 Oct 1999 07:41:25 -0400 (EDT) Message-Id: <199910261141.HAA02401@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldup-urp-02.txt Date: Tue, 26 Oct 1999 07:41:24 -0400 Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF. Title : LDUP Update Reconciliation Procedures Author(s) : S. Legg, A. Payne Filename : draft-ietf-ldup-urp-02.txt Pages : 26 Date : 25-Oct-99 This document describes the procedures used by directory servers to reconcile updates performed by autonomously operating directory servers in a distributed, replicated directory service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldup-urp-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldup-urp-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991025151042.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-urp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-urp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991025151042.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@imc.org Wed Oct 27 18:18:46 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13334 for ; Wed, 27 Oct 1999 18:18:45 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA14750 for ietf-ldup-bks; Wed, 27 Oct 1999 14:31:44 -0700 (PDT) Received: from dir1.control.att.com ([135.207.251.15]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14744 for ; Wed, 27 Oct 1999 14:31:42 -0700 (PDT) Received: from att.com (pest.control.att.com [135.207.251.76]) by dir1.control.att.com (Postfix) with ESMTP id 95EE471C2 for ; Wed, 27 Oct 1999 17:39:19 -0400 (EDT) Message-ID: <38176C52.D8C3E599@att.com> Date: Wed, 27 Oct 1999 17:19:14 -0400 From: Chris Apple Organization: AT&T Labs X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ldup@imc.org Subject: WG Meeting slot Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit FRIDAY, November 12, 1999 0800-1000 IETF Registration - West Conference Center 0800-0900 Continental Breakfast - Bird Cage Walk 0900-1130 Morning Sessions Executive APP ldup LDAP Duplication/Replication/Update Protocols WG We're on the agenda. Chris. From owner-ietf-ldup@imc.org Thu Oct 28 09:08:18 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18931 for ; Thu, 28 Oct 1999 09:08:17 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id EAA06181 for ietf-ldup-bks; Thu, 28 Oct 1999 04:26:50 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA06177 for ; Thu, 28 Oct 1999 04:26:48 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14960; Thu, 28 Oct 1999 07:30:01 -0400 (EDT) Message-Id: <199910281130.HAA14960@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldup-model-02.txt Date: Thu, 28 Oct 1999 07:30:00 -0400 Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF. Title : LDAP Replication Architecture Author(s) : J. Merrells, E. Reed, U. Srinivasan Filename : draft-ietf-ldup-model-02.txt Pages : 44 Date : 27-Oct-99 This architectural document outlines a suite of schema and protocol extensions to LDAPv3 that enables the robust, reliable, server-to- server exchange of directory content and changes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldup-model-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldup-model-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991028063815.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-model-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-model-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991028063815.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@imc.org Thu Oct 28 10:28:46 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23074 for ; Thu, 28 Oct 1999 10:28:42 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA07646 for ietf-ldup-bks; Thu, 28 Oct 1999 06:00:06 -0700 (PDT) Received: from monet.digsigtrust.com ([208.30.69.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA07642 for ; Thu, 28 Oct 1999 06:00:04 -0700 (PDT) Received: from digsigtrust.com (rfwlaptop.digsigtrust.com [208.30.64.125]) by monet.digsigtrust.com (8.9.3/8.9.3) with SMTP id HAA08057; Thu, 28 Oct 1999 07:01:59 -0600 (MDT) Message-ID: <3818471D.6BA990AD@digsigtrust.com> Date: Thu, 28 Oct 1999 06:52:45 -0600 From: "Russel F. Weiser" X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ellen Stokes , rvh@qsun.ho.att.com, Chris Apple , ietf-ldup@imc.org Subject: Revised draft-ietf-ldup-replica-02.txt Content-Type: multipart/mixed; boundary="------------186DDE35220523D8637CB2A2" Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------186DDE35220523D8637CB2A2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rich and LDUP, Rick Huber pointed out that a phrase in 5.5 needed correction to read correctly. I made the change but kept the version and date information of the draft the same since I only changed a 4 word phrase. cheers RFW --------------186DDE35220523D8637CB2A2 Content-Type: text/plain; charset=iso-8859-1; name="draft-ietf-ldup-replica-req-02.txt" Content-Disposition: inline; filename="draft-ietf-ldup-replica-req-02.txt" Content-Transfer-Encoding: 8bit INTERNET-DRAFT Russel F. Weiser Informational Draft Digital Signature Trust Co. Expires 21 April 2000 Ellen Stokes IBM 21 October 1999 LDAP V3 Replication Requirements Status of this Memo This document is am Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Drafts Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document discusses the fundamental requirements for replication of data accessible via the LDAPv3 [RFC2251] protocol. It is intended to be a gathering place for general replication requirements needed to provide interoperability between informational directories. The key words MUST, MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Weiser & Stokes 21 April 2000 [PAGE 1] INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 Table of Contents 1.Introduction.....................................................3 2. Terminology.....................................................3 3. Objective.......................................................5 4. Applicability Statement.........................................5 5. Replication Model..............................................10 6. Replication Protocol...........................................12 7. Schema.........................................................13 8. Administration and Management Considerations...................13 9. Acknowledgement................................................14 10. References....................................................15 11. Author's Address..............................................15 Weiser & Stokes 21 April 2000 [Page 2] INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 1. Introduction The ability to distribute directory information throughout the network provides a two fold benefit to the network: (1) increasing the reliability of the directory through fault tolerance, and (2) brings the directory content closer to the clients using the data. LDAP’s acceptance as an access protocol for directory information is driving the need to distribute LDAP directory content among servers within enterprise and Internet. Currently LDAP does not define a replication mechanism and only generally mentions LDAP shadow servers (see [RFC2251] and [Changelog]) in passing. The requirements for replication are critical to the successful deployment and acceptance of LDAP in the market place. 2. Terminology For the purposes of this document, the following terminology definitions are used: Area of replication - A whole or portion of a directory tree(DIT) making up a distinct unit of data to be replicated. This may also be known as "unit of replication". Atomic operation - The ability to treat and contain several updates or attribute changes as a single operation for replication purposes to guarantee that the several updates or attribute changes are propagated to a replica as a single unit. Authoritative Master Replica - The Primary updateable replica of the replicated information. Conflict resolution - Deterministic procedures within replication protocols, utilized to resolve change information conflicts that may arise due to conflicting changes affecting a directory entry. Fractional replication - The capability to replicate a subset of attributes of any given entry. Incremental Update - The process of updating a replica, or copy, of a naming context, by updating only those fields or objects which have changed. Master Slave, or Single Master Replication - Replication model that assumes only one server, the master, allows write access to the replicated data. Note that Master-Slave replication can be considered a proper subset of multi-master replication. Weiser & Stokes 21 April 2000 [Page 3] INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 Multi-Master Replication - A replication model where entries can be written and updated on any of several updateable replica copies without requiring communication with other updateable replicas before the write or update is performed. Naming Context - Suffix of a Sub-tree. A sub-tree of entries held in a single server [X.500]. One-way Replication - The process of synchronization in a single direction where the authoritative source information is provided to a replica. Partial Replication - The capability to replicate some subset of entries in a naming context. Propagation behavior - The general behavior of the actual synchronization process between a consumer and a provider of replication information. Read-only Replica - A read-only copy of a replicated directory. A read-only replica is assumed to be a slave replica of master slave or single master replication definition. Replica - A single instance of a whole or portion of the Directory tree (DIT) as defined by area of replication. Replica Ring - A set of servers, which hold in common the same DIT information as, defined by “Area of replication”. These servers may be managed under a single replication agreement that handles all members of the set of servers as a group. Replica Cycle - When a change or groups of changes need to be propagated to the other member of a replica ring. The process of contacting a replica member would be considered the beginning of a replication cycle; the termination of communications with a replica is the end of the cycle whether its due to an error or successful exchange of update records. Replication - The process of copying portions of naming context information and content between multiple LDAP servers, such that certain predefined portions of the information are available from different servers. Replication can occur between either homogeneous implementations across heterogeneous platforms (operating systems) or heterogeneous implementations supporting identical replication across heterogeneous platforms (operating systems). Sparse Replica - A incomplete copy of a sub-tree which maybe inclusive with updateable, or Read-only. See Partial replication and Weiser & Stokes 21 April 2000 [Page 4] INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 Fractional replication. Topology - Refers to the shape of the directed graph describing the relationships between replicas, as in the replicated directory topology. Two-way Replication - The process of synchronization where change information may flow bi-directionally between two replica. Update Propagation - Protocol-based process by which directory replicas are reconciled. Updateable Replica - A Non-authoritative read-writeable copy of the replicated information. Such that during conflict resolution a authoritative master takes precedents in resolving conflicts. 3. Objective The major objective is to provide an interoperable LDAP V3 directory synchronization protocol which is simple, highly efficient and flexible enough to support both multi-master and master-slave replication operations to meet the needs of both the internet and enterprise environments. 4. Applicability Statement Generally replication can be characterized by looking at data consistency models across existing technologies. This may provide insight to LDAP v3 replication requirements. The following is a brief examination of the following data models. Model 1: Tight Consistency -- Includes environments where all replicas must always contain exactly the same directory content. Two phase commit transaction models may be used to preserve transaction consistency. Model 2: Eventual Consistency or Transient Consistency -- Includes X.500 Directories, Bayou [XEROX], and NDS (Novell Directory Services) names service where definite knowledge of the global replica topology is provided through predetermined replication agreements. Such that every update propagates to every replica that it can reach via a path of stepwise eventual connectivity. Transaction consistency is preserved for transactions directed at the master server in X.500 implementations. NDS additionally provides deterministic consistency over time to all replicas due to its inherent replication policies. Weiser & Stokes 21 April 2000 [Page 5] INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 Model 3: Limited Effort Eventual Consistency -- Includes Xerox Clearinghouse [XEROX] that provides a statistical probability of convergence with global knowledge of replica topology. Similar to "Eventual Consistency", except where replicas may purge updates therefore dropping propagation changes when some replica time boundary is exceeded, thus leaving some changes replicated to a portion of the replica topology. Transactional consistency is not preserved, though some weaker constraints on consistency are available. Model 4: Loosest Consistency -- Includes opportunistic or simple cache where information is provided from the cache until stale. Model 5: Ad hoc -- A copy of a date store where no follow up checks are made for the accuracy/freshness of the data. Consistency models 2, and 3 involve the use of prearranged replication agreements or "Predefined Replication Agreements" between cooperating servers. The complexity of Model 1's use of 2- phase commit adds additional overhead that should not considered at this time. Models 4 and 5 involve unregistered replicas which "pull" updates from another directory server without that server's knowledge. These models can be considered to violate a directory's security policies. Therefore models 1, 4, and 5 are declared to be out of scope of this working group. So through further review of these consistency models two application areas can then be derived with even further characterizations of the data types usages. Eventual Consistency or Transient Consistency (Model 2) - This model provides policy configuration through security management parameters; the data is more dynamic and utilizes dynamic address information. Limited Effort Eventual Consistency (Model 3) - This model matches a white-pages environment which contains fairly static data and address information. This model mainly replicates message attributes. Therefore it is believed an LDAP replication should be flexible enough to cover the above range of capabilities. The generalized use of LDUP replication environment is to provide for the distribution of LDAP directory information in order to improve accessibility and consistency of the information held by the directory. 4.1 Replication Scenarios Weiser & Stokes 21 April 2000 [Page 6] INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 The following directory deployment examples are intended to substantiate and validate our replication requirements. It is assumed in all cases that directory implementations from different vendors are involved. 4.1.1 Extranet Example A company has a trading partner to whom it wishes to provide directory information. This information may be as simple as a corporate telephone directory, or as complex as an extranet work flow application. For performance reasons the company may wish to have a replica of its directory within the Partner Company, rather than simply exposed beyond its firewall. The requirements, which follow from this scenario, are: - One-way replication, single mastered. - Authentication of clients. - Common access control and access control identification. - Secure transmission of updates. - Selective attribute replication (Fractional Replication), so that only partial entries can be replicated. 4.1.2 Consolidation Example Company A acquires company B. In the transition period, whilst the organizations are merged, both directory services must coexist. Company A may wish to attach company B's directory to its own. The requirements, which follow from this scenario, are: - Multi-Master replication. - Common access control model. Access control model identification. - Secure transmission of updates. - Replication between DITs with potentially differing schema. 4.1.3 Replication Heterogeneous Deployment Example An organization may deliberately deploy multiple directory services within their enterprise to employ the differing benefits of each service. In this case multi-master replication will be required to ensure that the multiple updateable replicas of the DIT are synchronized. Some vendors may provide directory clients, which are tied to their own directory service. The requirements, which follow from this scenario, are: - Multi-Master replication Weiser & Stokes 21 April 2000 [Page 7] INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 - Common access control model and Access control model identification. - Secure transmission of updates. - Replication between DITs with potentially differing schemas. 4.1.4 Shared Name Space Example Two organizations may choose to cooperate on some venture and need a shared name space to manage their operation. Both organizations will require administrative rights over the shared name space. The requirements, which follow from this scenario, are: - Multi-Master replication. - Common access control model and Access control model identification. - Secure transmission of updates. 4.1.5 Supplier Initiated Replication A single master environment, which maintains a number of replicas of the DIT by pushing changes, based on a defined schedule. The requirements, which follow from this scenario, are: - Single-master environment. - Supplier-initiated replication. - Secure transmission of updates. 4.1.6 Consumer Initiated Replication Again a single mastered replication topology, but the replica initiates the replication exchange rather than the master. An example of this is a replica that resides on a laptop computer that may run disconnected for a period of time. The requirements, which follow from this scenario, are: - Single-master environment. - Consumer initiated replication. - Open scheduling (anytime). 4.1.7 Prioritized attribute replication The password attribute can provide an example of the requirement for prioritized attribute replication. A user is working in Utah and the administrator resides in California. The user has forgotten his password. So the user calls or emails the administrator to request a new password. The administrator provides the updated password (a change). Policy states that this attribute is critical and must be Weiser & Stokes 21 April 2000 [Page 8] INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 available to the user for login immediately (e.g. shortly) after the administrator changed it. Replication needs to occur immediately for critical attributes/objects. The requirements, which follow from this scenario, are: - Incremental replication of changes. - Automatic replication on change of certain attributes. - Replicate based on time/attribute semantics. 4.1.8 Bandwidth issues The replication of Server (A) R/W replica (a) in Katmandu is handled via a dial up phone link to Paris where server (B) R/W replica of (a) resides. Server (C) R/W replica of(a) is connected by a T1 connection to server (B). Each connection has a different performance characteristic. The requirements, which follow from this scenario, are: - Minimize repetitive updates when replicating from multiple replication paths. - Incremental replication of changes. - Provide replication cycles to delay and/or retry when connections can not be reached. - Allowances for consumer initiated or supplier initiated replication. 4.1.9 Interoperable Administration and Management The administrator with administrative authority of the corporate directory which is replicated by numerous geographically dispersed LDAP servers from different vendors notices that the replication process is not completing correctly as the change log is continuing to grow and/or error message informs him. The administrator uses his $19.95 RepCo LDAP directory replication diagnostics tools to look at Root DSE replica knowledge on server 17 and determines that server 42 made by LDAP’RUS Inc. is not replicating properly due to an Object conflict. Using his Repco Remote repair tools he connects to server 42 and resolves the conflict on the remote server. The requirements, which follow from this scenario, are: - Provides replication audit history. - Provisions for managing conflict resolution. - Provide LDAP access to predetermined agreements, topology and policy attributes. - Provide operations for comparing replica’s content for validity. - Provide LDAP access to status and audit information. Weiser & Stokes 21 April 2000 [Page 9] INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 4.1.10 Enterprise Directory Replication Mesh A Corporation builds a mesh of directory servers within the enterprise utilizing LDAP servers from various vendors. Five servers are holding the same area of replication. The predetermined replication agreement(s) for the enterprise mesh are under a single management, and the security domain allows a single predetermined replication agreement to manage the 5 servers replication. The requirements, which follow from this scenario, are: - Predefined replication agreements that manage more than a single area of replication that is held on numerous servers. - Common support of replication management knowledge across vendor implementation. - Rescheduling and continuation of a replication cycle when one server in a replica ring is busy and/or unavailable. 5. Replication Model 5.1 LDAP Replication MUST be allowed to span different vendors directory services in order to provide interoperability. 5.2 All replicas MUST eventually be updated with the changed information, if specified by the replication policy. 5.3 Replication schedules MUST be configurable to allow for periodic replication, with the replication period determined by administrator of the replicated system. 5.4 Replication Model MUST enable replication cycle to be initiated on change or based on the number of pending changes. 5.5 The replication model MUST allow for administrative initiation of replication cycle for any replica that may have just come back online or was unavailable during previous replication cycles. 5.6 The replication model MUST support both master-slave and authoritative multi-updateable replica relationships. 5.7 All replicated information between the master database and its replica databases MUST be identical including all non-user modify operational attributes such as time stamps. Note this does not imply that the entire database is identical from replica to replica, but that the subset of data, chosen to replicate is identical from replica to replica. Some operational attributes may be dynamically evaluated; these attributes will not necessarily appear to be identical. Weiser & Stokes 21 April 2000 [Page 10] INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 5.8 In distributed multi-vendor environment, LDAP replication MUST NOT require all copies of the replicated information be complete copies of the replicated object. 5.9 LDAP replication MUST encompass common schema objects and attributes, access control, and name space information. 5.10 Sub-tree Replication MUST be defined to allow for greater flexibility in replication topologies of the DIT as defined by the area of replication called partial replication. 5.11 Replication of critical values MUST be synchronized and have priority over non-critical values. An example of a critical value might be a password or certificate value. 5.12 Replication activities MUST occur within the context of a predefined replication agreement that addresses proper knowledge of access requirements and credentials between the synchronizing directories. Currently X.525 DISP [X.525] discusses this as a shadowing agreement including such information as unit of replication, update mode, and access point defining many of the policies between the master and a replica. 5.13 The acceptance and usage of the Internet requires that LDAP replication be available across disparate vendor directory services. 5.14 LDAP replication MUST provide scalability to both enterprise and Internet environments, e.g. an LDAP server may provide replication services to replicas within an enterprise as well as across the Internet. 5.15 The replication model MUST define deterministic policy such that replication cycle startup time conflicts between two or more competing master replicas may be resolved programmatically. An example might be automatic submission and rescheduling by one of the masters. In such a case, these replication "conflicts" MUST be resolved by the replication policy. 5.16 Any replication capable LDAP server MUST allow replication where the 2 replicating servers agree they can replicate. This may be accomplished through administrative agreements assuming compatible access control model and common schema are provided. 5.17 The replication model MUST be able to handle convergence and resurrection of attributes and objects. This is a consequence of delete and move with respect to the replication process. Weiser & Stokes 21 April 2000 [Page 11] INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 5.18 It is not realistic to assume that all vendors have cooperating schemas, but that replication may be allowed between diverse schema. The Model MAY allow for replication between divergent schema of objects. 6. Replication Protocol 6.1 The act of replication SHOULD have minimal impact on both the system and network performance. 6.2 The replica synchronization SHOULD be handled in such a manner as to not saturate network with repetitive entry replication from multiple synchronization providers points. 6.3 Replication MUST only be allowed after the authentication and verification of authorization of both the replica and the source directory. 6.4 The transport for LDAP synchronization MUST allow for the integrity and confidentiality of each replicated server. 6.5 Replicated data MUST be transferable in a secure manner. 6.6 Replication protocol MUST provide for recovery and rescheduling of a replication cycle due to a replication initiation conflicts (e.g. consumer busy replicating with other servers) and or loss of connection(e.g. supplier cannot reach a replica). The replication protocol MUST include restarting at the last acknowledged update prior to interruption rather than re-sending updates it had already sent to a consuming replica. 6.7 LDAP replication MUST allow for full update to facilitate replica initialization and reset loading utilizing a standardized format such as LDIF [LDIF] format. 6.8 The replication standard SHOULD NOT limit the size of a replica. The area of replication is defined to be a whole or portion of a DIT, also allowing a portion of a naming context to be replicated. Incremental replication SHOULD be allowed. 6.9 The replication agreements MUST accommodate multiple servers receiving the same replica under a single predefined agreement. 6.10 The replication protocol MUST allow either a master or replica to initiate the replication process. 6.11 Additionally the initiator MUST be allowed to determine whether it will become a consumer or supplier during the synchronization startup process. This would allow a replica to Weiser & Stokes 21 April 2000 [Page 12] INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 be periodically connected and synchronized from remote sites at the local administrator's discretion. 6.12 Multiple LDAP changes to a single server: If transactional consistency is propagated during replication, then multiple LDAP changes submitted to a single server SHOULD BE treated as a single 'atomic unit of work'. 6.13 An LDAP Replication Standard SHOULD NOT limit the transaction rate of a replication session. 6.14 Entry change information MUST be purged or discarded in a timely manner when change information becomes outdated due to propagated to all replica members. 7. Schema 7.1 Replica knowledge MUST be provided as DSE attributes. 7.2 The Replication Protocol documents MUST define standard schema for representing replication agreements, and MUST define the semantics associated with modifying the attributes of replication agreements. The documents MUST also define a standard method for determining the location of these agreements accessible utilizing LDAP. 7.3 The Replication Protocol documents MUST define standard schema for publishing state information about a given replica, and MUST define a standard method for determining the location of this information. 7.4 A location independent management point MUST be defined to provide authorized administrators with well known access to the replication policies, regardless of network location. 7.5 Replication agreements of all servers containing replicated information MUST be accessible via LDAP. 7.6 All objects MUST be uniquely identifiable throughout the object lifetime . 8. Administration and Management Considerations 8.1 Replication policies MUST allow replication of changed information to be administratively postponed to a more Weiser & Stokes 21 April 2000 [Page 13] INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 convenient period. 8.2 Allowance for non-scheduled replication of a replica MUST be provided upon request such that the replica server has been down or unconnected for a period of time. 8.3 Each copy of a replica MUST maintain audit history information of which servers it has replicated with and which servers have replicated with it. 8.4 A replica MUST store conflicted versions of the replicated object to allow optional human review and intervention. 8.5 Access to replication predetermined agreements, topologies, and policies attributes MUST be provided through LDAP access. 8.6 The capability to check the differences between two replicas for the same information SHOULD be provided for. This should entail a client invoking an operation at some server, which causes that server to extract the contents from some other server it has a replication agreement with and report the differences back to the client as the result. 8.7 Authenticated access SHOULD be provided so that Administrative LDAP clients may query a server for the current state and replication history for each replica that the server maintains replication agreements with. 8.8 The ability to view replication conflicts, and override the resolution derived by the replication policy MUST be provided. 8.9 The deletion of sensitive data MUST be handled in an orderly manner so that at no time will that data be available without proper access control. That is, access control information (ACI) associated with sensitive data must be deleted after or simultaneously with the delete of the sensitive data. Likewise, when adding sensitive data, ACI MUST be added first or simultaneously with the addition of that data. 9. Acknowledgement This document is based on input from IETF members interested in LDUP Replication. Weiser & Stokes 21 April 2000 [Page 14] INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 10. References [RFC2251] M. Wahl, T. Howes, S. Kille "Lightweight Directory Access Protocal", RFC 2251. [RFC2119] S.Bradner, " Key words for use in RFCs to indicate Requirement Levels", RFC 2119. [LDIF] Gordon Good, "The LDAP Data Interchange Format (LDIF)", Internet draft, draft-ietf-asid-ldif-00.txt, November 1996. [Changelog] Gordon Good, "Definitions of an Object Class to Hold LDAP Change records", Internet Draft, draft-ietf-asid-changelog- 00.txt, November 1996. [X.501] ITU-T Recommendation X.501 (1993), | ISO/IEC 9594-2: 1993, Information Technology - Open Systems Interconnection - The Directory: Models [XEROX] Hauser, C. "Managing update conflicts in Bayou, a weakly connected replicated storage system". Palo Alto, CA: Xerox PARC, Computer Science Laboratory; 1995 August; CSL-95-4. [CSL-95-04] 11. Author's Address Russel F. Weiser Digital Signature Trust Co. One South Main Street Salt Lake City, Utah 84111 USA E-mail: rweiser@digsigtrust.com Telephone: +1-801-983-4415 Fax +1-801-983-4408 Ellen J. Stokes IBM 11400 Burnet Rd. Austin, Texas 78758 USA E-mail: stokes@austin.ibm.com Telephone: +1-512-838-3725 Fax: +1-512-838-0156 Weiser & Stokes 21 April 2000 [Page 15] --------------186DDE35220523D8637CB2A2-- From owner-ietf-ldup@imc.org Fri Oct 29 09:47:24 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25076 for ; Fri, 29 Oct 1999 09:47:22 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA14990 for ietf-ldup-bks; Fri, 29 Oct 1999 06:07:17 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA14986 for ; Fri, 29 Oct 1999 06:07:16 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23188; Fri, 29 Oct 1999 09:10:33 -0400 (EDT) Message-Id: <199910291310.JAA23188@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldup-protocol-00.txt Date: Fri, 29 Oct 1999 09:10:32 -0400 Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF. Title : The LDUP Replication Update Protocol Author(s) : E. Stokes, G. Good Filename : draft-ietf-ldup-protocol-00.txt Pages : 15 Date : 28-Oct-99 The protocol described in this document is designed to allow one LDAP server to replicate its directory content to another LDAP server. The protocol is designed to be used in a replication configuration where multiple updatable servers are present. Provisions are made in the protocol to carry information that allows the server receiving updates to apply a total ordering to all updates in the replicated system. This total ordering allows all replicas to correctly resolve conflicts that arise when LDAP clients submit changes to different servers that later replicate to one another. All protocol elements described here are LDAP Version 3 extended operations. LDAP Version 3 is described in RFC 2251 [LDAPv3]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-protocol-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldup-protocol-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldup-protocol-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991028144604.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-protocol-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-protocol-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991028144604.I-D@ietf.org> --OtherAccess-- --NextPart--