HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 10:08:30 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Mon, 21 Sep 1998 11:40:00 GMT ETag: "361a77-114e5-36063b10" Accept-Ranges: bytes Content-Length: 70885 Connection: close Content-Type: text/plain INTERNET-DRAFT draft-merrells-ldup-model-00.txt John Merrells Netscape Communications Corp. Ed Reed Novell, Inc. Uppili Srinivasan Oracle, Inc. August 5, 1998 LDAP Replication Architecture Copyright (C) The Internet Society (1998). All Rights Reserved. Status of this Memo This draft, file name draft-merrells-ldup-model-00.txt, is intended to be become a Proposed Standard RFC, to be published by the IETF Working Group LDUP, when it is formed. Distribution of this document is unlimited. Comments should be sent to the LDUP Replication mailing list or to the authors. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or made obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). This Internet-Draft expires on 5 February 1999. Merrells, Reed, Srinivasan [Page 1] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 1. Abstract This architectural document outlines a suite of schema and protocol extensions to LDAPv3 that enables the robust, reliable, server-to- server exchange of directory content and changes. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. The sections below reiterate these definitions and include some additional ones. Merrells, Reed, Srinivasan [Page 2] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 2. Table of Contents 1. Abstract 2 2. Table of Contents 3 3. Introduction 4 3.1 Scope 4 3.2 Document Objectives 5 3.3 Document Non-Objectives 6 3.4 Terms and Definitions 7 4. Overview 8 4.1 Directory Model 8 4.2 Information Model 8 4.3 Policy Information 9 4.4 Update Transfer Protocol 9 4.5 Replication Configuration and Management 9 4.6 Update Vector 10 4.7 Time 10 5. Directory Model 10 5.1 Replica Type 10 5.2 Sub-Entries 11 5.3 LDAP Change Sequence Numbers 11 5.4 State Storage and Representation 12 5.5 LDAP Update Operations 13 5.6 Purging State Information 13 5.7 Replication Schedule 14 6. Information Model 14 6.1 Entries, Semantics & Relationships 15 6.1.1 Root DSE Attributes 15 6.1.2 Naming Context Auxiliary Object Class and Entries 15 6.1.3 Replica Object Class and Entries 15 6.1.4 Replication Agreement Object Class and Entries 16 6.1.5 Update Vector 16 6.2 Unique Identifiers 17 7. Policy Information 17 7.1 Access Control 18 7.2 Schema Knowledge 18 8. Update Transfer Protocol 19 8.1 Session Initiation 19 8.1.1 Authentication 19 8.1.2 Consumer Initiated 19 8.1.3 Supplier Initiated 20 8.1.4 Start Replication Request 20 8.1.5 Start Replication Response 21 8.2 Update Transfer 21 8.2.1 Full Update Transfer 22 8.2.2 Incremental Update Transfer 22 Merrells, Reed, Srinivasan [Page 3] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 8.2.2.1 Conflict Detection and Resolution 23 8.3 End Replication Session 24 8.3.1 Full Update End Replication Session 24 8.3.2 Incremental Update End Replication Session 24 8.3.3 End Replication Request 25 8.3.4 End Replication Response 25 8.4 Integrity & Confidentiality 26 9. Replication Configuration and Management 26 10. Time 28 11. Security Considerations 28 12. Acknowledgements 28 13. References 29 14. Intellectual Property Notice 30 15. Copyright Notice 30 16. Authors' Address 31 17. Appendix A - Open Issues 32 17.1 Replication Session Initiation 32 17.2 Lost and Found Container 32 17.3 Write Conflicts 32 17.4 Management and Configuration 32 17.5 Sparse, Fractional, and Partial Replicas 33 17.6 Update Transfer: Errors, Recovery, Diagnostics and Repair 33 17.7 Update Access Control 33 3. Introduction 3.1 Scope This architectural document provides an outline of an LDAP based replication scheme. Further detailed design documents will draw guidance from here. The design proceeds from prior work in the industry, including concepts from the ITU-T Recommendation X.525 (1993, 1997) Directory Information Shadowing Protocol (DISP) [X525], experience with widely deployed distributed directories in network operating systems, electronic mail address books, and other database technologies. The emphasis of the design is on: - Simplicity of operation, - Flexibility of configuration. Merrells, Reed, Srinivasan [Page 4] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 - Manageability of replica operations among mixed heterogeneous vendor LDAP servers under common administration. - Security of content and configuration information when LDAP servers from more than one administrative authority are interconnected. A range of deployment scenarios are supported, including multi-master and single-master topologies. Replication networks may include transitive and redundant relationships between LDAP servers. The controlling framework used to define the relationships, types, and state of replicas of the directory content is defined. In this way the directory content can itself be used to monitor and control the replication network. The directory schema is extended to define object classes, auxiliary classes, and attributes that describe areas of the namespace which are replicated, LDAP servers which hold replicas of various types for the various partitions of the namespace, LDAP Access Points (network addresses) where such LDAP servers may be contacted, which namespaces are held on given LDAP servers, and the progress of replication operations. Among other things, this knowledge of where directory content is located will provide the basis for dynamic generation of LDAP referrals for clients to follow. [REF] An update transfer protocol, which actually brings a replica up to date with respect to changes in directory content at another replica, is defined using LDAPv3 protocol extensions. The representation of directory content and changes will be defined by the LDAP Replication Update Transfer Protocol sub-team. Incremental and full update transfer mechanisms are described. Replication protocols are required to include initial population, change updates, and removal of directory content. Security information, including access control policy will be treated as directory content by the replication protocols. Confidentiality and integrity of replication information is required to be provided by lower-level transport/session protocols such as IPSEC and/or TLS. The architecture will describe required and optional house-keeping duties for compliant systems to implement, such as garbage collection of deleted entries. 3.2 Document Objectives The following list enumerates the objectives of this document. a) To define the architectural foundations for LDAP Replication, so that further detailed design documents may be written. For Merrells, Reed, Srinivasan [Page 5] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 instance, the Information Model, Update Transfer Protocol, and Conflict Detection and Resolution documents. b) Provide an architectural solution for each clause of the requirements document [LDUP Requirements]. c) To preserve the atomicity of LDAP operations. Updates to an entry, from multiple sources, will be combined such that the resultant entry is equivalent to a serial execution of the operations. d) To avoid tying the LDUP working group to the schedule of any other working group. e) Not to infringe known registered intellectual property. 3.3 Document Non-Objectives This document does not address the following issues, as they are considered beyond the scope of the Working Group. The following list describes the features we are not addressing in this document. a) How LDAP becomes a distributed directory. There are many issues beyond replication that should be considered. Such as, support for external references, algorithms for computing referrals from the distributed directory knowledge, etc. b) Specifying management protocols to create naming contexts or new replicas. LDAP may be sufficient for this. The document describes how new replicas and naming contexts are represented, in the directory, as entries, attributes, and attribute values. c) How transactions will be replicated. However, the architecture should not knowingly prevent or impede them, given the Working Group's incomplete understanding of the issues at this time. d) The mapping or merging of disparate Schema definitions. e) Support of overlapping replicated regions. f) The case where separate attributes of an entry may be mastered by different LDAP servers. This might be termed a 'Split Primary'. Replica roles are defined in section 5.1. Merrells, Reed, Srinivasan [Page 6] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 3.4 Terms and Definitions The definitions from the Replication Requirements document have been copied here and extended. For brevity, an LDAP server implementation to referred to throughout as 'the server'. The Naming Context is a subtree of entries in the Directory Information Tree (DIT). There may be multiple Naming Contexts stored on a single server. Naming contexts are defined in section 17 of X.501 A Replica is an instance of a replicated Naming Context. A Replication Relationship is established between two or more Replicas that are hosted on servers that cooperate to service a common area of the DIT. A Replication Agreement is defined between two parties of a Replication Relationship. The properties of the agreement codify the Unit of Replication, the Update Transfer Protocol to be used, and the Replication Schedule of a Replication Session. A Replication Session is an LDAP session between the two servers identified by a replication agreement. Interactions occur between the two servers, resulting in the transfer of updates from the supplier replica to the consumer replica. The Initiator of a Replication Session is the initiating server. A Responder server responds to the replication initiation request from the Initiator server. A Supplier server is the source of the updates to be transferred. A Consumer server is the recipient of the update sequence. The Update Transfer Protocol is the means by which the Replication Session proceeds. It defines the order of events, and update exchange mechanism between the Replication Relationship partners. An Entry Filter is an LDAP filter expression that describes the entries to be replicated. A Sparse Replica contains a subset of the naming context entries, being modified by the Entry Filter criteria associated with the replica. Merrells, Reed, Srinivasan [Page 7] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 A Fractional Entry Specification is a list of entry attributes to be included, or a list of attributes to be excluded in a replica. An empty specification implies that all entry attributes are included. A Fractional Entry is an entry that contains only a subset of its original attributes. It has been modified by a Fractional Entry Specification. A Fractional Replica is a replica that holds Fractional Entries of its naming context. Note that a Fractional Replica can also be a sparse replica. A Partial Replica is both a Sparse and Fractional Replica. 4. Overview This section provides an overview of the LDAP Replication architecture. It is broken down into Directory Model, Information Model, Policy Information, Update Transfer Protocol, Replication Configuration and Management, Update Vector, and Time. The remainder of the document discusses each in detail. 4.1 Directory Model The basic directory model must be extended in a number of ways. a) The Replication Management entries require a sub-entry object class to effectively hide them from end-user clients. b) A form of timestamp, a Change Sequence Number (CSN), must be recorded with every change to every entry. The change may be the creation of a new entry, the modification of an existing entry, or the deletion of an existing entry. c) Server implementations may need to include a CSN purging feature to control Directory Information Base (DIB) storage space. 4.2 Information Model The Naming Context Auxiliary Class is added to container entries that may have separately defined replication policy. [LDUP Info] Immediately subordinate to a Naming Context entry are the Replica Subentry container entries that identify its LDAP Access Point, its Merrells, Reed, Srinivasan [Page 8] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 replica type (Primary, Updateable, Read-Only), if it is sparse, the LDAP search filter defining which entries it holds, and if it is fractional, the attributes it does or does not hold. Immediately subordinate in the namespace to a Replica Subentry are Replication Agreement leaf entries which each identify another Replica, the scheduling policy for replication operations, including times when replication is to be performed, when it is not to be performed, or the policies governing event-driven replication initiation. 4.3 Policy Information Administrative policy information needs to be consistently known and applied by all replicas of a Naming Context. As such, the Naming Context Auxiliary Class provides a convenient way to define attributes which can communicate those policies among all replicas and users of the directory. 4.4 Update Transfer Protocol A Replication Session occurs between a Supplier server and Consumer server over an LDAP connection. The session initiator, termed the Initiator, could be either the Supplier or Consumer. The Initiator sends an LDAP extended operation to the Responder identifying the replication agreement being acted on. The Supplier then sends a sequence of updates to the Consumer. If the replica contents can be changed in more than one place then updates may conflict. As the consumer applies changes it must detect and resolve these conflicts. Change Sequence Numbers on each entry and each change enable the consumer to maintain the correct total ordering of updates. All transfers are in one direction only. A two way exchange requires two replication sessions; one session in each direction. 4.5 Replication Configuration and Management The management entries described in the Information Model may be created, modified, and deleted by administrative clients to configure and manage the replication network. The administrative operations performed over LDAP are discussed further in section 9. Merrells, Reed, Srinivasan [Page 9] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 4.6 Update Vector Each Replica holds an Update Vector that records the most recent change it has received for each of the other Replicas of this Naming Context. The vector is used at the initiation of a replication session to determine the sequence of updates that should be transferred. 4.7 Time Because Change Sequence Numbers are primarily based on timestamps, clock differences between servers can cause unexpected change ordering. The synchronization of server clocks is not required, though it is preferable that clocks are accurate. If timestamps are not accurate, and a server consistently produces timestamps which are significantly older than those of other servers, its updates will not have effect and the real world time ordering of updates will not be maintained. However, an implementation may choose to require clock synchronisation. The Network Time Protocol [NTP] [SNTP] offers a protocol means by which heterogeneous server hosts may be time synchronised. 5. Directory Model The following sections describe changes to the basic directory model that are required by the replication architecture. 5.1 Replica Type Each Replica is characterized with a replica type. This may be Primary, Updatable, or Read-Only. The latter two types may be further defined as being Sparse, Fractional, or Partial. The Primary Replica is a full copy of the Replica, to which all applications that require strong consistency should direct their LDAP operations. There can be only one Primary Replica within the set of Replicas of a given Naming Context. It is also permissible for none of the Replicas to be designated the Primary. An Updatable Replica is a Replica that accepts all LDAP operations, but is not the Primary Replica. There could be none, one, or many Updatable Replicas within the set of Replicas of a given Naming Context. Merrells, Reed, Srinivasan [Page 10] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 A Read-Only Replica will accept only non-modifying LDAP operations. All modification operations will be referred to an updateable Replica, usually to its supplier. 5.2 Sub-Entries Replication management entries are to be stored at the base of the replicated naming context. They will be of a subentry objectclass to exclude them from regular searches. Entries with the objectclass subentry are not returned as the result of a search unless the filter component "(objectclass=subentry)" is included. 5.3 LDAP Change Sequence Numbers Every change, caused by an LDAP update operation, is assigned a sequence number. The Change Sequence Number (CSN) is formed of three components. In order of significance they are; the time, a replica id number, and a change count. The time component is a year-2000-safe representation of the real world time, with a granularity of one second. Should LDAP update operations occur at different replicas, to the same data, within the same single second, then the replica id is used to further order the changes. Because LDAP update operations at a single replica may also occur to the same data in a single second, the 'change count' component of the CSN is provided to definitely order the changes. Each replica maintains a count of changes made against it, which is reset to zero at the start of each second, and is monotonically increasing within the second, incremented for each LDAP update operation applied to the replica. The preferred time syntax is: yyyy mm dd hh:mi:ssz # replica id # 0xssss The "z" in the time stipulates that the time is expressed in GMT without any daylight savings time offsets permitted, and the 0xssss represents the hexidecimal representation of an unsigned integer. Implementations must support 16 bit change counts and should support longer ones (32, 64, 128). An example CSN would be " 1998081018:44:31z#1#0x000F " Merrells, Reed, Srinivasan [Page 11] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 5.4 State Storage and Representation All changes made to an entry, and its attributes, include the CSN assigned at the server where the change was first made. Each of the LDAP update operations Add, Modify, Modify RDN (LDAP v2), Modify DN (LDAP v3), and Delete change their target entry in different ways, and record the CSN of the change differently. This state information must be stored for each entry to enable Conflict Detection and Resolution. State information is recorded at three levels within each entry. At the entry level, attribute level, and attribute value level. Each is briefly described below. 5.4.1 Entry Change State Storage and Representation When an entry is created, with the LDAP Add operation, the CSN of the change is added to the entry as the value of an operational attribute named 'createdEntryCSN', of syntax type LDAPChangeSequenceNumber. createdEntryCSN ::= csn Deleted entries are marked as deleted by the addition of the object class 'deletedEntry'. The attribute 'deletedEntryCSN', of syntax type LDAP Change Sequence Number, is added to record where and when the entry was deleted. Deleted entries are not visible to LDAP clients - they may not be read, they don't appear in lists or search results, and they may not be changed once deleted. Names of deleted entries are available for reuse by new entries immediately after the deleted entry is so marked. It may be desirable to allow deleted entries to be accessed and manipulated by management and data recovery applications, but that is outside the scope of this document. deletedEntryCSN ::= csn 5.4.2 Attribute Change State Storage and Representation When all values of an attribute have been deleted, the attribute is marked as deleted and the CSN of the deletion is recorded. The deleted state and CSN are stored by the server, but have no representation on the entry, and may not be the subject of a search operation. This state information must be stored to enable Conflict Detection and Resolution to be performed. Merrells, Reed, Srinivasan [Page 12] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 5.4.3 Attribute Value Change State Storage and Representation The Modification CSN for each value is to be set by the server when it accepts a modification request to the value, or when a new value with a later Modification CSN is received via Replication. The modified value and the Modification CSN changes are required to be atomic, so that the value and its Modification CSN cannot be out of synch on a given server. The state information is stored by the server, but it has no representation on the entry, and may not be the subject of a search operation. When the value of an attribute is deleted the state of its deletion must recorded, with the CSN of the modifying change. It must be stored to enable Conflict Detection and Resolution to be performed. 5.5 LDAP Update Operations The server must reject LDAP client update operations with a CSN that is older than the state information that would be replaced if the operation were performed. This could occur in a replication topology where the difference between the clocks of updateable replicas was too large. Result code 72, serverClocksOutOfSync, is returned to the client. 5.6 Purging State Information The state information stored with each entry need not be stored indefinitely. A server implementation may choose to periodically, or continuously, remove state information that is no longer required. The mechanism is implementation-dependent, but to ensure interoperability between implementations, the state information must not be purged until all known replicas have received and acknowledged the change associated with a CSN. This can be determined by constructing an Update Vector containing the lowest CSN for each replica from all the known replicas. All the CSNs stored that are lower than this Update Vector may be purged, because no changes with older CSNs will be replicated to this replica. 5.6.1 Purging Deleted Entries, Attributes, and Attribute Values The following conditions must hold before an item can be deleted from the Directory Information Base. 1) The LDAP delete operation has been propagated to all replication agreement partners. Merrells, Reed, Srinivasan [Page 13] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 2) All the updates from all the other replicas with timestamps less than the timestamp on the deletion have been propagated to the server holding the deleted object (similarly for deleted attributes and attribute values). 3) The clocks of the other Replicas must have advanced beyond the deletion CSN of the deleted entry. Otherwise, it is possible for one of those Replicas to generate operations with CSNs earlier than the deleted object. 5.7 Replication Schedule There are two broad mechanisms for initiating replication sessions: (1) scheduled event driven and (2) change event driven. The mechanism is used to schedule replication operations between two servers is determined by the Schedule information that is part of the Replication Agreement governing the Replicas on those two servers. Because each Replication Agreement describes the policy for one direction of the relationship, it is possible that events propagate via scheduled events in one direction, and by change events in the other. Change event driven replication sessions are, by their nature, initiated by suppliers of change information. The server, which the change is made against, schedules a replication session in response to the change itself, so that notification of the change is passed on to other Replicas. Scheduled event driven replication sessions can be initiated by either consumers or suppliers of change information. The schedule defines a calendar of time periods during which Replication Sessions should be initiated. Schedule information may include both scheduled and change event driven mechanisms. For instance, one such policy may be to begin replication within 15 seconds of any change event, or every 30 minutes if no change events are received. 6. Information Model This section describes the object classes of the entries that represent the replication topology. The where, when and how of Naming Context replication is administered through these entries. The LDUP Working Group will publish an Internet Draft to fully detail all these schema elements. [LDUP Info] Merrells, Reed, Srinivasan [Page 14] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 6.1 Entries, Semantics & Relationships 6.1.1 Root DSE Attributes The Root DSE attribute 'replicaRoot', publishes the names of the Replicas that are held on that server. Each value of the attribute is the Distinguished Name of the root entry of the Replicated Area. 6.1.2 Naming Context Auxiliary Object Class and Entries Each Naming Context contains attributes which hold common configuration and policy information for all replicas of the Naming Context. A Naming Context Creation attribute records when and where the Naming Context was created. The Access Control Policy OID attribute defines the syntax and semantics of Access Control Information for entries within the Naming Context. The Naming Context is based at the entry given the auxiliary class, and continues down the tree until another Naming Context is encountered. 6.1.3 Replica Object Class and Entries Each Replica is characterized by a replica type. This may be Primary, Updatable, or Read-Only. The latter two types may be further defined as being Sparse, Fractional, or Partial. The Replica entry will include an Entry Filter for a Sparse Replica, a Fractional Entry Specification for a Fractional Replica, and both for a Partial Replica There is a need to represent network addresses of servers holding replicas and participating in Replication Agreements. The X.501 Access Point syntax is not sufficient, in that it is tied specifically to OSI transports. Therefore, a new syntax will be defined for LDAP which serves the same purpose, but uses IETF-style address information. [LDUP Info] An Update Vector (described below) describes the point to which the Replica has been updated, in respect to all the other Replicas of the Naming Context. Merrells, Reed, Srinivasan [Page 15] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 The intent is to enable distributed operations in LDAP with the replica information stored there, but not to complete the process of turning LDAP into a fully distributed service. 6.1.4 Replication Agreement Object Class and Entries The Replication Agreement defines: - The schedule for Replication Sessions initiation. - Which server initiates the Replication Session. Either Consumer, or Supplier. - The authentication credentials that will be presented between servers. - The network/transport security scheme that will be employed in order to ensure data confidentiality. - The replication protocols and relevant protocol parameters to be used for Full and Incremental updates. An OID is used to identify the update transfer protocol, thus allowing for future extensions or bilaterally agreed upon alternatives. Permission to participate in replication sessions will be controlled, at least in part, by the presence and content of replica agreements. 6.1.5 Update Vector Each Replica entry includes an Update Vector to record the point to which the replica has been updated. The vector is a set of CSN values, one value for each known updateable Replica. Each CSN is the most recent change, made at that Replica, that has been replicated to this Replica. It may be the case that a CSN for a given replica is absent, for one of two reasons. - CSNs for Read-Only replicas might be absent because no changes will have ever been applied to that Replica, so there are no changes to replicate. - CSNs for newly created replicas may be absent because no changes to that replica have yet been propagated. An Update Vector might contain a CSN for a replica that no longer exists. The replica may have been temporarily taken out of service, or may have been removed from the replication topology permanently. An Merrells, Reed, Srinivasan [Page 16] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 implementation may choose to retire a CSN after some configurable time period. Since the Update Vector records the state to which the replica has been updated, a supplier server, during Replication Session initiation, can determine the sequence of updates that should be sent to the consumer. The Update Vector embodies knowledge of updates made at all known replicas ensuring that changes are not transferred to a consumer multiple times. This would otherwise occur in the case where redundant replication agreements existed. Unnecessary transfers are eliminated because each replica maintains the highest CSN it has seen for all other replicas, not just the supplier replica. 6.2 Unique Identifiers Distinguished names can change, so are therefore unreliable as identifiers. A Unique Identifier must therefore be assigned to each entry as it is created. This identifier will be stored as an operational attribute of the entry. The unique identifier could be generated by a number of algorithms, so we propose that the first octet be a prefix to identify its type. The prefix zero is reserved to signify the UUID (Universally Unique IDentifier) format, also known as GUID (Globally Unique IDentifier) [UUID]. Support for alternative algorithms is provided so that future better unique identifier generation algorithms may be easily adopted. Implementations may also wish to impose some structure to their unique identifiers to ease implementation of Conflict Detection & Resolution. 7. Policy Information Policy information governs the behavior of the server. It may be represented in the DIT as sub-entries, attributes, and attribute values. When replicating a naming context that is itself a subtree of another naming context, there may be policy information stored in its antecedent entries. The most common examples are prescriptive access control information and inherited schema definition. Implementations may also define other policy attributes, or sub-entries, that apply to a whole subtree. For a naming context to be faithfully reproduced, this generational information must also be replicated. In all cases Merrells, Reed, Srinivasan [Page 17] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 the policy information is transmitted as if it were an element of the Replica root entry. Policy information is always replicated in the same manner as any other entries, attributes, and attribute values. 7.1 Access Control The Access Control Models supported by a server are identified by the 'accessControlScheme' multi-valued attribute of the Root DSE entry. Each model is assigned an OID so that Consumers and Suppliers can determine if their access control policy will be faithfully imposed when replicated. An access control policy must be consistently applied by all servers holding replicas of the same Naming Context. Therefore, the Access Control Policy attribute is to be an operational attribute of the Naming Context Auxiliary Class. Thus, any consumer of the directory, and any server which would replicate a Naming Context, will know that an Access Control Policy is defined for the Naming Context, and by reference to the OID value of this attribute, know what policy mechanism to invoke to enforce that policy. Administrators are strongly cautioned against placing replicas of naming contexts on servers that cannot enforce the policy required by the Access Control Policy OID. Servers should refuse to accept replicas with policies they are unable to properly interpret. 7.2 Schema Knowledge Schema subentries should be subordinate to the naming contexts to which they apply. Given our model, a single server may hold replicas of several naming contexts. It is therefore essential that schema should not be considered to be a server-wide policy, but rather to be scoped by the namespace to which it applies. Schema modifications replicate in the same manner as other directory data. Given the strict ordering of replication events, schema modifications will naturally be replicated prior to entry creations which use them, and subsequent to data deletions which eliminate references to schema elements to be deleted. servers may not replicate information about entries which are not defined in the schema. Servers SHOULD NOT replicate modifications to existing schema definitions for which there are existing entries and/or attributes which rely on the schema element. Merrells, Reed, Srinivasan [Page 18] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 Should a schema change cause an entry to be in violation of the new schema, it is recommended that the server preserve the entry for administrative repair. The server could add a known object class to make the entry valid and to mark the entry for maintenance. 8. Update Transfer Protocol This section describes the process by which a Replication Session is established, how updates are transferred, and how a session is terminated. Subject to Replication Agreements, either the supplier or the consumer server can initiate the replication session. This document only defines a transfer protocol for the supplier to push changes to the consumer. Other protocols could be defined to transfer changes, including those which pull changes from the supplier to the consumer, but those are left for future work. 8.1 Session Initiation The Initiator starts the Replication Session by opening an LDAP connection to its Responder. The Initiator binds using the authentication credentials provided in the Replication Agreement. The extended LDAP operation Start Replication is then sent by the Initiator to the Responder. This operation identifies which role each server will perform, and what type of replication is to be performed. One server is to be the Consumer, the other the Supplier, and the replication may be either Full or Incremental. If the Responder does not support the requested type of replication then an error is returned. 8.1.1 Authentication The initiation of a Replication Session is to be restricted to only permitted clients. The identity and credentials of a connected server are determined via the bind operation. Access control on the Replication Agreement determines if the Replication Session may proceed. Otherwise, the insufficientAccessRights error is returned. 8.1.2 Consumer Initiated The Consumer binds to the Supplier using the authentication credentials provided in the Replication Agreement. The Consumer sends the Start Replication extended request to begin the Replication Merrells, Reed, Srinivasan [Page 19] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 Session. The Supplier returns a Start Replication extended response containing a response code. The Consumer then disconnects from the Supplier. If the Supplier has agreed to the replication session initiation, it binds to the Consumer and behaves just as if the Supplier initiated the replication. 8.1.3 Supplier Initiated The Supplier binds to the Consumer using the authentication credentials provided in the Replication Agreement. The Supplier sends the Start Replication Request extended request to begin the Replication Session. The Consumer returns a Start Replication extended response containing a response code, and optionally its Update Vector. If the Consumer has agreed to the Replication Session initiation, then the transfer protocol begins. The Supplier uses the Consumer's Update Vector to determine the sequence of changes that should be sent to the Consumer. 8.1.4 Start Replication Request A client may request this operation by transmitting an LDAP PDU containing an LDAP ExtendedRequest, defined as follows. [LDAPv3] ExtendedRequest ::= [APPLICATION 23] SEQUENCE { requestName [0] LDAPOID, requestValue [1] OCTET STRING } The requestName field must be set to the string "2.16.840.1.113730.3.5.3". The requestValue field will contain as a value the DER-encoding of the following ASN.1 data type: SEQUENCE { namingContextDN LDAPDN, replicaID INTEGER (1..2^^16-1), protocolOID LDAPOID } The parameters of the Start Replication Request are: - The Distinguished Name of the entry at the root of the Naming Context. - The Replica Identifier of the Initiator. Merrells, Reed, Srinivasan [Page 20] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 - The OID identifying the Update Transfer Protocol to be used. From the DN and Replica ID the Responder can determine which Replication Agreement is being acted on. The Protocol OID identifies the Update Transfer Protocol that the Initiator wishes to use, this indicates whether the it is to be a Full or Incremental update. 8.1.5 Start Replication Response If a server implements this extension, then when the request is made it will return an LDAP PDU containing an ExtendedResponse, defined as follows. [LDAPv3] ExtendedResponse ::= [APPLICATION 24] SEQUENCE { COMPONENTS OF LDAPResult, responseName [10] LDAPOID OPTIONAL, responseValue [11] OCTET STRING OPTIONAL } The responseName field must be set to the string "2.16.840.1.113730.3.5.4". The responseValue field, when present, will contain as a value the DER-encoding of the following ASN.1 data type: SEQUENCE { startReplicationResult [0] startReplicationStatus, updateVector [1] SET OF OCTET STRING OPTIONAL, } startReplicationStatus ::= ENUMERATED { success (0), -- operation succeeded operationsError (1), -- server internal failure protocolError (2), -- protocol error insufficientAccessRights (50), -- refused to carry out operation busy (51), -- already being updated other (80) } The startReplicationResult field indicates any error condition encountered in the processing of the operation. In Supplier Initiated Replication the Consumer Responder responds with its Update Vector. 8.2 Update Transfer Each Update Transfer Protocol is identified by an OID. A conformant server implementation must support the two update protocols defined here, and may support many others. A server will advertise its Merrells, Reed, Srinivasan [Page 21] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 protocols in the Root DSE multi-valued attribute 'supportedReplicationProtocols'. The two mandatory to implement protocols will be defined by the LDUP Working Group in another Internet Draft. One is to provide a Full Update for initialisation and re-initialisation of a replica, the other is to maintain that replica via an Incremental Update. Each entry to be transferred is passed through the Entry Filter and Fractional Entry Specification. Necessary extended operations will be defined to support efficient transfer of change information from supplier to consumer servers. 8.2.1 Full Update Transfer This Full Update Protocol will provide a bulk transfer of the replica contents for the initial population of new replicas, and the refreshing of existing replicas. Upon receiving a full update request the Consumer must replace any existing information in its replica with that sent from the Supplier. The Consumer need not service any requests for this Naming Context whilst the full update is in progress. The Consumer could return a referral to another replica, possibly the supplier. [REF] 8.2.2 Incremental Update Transfer For efficiency the Incremental Update Protocol transmits only those changes that have been made to the Naming Context since updates were last transmitted, that the Consumer has not already received. In a replication topology with transitive redundant replication agreements, changes may propagate through the replica network via different routes. The Supplier uses the Consumer's Update Vector to determine the sequence of updates that should be sent to the Consumer. As the transmission of updates proceeds the Consumer may return the last CSN received as a form of committed acknowledgement. This provides an implicit restart value for the Supplier, should the connection be interrupted. Each individual change may contain a sequence of entry modifications that must be preserved when transferred. The atomicity of the LDAP operation must be preserved when it is applied to the Consumer Replica. Merrells, Reed, Srinivasan [Page 22] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 Changes must be transmitted in ascending change sequence number. Each change transmitted includes the unique identifier of the subject entry and the CSN of the originating operation. This allows the Consumer to keep track of which changes it has received. The Consumer must not support multiple concurrent replication sessions with many Suppliers for the same Naming Context. A Supplier that attempts to initiate a Replication Session with a Consumer already participating as a Consumer in another Replication Session will receive the busy error code. 8.2.2.1 Conflict Detection and Resolution A consequence of permitting multiple updateable replicas within a replication topology is that conflicting update changes may occur. A Consumer will receive replication changes from its various agreement partners. Those changes must be reconciled with the current replica contents and any previously received changes. In broad outline, received replication changes are compared to the state information associated with the item being operated on. If the change has a more recent CSN, then it is applied to the directory contents. If the replica has replication agreements where it acts as a supplier then the change is retained for forwarding at the appropriate time. If the change has an older CSN it is no longer relevant and is simply discarded. Naming collisions may occur when updates are received by a server for a given named entry whose Unique Identifier is different from that of an already existing entry with the same distinguished name. This may occur because events from various replicas cannot be guaranteed to arrive in sequence, or because of conflicting data changes being entered at two or more different replicas. Consider the following scenario: The entry named "A" has a Unique Identifier of "3", and it exists on each of three replicas, X, Y, and Z. At replica X, entry "A" is deleted, and then another entry "A" is created with the same name, but with the Unique Identifier of "4". If at replica Y a modification to entry "A" is entered before the deletion and creation events from X are received, Y will attempt to replicate the modification to "A" to X. When received, X will note that the Unique Identifier of the entry "A" which is being modified is "3". Because the entry "A" with Unique Identifier "3" is marked as "deleted" on X, server X will simply ignore the modification, since it applies to a deleted object, and not Merrells, Reed, Srinivasan [Page 23] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 to the entry currently defined with name "A", whose Unique Identifier is "4". Thus, the confusion over which entry was modified is resolved. This briefly describes the types of change collisions that can occur. The LDUP Working Group will publish an Internet Draft fully defining the Conflict Detection and Resolution mechanism. 8.3 End Replication Session A Replication Session is terminated by the Supplier by sending an End Replication LDAP extended request, see section 8.3.3. The purpose of the request and response operations is to carry the Update Vector from the Supplier to the Consumer in the Full Update case, and to convey the Update Vector from the Consumer to the Supplier in the Incremental Update case. 8.3.1 Full Update End Replication Session After a Full Update transfer the Supplier sends the Update Vector that reflects the update state of the full replica information sent. The Consumer records this as its Update Vector. The Supplier could be accepting updates whilst the update is in progress. Once the Full Update has completed, an Incremental Update should be performed to transfer these changes. 8.3.2 Incremental Update End Replication Session After an Incremental Update transfer has completed the Supplier must send its Update Vector to the Consumer. If the Supplier sent none of its own updates to the Consumer, then its CSN within its Update Vector should be updated with the earliest possible CSN that it could generate, to allow for deletion state information to be purged in a timely manner. The Consumer records the received Update Vector in the replica entry it holds for the Supplier Replica. The Consumer then returns its resultant Update Vector to the Supplier so that it too can update its replica entry for the Consumer Replica. The Consumer's Update Vector CSN values will be at least as great as the Supplier's Update Vector. Merrells, Reed, Srinivasan [Page 24] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 8.3.3 End Replication Request A client may request this operation by transmitting an LDAP PDU containing an LDAP ExtendedRequest, defined as follows. [LDAPv3] ExtendedRequest ::= [APPLICATION 23] SEQUENCE { requestName [0] LDAPOID, requestValue [1] OCTET STRING } The requestName field must be set to the string "2.16.840.1.113730.3.5.5". The requestValue field will contain as a value the DER-encoding of the following ASN.1 data type: SEQUENCE { updateVector SET OF OCTET STRING } When the update has completed the Supplier sends this extended request to inform the Consumer that all updates have been sent, and to advise the Consumer of its own Update Vector. 8.3.4 End Replication Response If a server implements this extension, then when the request is made it will return an LDAP PDU containing an ExtendedResponse, defined as follows. [LDAPv3] ExtendedResponse ::= [APPLICATION 24] SEQUENCE { COMPONENTS OF LDAPResult, responseName [10] LDAPOID OPTIONAL, responseValue [11] OCTET STRING OPTIONAL } The responseName field must be set to the string "2.16.840.1.113730.3.5.6". The responseValue field, when present, will contain as a value the DER-encoding of the following ASN.1 data type: SEQUENCE { endReplicationResult [0] endReplicationStatus, updateVector [1] SET OF OCTET STRING OPTIONAL, } startReplicationStatus ::= ENUMERATED { success (0), -- operation succeeded Merrells, Reed, Srinivasan [Page 25] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 operationsError (1), -- server internal failure protocolError (2), -- protocol error other (80) } The endReplicationResult field indicates any error condition encountered in the processing of the operation. The Consumer returns its Update Vector to the Supplier. 8.4 Integrity & Confidentiality Data integrity (i.e. protection from unintended changes) and confidentiality (i.e. protection from unintended disclosure to eavesdroppers) SHOULD be provided by appropriate selection of underlying transports, for instance TLS, or IPSEC. Replication MUST be supported across TLS LDAP connections. Servers MAY be configured to refuse replication connections over unprotected TCP connections. 9. Replication Configuration and Management Replication management entries, such as replica or replication agreement entries, can be altered on any updateable replica. These entries are implicitly included in the directory entries governed by any agreement associated with this naming context. As a result, all servers with a replica of a naming context will have access to information about all other replicas and associated agreements. The deployment and maintenance of a replicated directory network involves the creation and management of all the replicas of a naming context and replication agreements among these replicas. This section outlines, through an example, the administrative actions necessary to create a new replica and establish replication agreements. Typically, administrative tools will guide the administrator and facilitate these actions. The objective of this example is to illustrate the architectural relationship among various replication related operational information. A copy of an agreement should exist on both the supplier and consumer side for the replication update transfer protocol to be able to start. For this purpose, the root of the naming context, replica objects and the replication agreement objects are created first on one of the servers. A copy of these objects are then manually created on the second server associated with the agreement. Merrells, Reed, Srinivasan [Page 26] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 The scenario below starts with a server (named DSA1) that holds an updateable replica of a naming context NC1. Procedures to establish an updateable replica of the naming context on a second server (DSA2) are outlined. On DSA1: 1) Add the context prefix for NC1 to the Root DSE attribute 'replicaRoot'. If it does not already exist. 2) Alter the 'ObjectClass' attribute of the root entry of NC1 to include the "namingContext" auxiliary class. 3) Create a replica object, NC1R1, (as a child of the root of NC1) to represent the replica on DSA1. The attributes include replica type (updateable, read-only etc.) and DSA1 access point information. 4) Create a copy of the replica object NC1R2 (after it is created on DSA2) 5) Create a replication agreement, NC1R1-R2 to represent update transfer from NC1R1 to NC1R2. This object is a child of NC1R1. On DSA2: 1) Add NC1's context prefix to the Root DSE attribute 'replicaRoot'. 2) Create a copy of the root entry of NC1 as a copy of the one in DSA1 (including the namingContext auxiliary class) 3) Create a copy of the replica object NC1R1 4) Create a the second replica object, NC1R2 (as a sibling of NC1R1) to represent the replica on DSA2. 5) Create a copy the replication agreement, NC1R1-R2 6) Create a replication agreement, NC1R2-R1, to represent update transfer from NC1R2 to NC1R1. This object is a sibling of NC1R1- R2. After these actions update transfer to satisfy either of the two agreements can commence. If data already existed in one of the replicas, the update transfer protocol should perform a complete update of the data associated with the agreement before normal replication begins. Merrells, Reed, Srinivasan [Page 27] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 10. Time The server assigns CSN for every LDAP update operation it receives. Since the CSN is principally based on time, the CSN is susceptible to the Replica clocks drifting in relation to each other (either forwards or backwards). The server must never assign a CSN older than or equal to the last CSN it assigned. The server must reject update operations, from any source, which would result in setting a CSN on an entry or a value which is earlier than the one that is there. The error code serverClocksOutOfSync (72) should be returned. 11. Security Considerations The preceding architecture discussion covers the server authentication, session confidentiality, and session integrity in sections 8.1.1, 17.7, and 8.4 The internet draft "Authentication Methods" for LDAP, provides a detailed LDAP security discussion. Its introductory passage is paraphrased below. [AUTH] A Replication Session can be protected with the following security mechanisms. 1) Authentication by means of the SASL mechanism set, possibly backed by the TLS credentials exchange mechanism, 2) Authorization by means of access control based on the Initiators authenticated identity, 3) Data integrity protection by means of the TLS protocol or data- integrity SASL mechanisms, 4) Protection against snooping by means of the TLS protocol or data- encrypting SASL mechanisms, 12. Acknowledgements This document is a product of the LDUP Working Group of the IETF. The contributions of its members is greatly appreciated. Merrells, Reed, Srinivasan [Page 28] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 13. References [AUTH] - M. Wahl, H. Alvestrand, J. Hodges, RL "Bob" Morgan, "Authentication Methods for LDAP", Internet Draft, draft-ietf-ldapext- authmeth-02.txt, July 1998. [BCP-11] - R. Hovey, S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. [LDAPv3] - M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access Protocol (v3)", RFC 2251, December1997. [LDUP Requirements] - R. Weiser, E. Stokes “LDAP Replication Requirements”, Internet Draft, draft-weiser-replica-req-02.txt, April 1998. [LDUP Info.] - E. Reed, "LDUP Replication Information Model", Internet Draft, draft-reed-ldup-infomod-00-1.txt, August 1998. [NTP] - D. L. Mills, "Network Time Protocol (Version 3)", RFC 1305, March, 1992. [REF] - T. Howes, Mark Wahl, "Referrals and Knowledge References in LDAP Directories", Internet draft, draft-ietf-ldapext-referral-00.txt, March 1998. [RFC2119] - S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119. [RFC2252] - M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997. [SNTP] - D. L. Mills, "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030, University of Delaware, October 1996. [TLS] - J. Hodges, R. L. "Bob" Morgan, M. Wahl, "Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security", Internet draft, draft-ietf-ldapext-ldapv3-tls-01.txt, July 1998. [UUID] - P. Leach, R. Salz, "UUIDs and GUIDs", Internet draft, draft- leach-uuids-guids-01.txt, February 1998. [X501] - ITU-T Recommendation X.501 (1993), ) | ISO/IEC 9594-2:1993, Information Technology - Open Systems Interconnection - The Directory: Models Merrells, Reed, Srinivasan [Page 29] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 [X680] - ITU-T Recommendation X.680 (1994) | ISO/IEC 8824-1:1995, Information technology - Abstract Syntax Notation One (ASN.1): Specification of Basic Notation" [X525] ITU-T Recommendation X.525 (1997) | ISO/IEC 9594-9:1997, Information Technology - Open Systems Interconnection - The Directory: Replication 14. Intellectual Property Notice The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. [BCP-11] Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 15. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for Merrells, Reed, Srinivasan [Page 30] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 16. Authors' Address John Merrells Netscape Communications, Inc. 501 East Middlefield Road Mountain View CA 94043 E-mail: merrells@netscape.com Phone: +1 650-937-5739 Edwards E. Reed Novell, Inc. 122 E 1700 S Provo, UT 84606 E-mail: ed_reed@novell.com Phone: +1 801-861-3320 Fax: +1 801-861-2220 Uppili Srinivasan Oracle, Inc. Redwood Shores E-mail: usriniva@us.oracle.com Phone: +1 650 506 3039 LDUP Engineering Mailing List: ldup-repl@external.cisco.com Merrells, Reed, Srinivasan [Page 31] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 17. Appendix A - Open Issues 17.1 Replication Session Initiation Insisting that an agreement is always consumer initiated or always supplier initiated is rather inflexible. There are times when a read- only replica will want to initiate an immediate total refresh on an agreement that is ordinarily supplier initiated. With the above restriction a read-only replica will just have to wait until a supplier contacts it. It might be preferable that the identity of the initiator be associated with the schedule components, rather than with the whole replication agrement. 17.2 Lost and Found Container The replication architecture proposal submitted by Steven Legg of Teltra includes the concept of every entry being assigned a lost and found superior. If the entry becomes orphaned from its parent, due to some naming collision, then the lost and found container adopts that entry. This well known place would allow administrators and their tools to find and repair abandoned entries. 17.3 Write Conflicts Servers could be administratively configured to ignore updates with ridiculous times, and may choose their own definitions for what times are considered ridiculous. Servers that do so must declare their definition of ridiculous in the Root DSE or the Naming Context entry of the Replica. 17.4 Management and Configuration Topics that need coverage. - Creation, Destruction, and Modification of Naming Contexts, Replicas, and Replication Agreements. - Promotion and Demotion of Replicas from Read-Only to Updateable to Primary. - Patching up of partitioned replication networks. Merrells, Reed, Srinivasan [Page 32] Expires 5 February 1999 INTERNET-DRAFT LDAP Replication Architecture August 1, 1998 - Discuss redundant replication agreements. - Triggering a Full Update for a Replication Agreement. 17.5 Sparse, Fractional, and Partial Replicas The scope and expressiveness of the Entry Filter and Fractional Attribute Specification need to be defined. One of the replication requirements is that not all replicas hold all the entries or all their attributes. There are some consequences. - Both Replica and Replication Agreements could specify the Partial- ness of a Replica. - What should the server behaviour be when an LDAP update operations is applied to Partial Replica that does not hold the data to be modified. - How is schema enforced on a Fractional Replica. 17.6 Update Transfer: Errors, Recovery, Diagnostics and Repair How should the protocol react to connection loss. Should the Replication Agreement protocol parameters define the acknowledgement frequency. Should keep-alive and progress feedback be provided for long operations. For instance replica preparation during Full Update for reinitialisation. 17.7 Update Access Control The Supplier must be subject to the access control policy enforced by the Consumer. Since the access control policy information is stored and replicated as directory content, the access control imposed on the Supplier by the Consumer must be stored in the Consumer's Replication Agreement. Merrells, Reed, Srinivasan [Page 33] Expires 5 February 1999