Skip to main content

Lightweight Directory Access Protocol (LDAP) Bulk Update/Replication Protocol (LBURP)
draft-rharrison-lburp-05

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 4373.
Authors Yulin Dong, Roger Harrison , Jim Sermersheim
Last updated 2018-12-20 (Latest revision 2005-10-11)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Informational
Formats
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 4373 (Informational)
Action Holders
(None)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Ted Hardie
Send notices to (None)
draft-rharrison-lburp-05
INTERNET-DRAFT                                              R. Harrison
draft-rharrison-lburp-05.txt                             J. Sermersheim
Intended Category: Informational                                Y. Dong
                                                           Novell, Inc.
                                                          October, 2005

                 LDAP Bulk Update/Replication Protocol

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   This document is intended to be, after appropriate review and
   revision, submitted to the RFC Editor as an Informational document.
   Distribution of this memo is unlimited.  Technical discussion of
   this document will take place on the mailing list
   <ldapext@ietf.org>.  Please send editorial comments directly to the
   author <roger_harrison@novell.com>.

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

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Abstract

   The Lightweight Directory Access Protocol (LDAP) Bulk
   Update/Replication Protocol (LBURP) allows an LDAP client to perform
   a bulk update to an LDAP server.  The protocol frames a sequenced
   set of update operations within a pair of LDAP extended operations
   to notify the server that the update operations in the framed set
   are related in such a way that the ordering of all operations can be
   preserved during processing even when they are sent asynchronously
   by the client.  Update operations can be grouped within a single
   protocol message to maximize the efficiency of client-server
   communication.

Harrison, et al          Expires April, 2006                 [Page 1]
Internet-Draft  LDAP Bulk Update/Replication Protocol    October 2005

   The protocol is suitable for efficiently making a substantial set
   of updates to the entries in an LDAP server.

Table of Contents

1. Introduction......................................................2
2. Conventions used in this document.................................3
3. Overview of Protocol..............................................3
3.1. Update Initiation...............................................3
3.2. Update Stream...................................................3
3.2.1. LBURPUpdateRequest ...........................................3
3.2.2. LBURPUpdateResponse ..........................................4
3.3. Update Termination..............................................4
3.4. Applicability of Protocol.......................................4
4. Description of Protocol Flow......................................4
5. Elements of Protocol..............................................5
5.1. StartLBURPRequest ..............................................6
5.1.1. updateStyleOID................................................6
5.2. StartLBURPResponse..............................................6
5.2.1. maxOperations.................................................7
5.3. LBURPUpdateRequest..............................................7
5.3.1. sequenceNumber................................................7
5.3.2. UpdateOperationList...........................................7
5.4. LBURPUpdateResponse.............................................8
5.4.1. OperationResults..............................................8
5.5. EndLBURPRequest.................................................9
5.5.1. sequenceNumber................................................9
5.6. EndLBURPResponse................................................9
6. Semantics of the Incremental Update Style.........................9
7. General LBURP Semantics..........................................10
8. Security Considerations..........................................10
9. IANA Considerations..............................................11
9.1. LDAP Object Identifier Registrations...........................11
Normative References................................................11
Authors' Addresses..................................................12
Appendix A - Document Revision History..............................12
Intellectual Property Rights........................................14

1. Introduction

   This protocol arose from the need to allow an LDAP client 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 because the update requests sent by the client
   encapsulate standard LDAP [RFC2251] update operations.  However,
   this protocol greatly facilitates bulk updates by allowing the
   client to send the update operations asynchronously and still
   allow the server to maintain proper ordering of the operations.
   It also allows the server to recognize the client's intent to

Harrison, et al          Expires April, 2006                 [Page 2]
Internet-Draft  LDAP Bulk Update/Replication Protocol    October 2005

   perform a potentially large set of update operations and then to
   change its processing strategy to more efficiently process the
   operations.  

2. Conventions used in this document

   Imperative keywords defined in RFC 2119 [RFC2119] are used in this
   document, and carry the meanings described there.

   All Basic Encoding Rules (BER) [X.690] encodings follow the
   conventions found in Section 5.1 of [RFC2251].

   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. Overview of Protocol

   LBURP frames a set of update operations within a pair of LDAP
   extended operations that mark the beginning and end of the update
   set.  These updates are sent via LDAP 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 LDAP message,
   the update operations in each subset are encoded as LDAP update
   operations and use the LDAP Abstract Syntax Notation One (ASN.1)
   [X.680] message types specified in [RFC2251]. 

3.1. Update Initiation

   The protocol is initiated when a supplier sends a
   StartLBURPRequest extended operation to a consumer as a
   notification that a stream of associated LBURPUpdateRequests will
   follow.  The supplier associates semantics with this stream of
   requests by including the OID of the bulk update/replication style
   in the StartLBURPRequest.  The consumer responds to the
   StartLBURPRequest with a StartLBURPResponse message.

3.2. Update Stream

   After the consumer responds with a StartLBURPResponse, the
   supplier sends a stream of LBURPUpdateRequest messages to the
   consumer.  Messages within this stream may be sent asynchronously
   to maximize the efficiency of the transfer.  The consumer responds
   to each LBURPUpdateRequest with an LBURPUpdateResponse message.

3.2.1. LBURPUpdateRequest 

Harrison, et al          Expires April, 2006                 [Page 3]
Internet-Draft  LDAP Bulk Update/Replication Protocol    October 2005

   Each LBURPUpdateRequest contains a sequence number identifying its
   relative position within the update stream and an
   UpdateOperationList containing an ordered list of LDAP update
   operations to be applied to the DIT.  The sequence number enables
   the consumer to process LBURPUpdateRequest messages in the order
   they were sent by the supplier even when they are sent
   asynchronously.  The consumer processes each LBURPUpdateRequest
   according to the sequence number by applying the LDAP update
   operations in its UpdateOperationList to the DIT in the order they
   are listed.

3.2.2. LBURPUpdateResponse 

   When the consumer has processed the update operations from an
   UpdateOperationList, it sends an LBURPUpdateResponse to the
   supplier indicating the success or failure of the update
   operations contained within the corresponding LBURPUpdateRequest.

3.3. Update Termination

   After the supplier has sent all of its LBURPUpdateRequest
   messages, it sends an EndLBURPRequest message to the consumer to
   terminate the update stream.  Upon servicing all LBURPOperation
   requests and receiving the EndLBURPRequest, the consumer responds
   with an EndLBURPResponse, and the update is complete.

3.4. Applicability of Protocol

   LBURP is designed to facilitate the bulk update of LDAP servers.
   It can also be used to synchronize directory information between a
   single master and multiple slaves.

   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 alone is used for replication, proper
   convergence of the data between all replicas can only be assured
   in a single-master replication environment.

4. 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 a supplier is indicated by the letter
   "S", and the server acting as a consumer is indicated by the
   letter "C".  The construct "S -> C" indicates that the supplier is
   sending an LDAP message to the consumer, and "C -> S" indicates
   that the consumer is sending an LDAP message to the supplier.
   Note that the protocol flow below assumes that a properly-
   authenticated LDAP session has already been established between
   the supplier and consumer.

Harrison, et al          Expires April, 2006                 [Page 4]
Internet-Draft  LDAP Bulk Update/Replication Protocol    October 2005

       S -> C: StartLBURPRequest message.  The parameter is:

                  1) OID for the LBURP update style (see section
5.1.1).

       C -> S: StartLBURPResponse message.  The parameter is:

                  1) An optional maxOperations instruction
                     (see section 5.2.1).

       S -> C: An update stream consisting of zero or more
               LBURPUpdateRequest messages.  The requests MAY be sent
               asynchronously.  The parameters are:

                  1) A sequenceNumber specifying the order of
                     this LBURPUpdateRequest with respect to the 
                     other LBURPUpdateRequest messages in the update 
                     stream.

                  2) LBURPUpdateRequest.updateOperationList, a list 
                     of one or more LDAP update operations.

               The consumer processes the LBURPUpdateRequest messages
               in the order of their sequence numbers and applies the
               LDAP update operations contained within each
               LBURPUpdateRequest to the DIT in the order they are
               listed.

       C -> S: LBURPUpdateResponse message.  This is sent when the
               consumer completes processing the update operations
               from each LBURPUpdateRequest.updateOperationList.

       S -> C: EndLBURPRequest message.  This is sent after the
               supplier sends all of its LBURPUpdateRequest messages
               to the consumer.  The parameter is:

                  1) A sequence number which is one greater than the 
                     sequence number of the last LBURPUpdateRequest
                     message in the update stream.  This allows the
                     EndLBURPRequest to also be sent asynchronously.

       C -> S: EndLBURPResponse message.  This is sent in response to
               the EndLBURPRequest after the consumer has serviced
               all LBURPOperation requests.

5. Elements of Protocol

   LBURP uses two LDAP ExtendedRequest messages--StartLBURPRequest
   and EndLBURPRequest--to initiate and terminate the protocol.  A
   third LDAP ExtendedRequest message--LBURPUpdateRequest--is used to
   send update operations from the supplier to the consumer.  These

Harrison, et al          Expires April, 2006                 [Page 5]
Internet-Draft  LDAP Bulk Update/Replication Protocol    October 2005

   three requests along with their corresponding responses comprise
   the entire protocol.

   LBURP request messages are defined in terms of the LDAP
   ExtendedRequest [RFC2251] as follows:
    
        ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
            requestName    [0] LDAPOID,
            requestValue   [1] OCTET STRING OPTIONAL
        }

   LBURP response messages are defined in terms of the LDAP
   ExtendedResponse [RFC2251] as follows:

       ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
           COMPONENTS of LDAPResult,
           responseName  [10] LDAPOID OPTIONAL,
           response      [11] OCTET STRING OPTIONAL
        }

5.1. StartLBURPRequest 

   The requestName value of the StartLBURPRequest is OID IANA-
   ASSIGNED-OID.1.

   The requestValue of the StartLBURPRequest contains the BER-
   encoding of the following ASN.1:

       StartLBURPRequestValue ::= SEQUENCE {
           updateStyleOID LDAPOID
       }

   LDAPOID is defined in [RFC2251] section 4.1.2.

5.1.1. updateStyleOID

   The updateStyleOID is an OID that uniquely identifies the LBURP
   update style being used.  This document defines one LBURP update
   semantic style that can be transmitted between the
   StartLBURPRequest and EndLBURPRequest.  The updateStyleOID is
   included in the protocol for future expansion of additional update
   styles.  For example, a future specification might define an
   update style with semantics to replace all existing entries with a
   new set of entries and thus only allows the Add operation.

   The updateStyleOID for the LBURP Incremental Update style is IANA-
   ASSIGNED-OID.7.  The semantics of this update style are described
   in section 6.

5.2. StartLBURPResponse

   The responseName of the StartLBURPResponse is the OID 
   IANA-ASSIGNED-OID.2.

Harrison, et al          Expires April, 2006                 [Page 6]
Internet-Draft  LDAP Bulk Update/Replication Protocol    October 2005

   The optional response element contains the BER-encoding of the
   following ASN.1:

       StartLBURPResponseValue ::= maxOperations

       maxOperations ::= INTEGER (0 .. maxInt)

       maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --

5.2.1. maxOperations

   When present, the value of maxOperations instructs the supplier to
   send no more than that number of update operations per
   LBURPUpdateRequest.updateOperationList (see section 5.3.2).  If
   the consumer does not send a maxOperations value, it MUST be
   prepared to accept any number of update operations per
   LBURPUpdateRequest.updateOperationList.  The supplier MAY send
   fewer but MUST NOT send more than maxOperations update operations
   in a single LBURPUpdateRequest.updateOperationList.

5.3. LBURPUpdateRequest

   The LBURPUpdateRequest message is used to send a set of zero or
   more LDAP update operations from the supplier to the consumer
   along with sequencing information that enables the consumer to
   maintain the proper sequencing of multiple asynchronous
   LBURPUpdateRequest messages.

   The requestName of the LBURPUpdateRequest is the OID 
   IANA-ASSIGNED-OID.5.

   The requestValue of an LBURPOperation contains the BER-encoding of
   the following ASN.1:

       LBURPUpdateRequestValue ::= SEQUENCE {
           sequenceNumber INTEGER (1 .. maxInt),
           updateOperationList UpdateOperationList
       }

5.3.1. sequenceNumber

   The sequenceNumber orders associated LBURPOperation requests.
   This enables the consumer to process LBURPOperation requests in
   the order specified by the supplier.  The supplier MUST set the
   value of sequenceNumber of the first LBURPUpdateRequest to 1, and
   MUST increment the value of sequenceNumber by 1 for each
   succeeding LBURPUpdateRequest.  In the unlikely event that the
   number of LBURPUpdateRequest messages exceeds maxInt, a
   sequenceNumber value of 1 is deemed to be the succeeding sequence
   number following a sequence number of maxInt.

5.3.2. UpdateOperationList

Harrison, et al          Expires April, 2006                 [Page 7]
Internet-Draft  LDAP Bulk Update/Replication Protocol    October 2005

   The UpdateOperationList is a list of one or more standard LDAP
   update requests and is defined as follows:

       UpdateOperationList ::= SEQUENCE OF SEQUENCE{
           updateOperation CHOICE {
               addRequest       AddRequest,
               modifyRequest    ModifyRequest,
              delRequest       DelRequest,
              modDNRequest     ModifyDNRequest
           },
           controls       [0] Controls OPTIONAL
       }

   AddRequest, ModifyRequest, DelRequest, and ModifyDNRequest are
   defined in sections 4.6, 4.7, 4.8, and 4.9 of [RFC2251].

   The LDAP update requests in the UpdateOperationList MUST be
   applied to the DIT in the order in which they are listed.

5.4. LBURPUpdateResponse

   An LBURPUpdateResponse message is sent from the consumer to the
   supplier to signal that all of the update operations from the
   UpdateOperationList of an LBURPUpdateRequest have been completed
   and to give the results for the update operations from that list. 

   The responseName of the LBURPUpdateResponse is the OID 
   IANA-ASSIGNED-OID.6.

   If the consumer server cannot successfully decode an
   LBURPUpdateRequest in its entirety, the resultCode for the
   corresponding LBURPUpdateResponse is set to protocolError and the
   response element is omitted.  Updates from the LBURPUpdateRequest
   SHALL NOT be committed to the DIT in this circumstance.

   If the status of all of the update operations being reported by an
   LBURPUpdateResponse message is success, the resultCode of the
   LBURPUpdateResponse message is set to success and the response
   element is omitted.

   If the status of any of the update operations being reported by an
   LBURPUpdateResponse message is something other than success, the
   resultCode for the entire LBURPUpdateResponse is set to other to
   signal that the response element is present.

5.4.1. OperationResults

   When a response element is included in an LBURPUpdateResponse
   message it contains the BER-encoding of the following ASN.1:

       OperationResults ::= SEQUENCE OF OperationResult

Harrison, et al          Expires April, 2006                 [Page 8]
Internet-Draft  LDAP Bulk Update/Replication Protocol    October 2005

       OperationResult ::= SEQUENCE {
          operationNumber    INTEGER,
           ldapResult         LDAPResult
       }

   An OperationResult is included for each operation from the
   UpdateOperationList that failed during processing. 

5.4.1.1. operationNumber

   The operationNumber identifies the LDAP update operation from the
   UpdateOperationList of the LBURPUpdateRequest that failed.
   Operations are numbered beginning at 1.

5.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 LDAP update
   operation. LDAPResult is defined in [RFC2251] section 4.1.10.

5.5. EndLBURPRequest

   The requestName of the EndLBURPRequest is the OID 
   IANA-ASSIGNED-OID.3.

   The requestValue contains the BER-encoding of the following ASN.1:

        EndLBURPRequestValue::= SEQUENCE {
            sequenceNumber INTEGER (1 .. maxInt) 
        }

5.5.1. sequenceNumber

   The value in sequenceNumber is one greater than the last
   LBURPUpdateRequest.sequenceNumber in the update stream.  It allows
   the server to know when it has received all outstanding
   asynchronous LBURPUpdateRequests.

5.6. EndLBURPResponse

   The responseName of the EndLBURPResponse is the OID IANA-ASSIGNED-
   OID.4.

   There is no response element in the EndLBURPResponse message.

6. Semantics of the Incremental Update Style

   The initial state of entries in the consumer's DIT plus the
   LBURPUpdateRequest messages in the update stream collectively
   represent the desired final state of the consumer's DIT.  All LDAP
   update operations defined in [RFC2251]--Add, Modify, Delete, and
   Modify DN--are allowed in the incremental update stream.  All of

Harrison, et al          Expires April, 2006                 [Page 9]
Internet-Draft  LDAP Bulk Update/Replication Protocol    October 2005

   the semantics of those 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 LDAP Add operation.

7. General LBURP Semantics

   The consumer server may take any action required to efficiently
   process the updates sent via LBURP, as long as the 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 LBURPUpdateRequest messages 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 LBURPUpdateResponse message
   for one LBURPUpdateRequest message before sending the next
   LBURPUpdateRequest message. 

   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.  As with any
   LDAP operation, a consumer MAY send a resultCode value of referral
   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.
   This provision is designed to allow implementers the freedom to
   implement highly-efficient methods of handling the update stream
   without being constrained by the need to maintain a live, working
   DIT database while doing so.

   If a consumer chooses to refuse LDAP operation requests from other
   suppliers during LBURP update, it is RECOMMENDED that the consumer
   refer those requests to another server that has the appropriate
   data to complete the operation. 

   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.

   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 LBURPUpdateRequest or the
   EndLBURPRequest) needed to complete the LBURP session is never

Harrison, et al          Expires April, 2006                [Page 10]
Internet-Draft  LDAP Bulk Update/Replication Protocol    October 2005

   received.  A timeout is one mechanism that can be used to
   accomplish this.

8. Security Considerations

   Implementations should ensure that a supplier making an LBURP
   request is properly authenticated and authorized to make the
   updates requested.  There is a potential for loss of data if
   updates are made to the DIT without proper authorization.  If
   LBURP is used for replication, implementers should note that
   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 permissions
   should be required to perform LBURP operations and take steps to
   ensure that only connections appropriate authorization 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.
   The StartTLS [RFC2830] operation is one mechanism that can be used
   to provide data confidentiality and integrity services for this
   purpose.

   As with any asynchronous LDAP operation, it may be possible for an
   LBURP supplier to send asynchronous LBURPUpdateRequest messages to
   the consumer faster than the consumer can process them.  Consumer
   implementers should take steps to prevent LBURP suppliers from
   interfering with the normal operation of a consumer server by
   issuing a rapid stream of asynchronous LBURPUpdateRequest messages.

9. IANA Considerations

   Registration of the following values is requested [RFC3383].

9.1. LDAP Object Identifier Registrations

   Upon publication of this document, it is requested that IANA
   register LDAP Object Identifiers identifying the protocol elements
   defined in this technical specification.  The following
   registration template is provided:

   Subject: Request for LDAP OID Registration
   Person & email address to contact for further information:
       Roger Harrison
       rharrison@novell.com
   Specification: RFCXXXX
   Author/Change Controller: IESG
   Comments:

Harrison, et al          Expires April, 2006                [Page 11]
Internet-Draft  LDAP Bulk Update/Replication Protocol    October 2005

   Seven delegations will be made under the assigned OID.  The
   following 6 OIDs are Protocol Mechanism OIDs of type "E"
   (supportedExtension):

   IANA-ASSIGNED-OID.1 StartLBURPRequest LDAP ExtendedRequest message
   IANA-ASSIGNED-OID.2 StartLBURPResponse LDAP ExtendedResponse
   message
   IANA-ASSIGNED-OID.3 EndLBURPRequest LDAP ExtendedRequest message
   IANA-ASSIGNED-OID.4 EndLBURPResponse LDAP ExtendedResponse message
   IANA-ASSIGNED-OID.5 LBURPUpdateRequest LDAP ExtendedRequest message
   IANA-ASSIGNED-OID.6 LBURPUpdateResponse LDAP ExtendedResponse
   message

   The following 1 OID is a Protocol Mechanism OID of type "F"
   (supportedFeature):

   IANA-ASSIGNED-OID.7 LBURP Incremental Update style OID

Normative References

   [RFC2119]  Bradner, S., "Key Words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2251]  Wahl, M., Howes, T., and S. Kille, "Lightweight
              Directory Access Protocol (v3)", RFC 2251, December
              1997.

   [RFC3383]  Zeilenga, K., "Internet Assigned Numbers Authority
              (IANA) Considerations for the Lightweight Directory
              Access Protocol (LDAP)", BCP 64, RFC 3383, September
              2002.

   [X.680]    ITU-T Recommendation X.680 (07/2002) | ISO/IEC 8824-
              1:2002 "Information Technology - Abstract Syntax
              Notation One (ASN.1): Specification of basic notation" 

   [X.690]    ITU-T Rec. X.690 (07/2002) | ISO/IEC 8825-1:2002,
              "Information technology - ASN.1 encoding rules:
              Specification of Basic Encoding Rules (BER), Canonical
              Encoding Rules (CER) and Distinguished Encoding Rules
              (DER)", 2002.

Informative References

   [RFC2830]  Hodges, J., et al, "Lightweight Directory Access
              Protocol (v3):Extension for Transport Layer Security",
              RFC 2830, May 2000.

Authors' Addresses

   Roger Harrison
   Novell, Inc.
   1800 S. Novell Place

Harrison, et al          Expires April, 2006                [Page 12]
Internet-Draft  LDAP Bulk Update/Replication Protocol    October 2005

   Provo, UT 84606
   +1 801 861 2642
   rharrison@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

   [Note to RFC Editor: Please remove this appendix upon publication
   of this Internet-Draft as an RFC.]

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

A.3. draft-rharrison-lburp-02.txt

Harrison, et al          Expires April, 2006                [Page 13]
Internet-Draft  LDAP Bulk Update/Replication Protocol    October 2005

   Clarified error responses in cases where one or more of the update
   operations in the UpdateOperationList of the LBURPUpdateRequest
   fail.

   Utilized the extended partial response and the LBURPUpdateStatus
   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 LBURPUpdateStatus
   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.

A.5. draft-rharrison-lburp-04.txt

   Removed LBURP Full Update style due to lack of current
   implementation. 

   Editorial changes to bring document into conformance with current
   RFC and Internet-Draft content and formatting requirements.

   Other editorial changes to fix typographical or grammatic errors
   or to clarify intent.

   Added IANA Considerations section and moved OID specifications to
   fall within the IANA-assigned OID subarc requested for assignment.

A.6. draft-rharrison-lburp-06.txt

   Updated security considerations to (1) include both authentication
   and authorization of LBURP suppliers and (2) suggest StartTLS as a
   mechanism to protect sensitive data in transit between supplier
   and consumer.

   Clarified the types of OIDs requested from IANA in IANA
   Considerations section.

Harrison, et al          Expires April, 2006                [Page 14]
Internet-Draft  LDAP Bulk Update/Replication Protocol    October 2005

   Fixed citations to X.680 and X.690.

Intellectual Property Rights

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it
   represent that it has made any independent effort to identify any
   such rights.  Information on the procedures with respect to rights
   in RFC documents can be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
   specification can be obtained from the IETF on-line IPR repository
   at http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention
   any copyrights, patents or patent applications, or other
   proprietary rights that may cover technology that may be required
   to implement this standard.  Please address the information to the
   IETF at ietf-ipr@ietf.org.

Full Copyright Statement

   Copyright (C) The Internet Society (2005). 

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Harrison, et al          Expires April, 2006                [Page 15]