Individual Submission to ldup working group R. Harrison Internet Draft J. Sermersheim Document: draft-rharrison-lburp-03.txt Y. Dong Category: Standards Track Novell, Inc. March, 2001 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 LDAP Bulk Update/Replication Protocol (LBURP) 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. The protocol frames a sequenced set of update operations within a pair of LDAPv3 extended operation to notify the client that the update operations in the framed set are related. The update operations within the framed set are LDAPv3 extended operations each encapsulating a sequence number and one or more LDAPv3 update operations. The sequence number allows the server to process the update operations in the proper order even when they are sent asynchronously by the client, and the update operations can be grouped within the extended request to maximize the efficiency of client-server communication. The protocol may be used to initialize all of the entries in an LDAP replica or to incrementally update 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 Individual Submission - Expires September 2, 2001 Harrison, Sermersheim & Dong 1 LDAP Bulk Update/Replication Protocol March, 2001 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]. The term supplier applies to an LDAP client or an LDAP server (acting as a client) that supplies a set of update operations to a consumer. The term consumer applies to an LDAP server that consumes (i.e. processes) the sequenced set of update operations sent to it by a supplier. 3. Motivation for protocol 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. LBURP introduces a minimum of new operational functionality to the LDAP protocol since the update requests sent by the client encapsulate standard LDAP [LDAPv3] update operations. However, this protocol greatly facilitates bulk updates by allowing the supplier to present the update operations asynchronously and still allow the consumer to maintain proper ordering of the operations. It also allows the consumer to recognize the supplier's 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 consumer that the LDAP operations framed within it can be treated in a special way because they are related to each other. The consumer 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 into a single transaction rather than applying them to the DIT individually. 4. Overview of protocol LBURP frames a set of update operations within a pair of LDAPv3 extended operations that mark the beginning and end of the update set. The update operations are sent via LDAPv3 extended operations, each containing a sequence number and a list of one or more update operations to be performed by the consumer. Except for the fact that they are grouped together as part of a larger LDAPv3 extended request, the update operations in each subset are normal LDAPv3 update operations and use the ASN.1 format specified in [LDAPv3]. 4.1. Update Initiation The protocol is initiated when a supplier sends a StartLBURPRequest extended operation to a consumer to notify it that the following Individual Submission - Expires September 2, 2001 Harrison, Sermersheim & Dong 2 LDAP Bulk Update/Replication Protocol March, 2001 LDAP update operations are to be treated as a stream of update information. The supplier includes the OID of the bulk update/replication protocol in the StartLBURPRequest to tell the consumer that the stream of operations contained within the framing are LBURP operations. The consumer responds to the StartLBURPRequest with a StartLBURPResponse. 4.2. Update Stream After the consumer responds with a StartLBURPResponse, the supplier sends a stream of LBURPOperation extended operations to the consumer. This stream MAY be sent asynchronously to maximize the efficiency of the transfer. The consumer responds to each LBURPOperation request with an LBURPOperationDone response. 4.2.1 LBURPOperation Request Each LBURPOperation request contains a sequence number identifying its relative position within the update stream and an UpdateOperationList containing an ordered list of LDAPv3 update operations to be applied to the DIT. The sequence number enables the consumer to process LBURPOperation requests in the order they were sent by the supplier even when they are sent asynchronously. The consumer processes each LBURPOperation according to sequence number by applying the LDAPv3 update operations in its UpdateOperationList to the DIT in the order they are listed. 4.2.2 LBURPOperationDone Response When the consumer has processed the update operations from the UpdateOperationList, the consumer sends an LBURPOperationDone response to the supplier indicating the success or failure of the update operations contained within the corresponding LBURPOperation request. 4.3. Update Termination When the supplier has sent all of the LBURPOperation requests it needs to send, it sends an EndLBURPRequest extended operation to the consumer to terminate the update stream. The consumer responds with an EndLBURPResponse, and the update is complete. 4.4. Update Styles Two styles of update--full and incremental--are defined. Full update creates a completely new set of entries in the target partition. Any existing entries in that partition when the StartLBURPRequest is received are removed before the LBURPOperation requests in the update stream are processed. The only update Individual Submission - Expires September 2, 2001 Harrison, Sermersheim & Dong 3 LDAP Bulk Update/Replication Protocol March, 2001 operation allowed in a full update stream is the add operation as defined in [LDAPv3]. Incremental update performs a series of incremental changes to the partition. Any existing entries in the partition are only affected if explicitly modified in some way by the update operations contained in the update stream. All of the update operations--add, modify, delete, and moddn--defined in [LDAPv3] are allowed in the incremental update stream. All of the semantics of the LDAPv3 operations are in effect, so for instance, an attempt to add an entry that already exists will fail just as it would during a normal LDAPv3 add operation. 4.5. Applicability of Protocol LBURP is designed to facilitate the bulk update of partitions on LDAPv3 servers. It can also be used to synchronize directory information between a single master replica and multiple slaves containing replicas of the same partition. No attempt is made to deal with the issues associated with multiple- master replication environments (such as keeping modification times of attribute values) so that updates to the same entry on different replicas can be correctly ordered. For this reason, when LBURP is used for replication, proper convergence of the data between all replicas can only be assured in a single-master replication environment. 5. Description of Protocol Flow This section describes the LBURP protocol flow and the information contained in each protocol message. 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. S -> C: LDAP bind operation (the identity and credentials required are implementation-defined) C -> S: Bind response S -> C: StartLBURPRequest LDAPv3 extended operation. The parameters are: 1) OID of LBURP incremental or full update protocol as defined in this document. Individual Submission - Expires September 2, 2001 Harrison, Sermersheim & Dong 4 LDAP Bulk Update/Replication Protocol March, 2001 C -> S: StartLBURPResponse LDAPv3 extended operation. The parameters are: 1) A suggested transactionSize (see section 6.2.1) S -> C: The supplier will send an update stream consisting of zero or more LBURPOperation LDAPv3 extended operations. The requests MAY be sent asynchronously. The parameters are: 1) A sequence number which specifies the order of this LBURPOperation request with respect to the other LBURPOperation requests in the update stream. 2) The UpdateOperationList, a list of one or more LDAPv3 update operations that are to be processed in the order they are listed. The consumer processes the LBURPOperation requests in the order of their sequence numbers and applies the LDAPv3 update operations contained within each LBURPOperation to the DIT in the order they are listed. C -> S: When the consumer completes processing the update operations from the UpdateOperationList it sends an LBURPOperationDone response. If the consumer was able to successfully complete all update operations in the request, the consumer sends an LBURPOperationDone response to the supplier with a result code of success (0) indicating that the entire set of pending update operations for the LBURPOperation succeeded. If the consumer could not successfully decode any part of the LBURPOperation request, it sends a result code of protocolError (2) to the supplier. If one or more of the newly-completed update operations failed, the consumer sends an LBURPOperationDone message with a result code of other (80) and includes an LDAPResult element for each of the failed update operations indicating the reason for failure. S -> C: After the supplier sends all of its LBURPOperation messages to the consumer, the supplier sends an EndLBURPRequest message to the consumer. The parameters are: Individual Submission - Expires September 2, 2001 Harrison, Sermersheim & Dong 5 LDAP Bulk Update/Replication Protocol March, 2001 1) A sequence number which is one greater than the sequence number of the last operation in the update stream. C -> S: The consumer responds by sending an EndLBURPResponse message. S -> C: The supplier sends an unbind operation to the consumer to close the connection. 6. Elements of Protocol LBURP uses two extended operation requests--StartLBURPRequest and EndLBURPRequest--to initiate and terminate the protocol. An extended operation request--LBURPOperation--is used to send update operations from the supplier to the consumer. An extended response, LBURPOperationDone is signals that an LBURPOperation is completed. 6.1. StartLBURPRequest Extended Operation The StartLBURPRequest extended operation is defined in terms of the [LDAPv3] ExtendedRequest as follows: ExtendedRequest ::= [APPLICATION 23] SEQUENCE { requestName [0] LDAPOID, requestValue [1] OCTET STRING OPTIONAL } The requestName portion of the StartLBURPRequest MUST be the OID "2.16.840.1.113719.1.142.100.1". The requestValue of the StartFramedProtocolRequest MUST be set to the BER-encoding of the following: StartLBURPRequestValue ::= SEQUENCE { lburpProtocolOID LDAPOID } 6.1.1. lburpProtocolOID The lburpProtocolOID is an OID that uniquely identifies the LBURP protocol framed by this operation. The lburpProtocolOID for the LBURP Incremental Update Protocol is 2.16.840.1.113719.1.142.1.4.1. The lburpProtocolOID for the LBURP Full Update Protocol is 2.16.840.1.113719.1.142.1.4.2. 6.2. StartFramedProtocolResponse Individual Submission - Expires September 2, 2001 Harrison, Sermersheim & Dong 6 LDAP Bulk Update/Replication Protocol March, 2001 The StartLBURPResponse is defined in terms of the [LDAPv3] ExtendedResponse as follows: ExtendedResponse ::= [APPLICATION 24] SEQUENCE { COMPONENTS of LDAPResult, responseName [10] LDAPOID OPTIONAL, response [11] OCTET STRING OPTIONAL } The responseName of the StartLBURPResponse must be the OID "2.16.840.1.113719.1.142.100.2". For LBURP, if the response element is included as part of a StartLBURPResponse, it must be set to the BER-encoding of the following: LBURPStartFramedProtocolResponse ::= maxOperations maxOperations ::= INTEGER (0 .. maxInt) maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- 6.2.1 maxOperations The value of maxOperations is a hint sent by the consumer to tell the supplier the number of update operations per UpdateOperationList (see section 6.3.2) that it would like the supplier to send. The maxOperations element is optional. If the consumer does not send a maxOperations value, it MUST be prepared to accept any number of update operations per UpdateOperationList. A supplier MAY choose to ignore the maxOperations value sent by a consumer, however, if it does, the supplier MUST NOT send more update operations in a single UpdateOperationList than the value in maxOperations. 6.3. LBURPOperation The LBURPOperation extended request is used to send a set of one or more LDAPv3 update operations from the supplier to the consumer along with sequencing information that enables the consumer to maintain the proper sequencing of multiple asynchronous LBURPOperation requests. An LDAPv3 Extended Request is defined in [LDAPv3] as follows: ExtendedRequest ::= [APPLICATION 23] SEQUENCE { requestName [0] LDAPOID, requestValue [1] OCTET STRING OPTIONAL } The responseName of the LBURPOperation must be the OID "2.16.840.1.113719.1.142.100.6". Individual Submission - Expires September 2, 2001 Harrison, Sermersheim & Dong 7 LDAP Bulk Update/Replication Protocol March, 2001 The requestValue of an LBURPOperation extended operation must be set the BER-encoding of the following: LBURPOperationValue ::= SEQUENCE { sequenceNumber INTEGER (1 .. maxInt), updateOperationList UpdateOperationList } 6.3.1. sequenceNumber The sequenceNumber is used to specify the ordering of LBURPOperation requests. This enables the consumer to know the order in which LBURPOperation requests must be processed even if it receives them in a sequence different from that in which they were sent from the supplier. The supplier MUST set the value of sequenceNumber of the first LBURPOperation to 1, and MUST increment the value of sequenceNumber for each succeeding LBURPOperation. 6.3.2. UpdateOperationList The UpdateOperationList is a list of one or more standard LDAP update requests and is defined as follows: UpdateOperationList ::= SEQUENCE { updateOperation CHOICE { addRequest AddRequest, modifyRequest ModifyRequest, delRequest DelRequest, modDNRequest ModifyDNRequest, } controls [0] Controls OPTIONAL } AddRequest, ModifyRequest, DelRequest, and ModifyDNRequest are standard LDAP update requests as defined in sections 4.6, 4.7, 4.8, and 4.9 of [LDAPv3]. For the LBURP Full Update Protocol, the only valid choice is addRequest. Clients MUST not include any other choice in LBURPOperations sent as part of an LBURP Full Update Protocol update stream. For the LBURP Incremental Update Protocol, all of the choices listed in UpdateOperationList are valid and can be freely intermixed within an LBURP Incremental Update Protocol update stream. The LDAP update requests in the UpdateOperationList MUST be applied to the DIT in the order in which they are listed. 6.4. LBURPOperationDone Individual Submission - Expires September 2, 2001 Harrison, Sermersheim & Dong 8 LDAP Bulk Update/Replication Protocol March, 2001 An LBURPOperationDone extended operation message is sent from the consumer to the supplier to signal that all of the update operations from the UpdateOperationList of an LBURPOperation have been completed and to give the results for the update operations from that list. An LDAPv3 extended response is defined in [LDAPv3] as follows: ExtendedResponse ::= [APPLICATION 24] SEQUENCE { COMPONENTS of LDAPResult, responseName [10] LDAPOID OPTIONAL, response [11] OCTET STRING OPTIONAL } The responseName of the LBURPOperationDone MUST be the OID "2.16.840.1.113719.1.142.100.7". If the consumer server cannot successfully decode the LBURPOperation in its entirety, the resultCode for the LBURPOperationDone is set to protocolError (2) and response element is omitted. No updates from the LBURPOperation should be committed to the DIT in this circumstance. If the status of all of the update operations being reported by an LBURPOperationDone message is success (0), the resultCode of the LBURPOperationDone message is set to success (0) and the response element is omitted. If the status of of any of the update operations being reported by an LBURPOperationDone message is something other than success (0), the resultCode for the entire LBURPOperationDone is set to other (80) to signal that an OperationResults element is in included in the message. 6.4.1. OperationResults A response element is always included in an LBURPOperationDone message and must be set to the BER-encoding of the following: OperationResults ::= SEQUENCE of OperationResult OperationResult ::= SEQUENCE { operationNumber INTEGER, ldapResult LDAPResult } An OperationResult element is included for each operation from the UpdateOperationList that failed during processing. Individual Submission - Expires September 2, 2001 Harrison, Sermersheim & Dong 9 LDAP Bulk Update/Replication Protocol March, 2001 6.4.1.1. operationNumber The operationNumber identifies the LDAPv3 update operation from the UpdateOperationList of the LBURPOperation that failed. Operations are numbered beginning at 1. 6.4.1.2. ldapResult The ldapResult included in the OperationResult is the same ldapResult that would be sent for the update operation that failed if it had failed while being processed as a normal LDAPv3 update operation. 6.5. EndFramedProtocolRequest The EndLBURPRequest extended operation is defined in terms of the [LDAPv3] ExtendedRequest as follows: ExtendedRequest ::= [APPLICATION 23] SEQUENCE { requestName [0] LDAPOID, requestValue [1] OCTET STRING OPTIONAL } The requestName of the EndLBURPRequest must be the OID "2.16.840.1.113719.1.142.100.4". For LBURP, the requestValue of the EndLBURPRequest must be set to the BER-encoding of the following: EndLBURPRequestValue::= SEQUENCE { sequenceNumber INTEGER (1 .. maxInt) } 6.6.1. sequenceNumber The value in sequenceNumber is one greater than the last LBURPOperation sequence number in the update stream. It allows the server to know when it has received all outstanding asynchronous LBURPOperations. 6.7. EndLBURPResponse The EndLBURPResponse is defined in terms of the [LDAPv3] ExtendedResponse as follows: ExtendedResponse ::= [APPLICATION 24] SEQUENCE { COMPONENTS of LDAPResult, responseName [10] LDAPOID OPTIONAL, response [11] OCTET STRING OPTIONAL } Individual Submission - Expires September 2, 2001 Harrison, Sermersheim & Dong 10 LDAP Bulk Update/Replication Protocol March, 2001 The responseName of the EndLBURPResponse must be the OID "2.16.840.1.113719.1.142.100.5". For LBURP, there is no response element for the EndLBURPResponse extended operation. 7. Semantics of Full and Incremental Update Protocols Most of the semantics of LBURP are common to both the full and incremental update protocols although there are some semantic differences between the two. 7.1. Semantics Common to Both Full and Incremental Update Protocols The LBURPOperation requests in the update 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. Regardless of the processing strategy used to increase efficiency, the server MUST ensure that the desired final state is equivalent to that which would have been achieved if the updates in the update stream had been applied to the DIT using normal LDAP update operations. The LBURPOperation requests that form the update stream MAY be sent asynchronously by the supplier to the consumer. This means that the supplier need not wait for an LBURPOperationDone response for one LBURPOperation request before sending the next LBURPOperation request. Suppliers MUST NOT send any request other than an LBURPOperation between the StartFramedProtocolRequest and EndFramedProtocolRequest. If a consumer receives any other LDAP request between the StartFramedProtocolRequest and the EndFramedProtocolRequest, it MUST send a response of protocolError (2) for the offending request. When the LBURP update stream contains a request that affects multiple DSAs, the consumer MAY choose to perform the request or return a resultCode value of affectsMultipleDSAs (71). As with any LDAPv3 operation, a consumer MAY send a resultCode value of referral (10) as part of the OperationResult element for any operation on an entry that it does not contain. If the consumer is configured to do so, it MAY chain on behalf of the supplier to complete the update operation instead. While a consumer server is processing an LBURP update stream, it MAY choose to not service LDAP requests on other connections for the replica involved in the LBURP operation. This provision is designed to allow implementers the freedom to implement highly-efficient Individual Submission - Expires September 2, 2001 Harrison, Sermersheim & Dong 11 LDAP Bulk Update/Replication Protocol March, 2001 methods of handling the update stream without being constrained by the need to maintain a live, working DIT database while doing so. If the update sequence fails for some reason (e.g. a connection is abruptly broken in the middle of an otherwise-successful update sequence) the consumer MUST leave the operations that have been completed in the DIT, thereby leaving the replica in a known state. Since both the full and incremental update protocols use sequences of standard LDAPv3 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]. Unless attribute values specifying timestamps are included as part of the update stream, updates made using LBURP are treated the same as other LDAP operations wherein they are deemed to occur at the present. Consumers MAY store timestamp values sent by suppliers but are not required to do so. 7.2. Semantics of the Full Update Protocol Full update creates a completely new set of entries in a replica; any existing entries in that replica at the start of the LBURP session are removed before the LDAP requests in the update stream are processed. The only LDAP operation allowed in a full update stream is add. Clients MUST NOT send any other type of update operation in the full update stream. If any other LDAP update operation is included in an UpdateOperationList, the server MUST return protocolError (2) as the response for the operation. 7.3. Semantics of the Incremental Update Protocol Incremental update performs a series of incremental changes to a replica; existing entries in the replica are only affected if explicitly modified in some way by the update operations contained in the update stream. All LDAPv3 update operations--add, modify, delete, and moddn--are allowed in the incremental update stream. 8. Notes To Implementers If a consumer chooses to take a replica off-line during an LBURP update, it is RECOMMENDED that the consumer refer non-LBURP requests for the off-line replica to another server containing a replica of the partition. Individual Submission - Expires September 2, 2001 Harrison, Sermersheim & Dong 12 LDAP Bulk Update/Replication Protocol March, 2001 Implementations MAY choose to perform the operations in the update stream with special permissions to improve performance. Consumer implementations SHOULD include functionality to detect and terminate connections on which an LBURP session has been initiated but information (such as an LBURPOperation or the EndLBURPRequest) needed to complete the LBURP session is never received. A timeout is one mechanism that can be used to accomplish this. 9. Security Considerations Implementations should ensure that a supplier making an LBURP 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 update stream with special permissions to improve performance. For these reasons, implementers should carefully consider which identities or permissions are required to perform LBURP operations and take steps to ensure that only connections bound with appropriate permissions are allowed to perform them. The data contained in the update stream may contain passwords and other sensitive data. Care should be taken to properly safeguard this information while in transit between supplier and consumer. As with any asynchronous LDAP operation, it may be possible for an LBURP supplier to send asynchronous LBURPOperation requests to the consumer faster than the consumer can process them. Consumer implementers should take steps to prevent LBURP suppliers from being able interfere with the normal operation of a consumer server by issuing a rapid stream of asynchronous LBURPOperation requests. 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) - Technical Specification", RFC 2849. [ReqsKeywords] Scott Bradner. "Key Words for use in RFCs to Indicate Requirement Levels", RFC 2119. 11. Author's Addresses Individual Submission - Expires September 2, 2001 Harrison, Sermersheim & Dong 13 LDAP Bulk Update/Replication Protocol March, 2001 Roger Harrison Novell, Inc. 1800 S. Novell Place Provo, UT 84606 +1 801 861 2642 roger_harrison@novell.com Jim Sermersheim Novell, Inc. 1800 S. Novell Place Provo, UT 84606 +1 801 861 3088 jimse@novell.com Yulin Dong Novell, Inc. 1800 S. Novell Place Provo, UT 84606 +1 801 861 4940 ydong@novell.com Appendix A - Document Revision History A.1. draft-rharrison-lburp-00.txt Initial Draft A.2. draft-rharrison-lburp-01.txt Adjusted LBURP protocol to use extended requests for all operations. LDAP update operations are now encapsulated within the LBURPOperation request for two reasons: (1) To allow the inclusion of operation ordering information. This allows LDAP servers to maintain the proper ordering of updates even in cases where multi- threaded stacks present update operations to the server out-of- sequence. (2) To allow multiple update operations to be sent from client to server in a single request. This was a natural evolution of the changes made for (1) and allows the protocol to make more efficient use of network bandwidth, Converted references to LDUP extended operations to use a new LDAP Framed Operations Protocol. Specified OIDs used for the protocol and extended operations. Changed requirement that a server "MUST NOT" service non-LBURP requests during a full update to a "MAY choose to not" service non- LBURP requests during a full update. This gives implementers the option to do what is needed without imposing a requirement that may not be needed by some implementations. Individual Submission - Expires September 2, 2001 Harrison, Sermersheim & Dong 14 LDAP Bulk Update/Replication Protocol March, 2001 A.3. draft-rharrison-lburp-02.txt Clarified error responses in cases where one or more of the update operations in the UpdateOperationList of the LBURPOperation fail. Utilized the extended partial response and the LBURPOperationStatus message to allow the consumer to give status on deferred operations and documented this in the protocol flow and elements of protocol. Updated the ASN.1 definition of UpdateOperationList to allow the inclusion of a control on each individual update operation. Made cosmetic changes to the names of the protocol elements to clarify their meanings. Clarified the semantics of the protocol and added additional notes to implementers and security considerations based on implementation and field experience. A.4. draft-rharrison-lburp-03.txt Based on ldup working group feedback, the ability to defer processing operations was removed along with the LBURPOperationStatus message. Due to ongoing work in the ldapext working group on LDAP framing and grouping, references to the LDAP framing protocol were replaced with direct ASN.1 productions and associated text explaining the framing semantics needed for the protocol. 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. Individual Submission - Expires September 2, 2001 Harrison, Sermersheim & Dong 15 LDAP Bulk Update/Replication Protocol March, 2001 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 September 2, 2001 Harrison, Sermersheim & Dong 16