Individual Submission to ldup working group                 R. Harrison
Internet Draft                                           J. Sermersheim
Document: draft-rharrison-lburp-01.txt                     Novell, Inc.
Category: Proposed Standard                                 March, 2000


                 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.


. Abstract

   The protocol described in this document allows an LDAP client (a
   genuine client or an LDAP server acting as a client) to perform a
   bulk update to a replica on an LDAP server. The protocol groups a
   set of update operations using the LDAP framed protocol requests
   defined in [FRAMING] to notify the client that the update operations
   in the framed set are related.  The update operations within the
   framed set are LDAP v3 extended operations each containing a
   sequence number and one or more update LDAP v3 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 change the existing entries in an LDAP
   replica. It is suitable for client utilities that need to
   efficiently initialize a replica with many entries or efficiently
   make a substantial set of update changes to a replica. It is also
   suitable as a protocol for replication between a single master
   replica and its slave replicas.


          Individual Submission - Expires September 10, 2000
Harrison & Sermersheim                                               1

                LDAP Bulk Update/Replication Protocol     March, 2000



. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC-2119
   [ReqsKeywords].

   The term supplier applies to an LDAP client or and 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
   (processes) the update operations sent to it by a supplier.


. 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. This protocol
   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 this process by allowing the client to present
   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 perform a potentially
   large set of update operations and then to change its processing
   strategy to be more efficient than it otherwise could be.

   In effect, this protocol gives a hint to the server that the LDAP
   operations framed within it can be treated in a special way because
   they are related to each other. The server may then take actions
   that would not otherwise be practical to speed the processing of the
   updates. Examples of such actions include refusing to perform
   operations for other clients during the update sequence and grouping
   update operations into a single transaction rather than applying
   them to the DIT singly.

   Additionally, this protocol deals with a common interoperability
   problem in this space caused by implementations having different
   requirements and abilities for handling linear and circular
   dependencies as entries are created.  A common application of this
   protocol is anticipated to be the initialization or update of an
   LDAP replica from a set of records represented in an [LDIF] file.
   Due to the abilities of various implementations, these files often
   contain "out-of-order" records where an entry is created before its
   parent or it is made a member of a group before the member's entry
   has been created. Some implementations create temporary holding
   objects to deal with these issues, but others do not.  This protocol
   allows the server to reorder update operations in a limited way to
   deal with such cases.

          Individual Submission - Expires September 10, 2000
Harrison & Sermersheim                                               2

                LDAP Bulk Update/Replication Protocol     March, 2000



. Overview of protocol

   The bulk replication/update protocol utilizes framing described in
   [FRAMING] to group a set of update operations to be applied to a
   naming context. The update operations are sent via LDAP v3 extended
   operations, each of which contains 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 v3 extended request, the update operations in each
   subset are normal LDAP v3 update operations and use the encoding
   specified in [LDAPv3].


4.1. Update Initiation

   The protocol is initiated when a supplier sends a
   StartFramedProtocolRequest extended operation to a consumer to
   notify it that the following stream of LDAP update operations are to
   be treated as a unit of update information. The consumer responds to
   the StartFramedProtocolRequest with a StartFramedProtocolResponse.

4.2. Update Stream

   After the consumer responds with a StartFramedProtocolResponse
   extended operation, the supplier sends a stream of
   LBURPOperationRequest extended operations to the consumer. This
   stream MAY be sent asynchronously to maximize the efficiency of the
   transfer. Except in certain circumstances allowed by the protocol to
   deal with linear and circular dependency issues, the consumer
   processes each LBURPOperationRequest in the order it was sent by the
   supplier by applying the LDAP v3 update operations contained within
   it to the DIT. (The sequence number in each request is utilized to
   ensure that proper ordering between LBURPOperationRequests is
   maintained even when the requests are sent asynchronously.) As each
   LBURPOperationRequest is completed, the consumer sends a
   LBURPOperationResponse to the supplier indicating the success or
   failure of the operation.

4.3. Update Termination

   When the supplier has sent all LBURPOperationRequests, it sends an
   EndFramedProtocolRequest extended operation to the consumer to
   terminate the update stream.  The consumer responds with an
   EndFramedProtocolResponse extended operation, and the update is
   complete.

4.4. Update Styles

   Two styles of update--full and incremental--are defined.


          Individual Submission - Expires September 10, 2000
Harrison & Sermersheim                                               3

                LDAP Bulk Update/Replication Protocol     March, 2000


   Full update creates a completely new set of entries in the target
   replica; any existing entries in that replica at the start of the
   StartFramedProtocolRequest operation are removed before the LDAP
   requests in the replication stream are processed. The only LDAP
   operation allowed in a full update stream is add. After a server
   receives and acknowledges a StartFramedProtocolRequest for the
   LBURPFullUpdateProtocol, the LDAP server MAY choose to not service
   LDAP requests other than those contained in the update stream for
   the replica which is being initialized until that update stream is
   completely processed.

   Incremental update performs a series of incremental changes to the
   replica; existing entries in the replica are only affected if
   explicitly modified in some way by the update operations contained
   in the update stream. All update operations defined in [LDAPv3]--
   add, modify, delete, and moddn--are allowed in the incremental
   update stream.  When a server is processing an incremental update
   stream, the replica that is being modified MAY choose to not service
   LDAP requests other than those contained in the update stream until
   that update stream is completely processed.

4.5. Applicability of Protocol

   No attempt is made to deal with the issues associated with multiple-
   master replicas or to maintain state information such as
   modification times of entries or attribute values in such a way that
   updates to the same entry on multiple master replicas can be
   correctly ordered.  For this reason convergence of data between all
   replicas can only be assured in a single-master replication
   environment.

. High-level Description of Protocol Flow

   The following section provides a high-level overview of the
   replication protocol. Throughout this section, the client or server
   acting as supplier is indicated by the letter "S", and the server
   acting as consumer is indicated by the letter "C". The construct "S
   -> C" indicates that the supplier is sending an LDAPv3 operation to
   the consumer, and "C -> S" indicates that the consumer is sending an
   LDAPv3 operation to the supplier.


         S -> C: LDAP bind operation (identity and credentials
                used are implementation-defined)

         C -> S: Bind response

         S -> C: StartFramedProtocolRequest LDAPv3 extended
                 operation. The parameters are:

                  1) OID of LBURP incremental or full update


          Individual Submission - Expires September 10, 2000
Harrison & Sermersheim                                               4

                LDAP Bulk Update/Replication Protocol     March, 2000


                     replication protocol as defined in this
                     document.

         C -> S: StartFramedProtocolResponse LDAPv3 extended operation.
                 The parameters are:

                   1) A suggested transactionSize (see section 6.2.1)


         S -> C: The supplier may send zero or more
                 LBURPOperationRequest LDAPv3 extended operations.
                 The requests MAY be sent asynchronously. The
                 parameters are:

                   1) A sequence number which specifies the order of
                      the operation with respect to other operations
                      in the replication stream.

   2) A list of one or more LDAP v3 update operations.

         C -> S: The consumer processes each of the LDAP v3 update
                 operations contained within an LBURPOperationRequest.
                 If it was able to successfully complete all of the
                 update operations in the request, the consumer sends
                 an LBURPOperationResponse with a result code of
                 success.  If one or more of the LDAP v3 update
                 operations was not completed successfully, the
                 consumer sends an LBURPOperationResponse with a non-
                 success result code and includes a sequence of
                 LDAPResult elements for each of the failed update
                 operations which indicate the reason for failure.

         S -> C: After all required updates have been sent to the
                 consumer, the supplier sends an
                 EndFramedProtocolRequest LDAPv3 extended
                 operation. The parameters are:

                    1) A sequence number which is one greater than the
                       sequence number of the last operation in the
                       replication stream.


         C -> S: The consumer responds by sending an
                 EndFramedProtocolResponse LDAPv3 extended operation.


. Elements of Protocol

   The LDAP Bulk Update/Replication protocol works within the framework
   of the Replication Update Protocol [LDUP RUP].  Unless otherwise



          Individual Submission - Expires September 10, 2000
Harrison & Sermersheim                                               5

                LDAP Bulk Update/Replication Protocol     March, 2000


   stated, those elements of protocol taken from the Replication Update
   Protocol framework are to be used precisely as described there.

6.1. StartFramedProtocolRequest Extended Operation

   Section 4.1 of [FRAMING] defines the StartFramedProtocolRequest
   extended operation 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 StartFramedProtocolRequest 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:

       StartFramedProtocolRequestValue ::= SEQUENCE {
           framedProtocolOID LDAPOID,
           framedProtocolPayload OPTIONAL OCTET STRING
       }

6.1.1. framedProtocolOID

   The framedProtocolOID is an OID that uniquely identifies the
   protocol framed by this operation.

   The framedProtocolOID for the LBURP Incremental Update Protocol is
   2.16.840.1.113719.1.142.1.4.1.  The framedProtocolOID for the LBURP
   Full Update Protocol is 2.16.840.1.113719.1.142.1.4.2.

6.1.2. framedProtocolPayload

   The framedProtocolPayload is an octet string that contains protocol-
   specific information.

   For LBURP, there is no framedProtocolPayload element for the
   StartFramedProtocolRequest extended operation.

6.2. StartFramedProtocolResponse

   Section 4.2 of [FRAMING] defines the StartFramedProtocolResponse
   extended operation in terms of the [LDAPv3] ExtendedResponse as
   follows:

       ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
            COMPONENTS of LDAPResult,
            responseName  [10] LDAPOID OPTIONAL,

          Individual Submission - Expires September 10, 2000
Harrison & Sermersheim                                               6

                LDAP Bulk Update/Replication Protocol     March, 2000


            response      [11] OCTET STRING OPTIONAL
        }

   The responseName of the StartFramedProtocolResponse must be the OID
   "2.16.840.1.113719.1.142.100.2".

   For LBURP, the response of a StartFramedProtocolResponse must be set
   to the BER-encoding of the following:

       LBURPStartFramedProtocolResponse ::= SEQUENCE {
           transactionSize INTEGER,
   }

6.2.1 transactionSize

   The transactionSize is 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.

6.3. LBURPOperationRequest

   The LBURPOperationRequest extended operation is used to send a set
   of one or more LDAP v3 update operations from the supplier to the
   consumer along with sequencing information that enables the consumer
   to maintain the proper sequencing of among multiple asynchronous
   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 LBURPOperationRequest must be the OID
   "2.16.840.1.113719.1.142.100.6".

   The requestValue of an LBURPOperationRequest extended operation must
   be set the BER-encoding of the following:

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

6.3.1. sequenceNumber

   The sequenceNumber is used to specify the ordering of
   LBURPOperationRequests. This enables the consumer to know the order
   in which LBURPOperationRequests must be processed even if it
   receives them in a sequence different from that in which they were

          Individual Submission - Expires September 10, 2000
Harrison & Sermersheim                                               7

                LDAP Bulk Update/Replication Protocol     March, 2000


   sent from the supplier.  The supplier MUST set the value of
   sequenceNumber of the first LBURPOperationRequest to 1, and MUST
   increment the value of sequenceNumber for each succeeding
   LBURPOperationRequest.

6.3.2. UpdateOperationList

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

       UpdateOperationList ::= SEQUENCE of CHOICE {
           addRequest           AddRequest,
           modifyRequest        ModifyRequest,
           delRequest           DelRequest,
           modDNRequest         ModifyDNRequest,
       }

   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 Incremental Update Protocol, all of the choices listed
   in OpList are valid and can be freely intermixed within an LBURP
   Incremental Update Protocol replication stream

   For the LBURP Full Update Protocol, the only valid choice is
   addRequest.  Clients MUST not include any other choice in
   LBURPOperationRequests sent as part of an LBURP Full Update Protocol
   replication stream.

6.4. LBURPOperationResponse

   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 LBURPOperationResponse must be the OID
   "2.16.840.1.113719.1.142.100.7".


   The response of an LBURPOperationRequest extended operation must be
   set the BER-encoding of the following:

       LBURPOperationResponseValue ::= SEQUENCE of OperationResult

       OperationResult ::= SEQUENCE {

          Individual Submission - Expires September 10, 2000
Harrison & Sermersheim                                               8

                LDAP Bulk Update/Replication Protocol     March, 2000


           operationNumber      INTEGER,
           ldapResult LDAPResult
       }

   If all of the update operations contained in the
   LBURPOperationRequest are successfully processed, the resultCode of
   the LBURPOperationResponse is set to success and no
   LBURPOperationResponseValue is included in the
   LBURPOperationResponse.

   If any of the update operations contained in the
   LBURPOperationRequest fails, an LBURPOperationResponseValue is
   included in the LBURPOperationResponse. For each update operation
   that fails, an OperationResult is included in the
   LBURPOperationResponseValue.

6.4.1. operationNumber

The operationNumber identifies the operation that failed. Operations
are numbered beginning at 1.

6.4.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 v3 update operation.

6.5. EndFramedProtocolRequest

   Section 4.3 of [FRAMING] defines the EndFramedProtocolRequest
   extended operation in terms of the [LDAPv3] ExtendedRequest as
   follows:

      ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
          requestName    [0] LDAPOID,
          requestValue   [1] OCTET STRING OPTIONAL
      }

   The requestName of the EndFramedProtocolRequest must be the OID
   "2.16.840.1.113719.1.142.100.4".

   For LBURP, the requestValue of the EndFramedProtocolRequest must be
   set to the BER-encoding of the following:

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

6.5.1. sequenceNumber



          Individual Submission - Expires September 10, 2000
Harrison & Sermersheim                                               9

                LDAP Bulk Update/Replication Protocol     March, 2000


   The value in sequenceNumber is one greater than the last
   LBURPOperationRequest sequence number in the replication stream. It
   allows the server to know when it has received all outstanding
   asynchronous LBURPOperationRequests.

6.6. EndFramedProtcolResponse

   Section 4.4 of [FRAMING] defines the EndFramedProtocolResponse
   extended operation 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 EndFramedProtocolResponse must be the OID
      "2.16.840.1.113719.1.142.100.5".

   For LBURP, there is no response element for the
   EndFramedProtocolResponse extended operation.

. Semantics of Full and Incremental Update Protocols

7.1. Semantics Common to Both Full and Incremental Update Protocols

   Since both the full and incremental update protocols use sequences
   of standard LDAP v3 operations to transmit update information, no
   attempt is made by the protocol to include the information needed to
   support full multi-master replication as defined by [LDUP RUP].
   Although entries and their associated attributes and attribute
   values can be synchronized using this protocol, no CSNs are included
   in the update stream; updates made using this replication protocol
   are treated the same as other LDAP operations wherein they are
   deemed to occur at the present.  Operational attributes such as
   modifiersTimeStamp MAY be included in the replication stream, and if
   they are, they SHOULD be put into the entry.

   The LBURPOperationRequests that form the replication stream MAY be
   sent asynchronously by the supplier to the consumer. This means that
   the supplier need not wait for a LBURPOperationResponse from one
   LBURPOperationRequest before sending the next.

   The LBURPOperationRequests in the replication stream, plus the
   initial state of entries in the consumer replica in the case of
   incremental update, collectively represent the desired final state
   of the consumer replica. The consumer server may take any action
   required to efficiently achieve this desired final state of the
   replica.  Examples of such actions include reordering LDAP requests
   to ensure that linear dependencies within the replication stream are

          Individual Submission - Expires September 10, 2000
Harrison & Sermersheim                                              10

                LDAP Bulk Update/Replication Protocol     March, 2000


   correctly ordered, breaking an LDAP modification request into two or
   more separate modification requests to adequately resolve a circular
   dependency within the replication stream, and aggregating LDAP
   update operations to process them more efficiently.  When taking
   actions of this sort, the server MUST NOT reorder LDAP requests in
   such a way that the desired final state is different from that which
   would have been achieved before the action was taken.

   While a consumer server is processing a an LBURP update stream, the
   it MAY choose to not service LDAP requests for the replica involved
   in the replication operation other than those contained in the
   replication stream including LDAP requests on other connections.
   This requirement is designed to allow implementers the freedom to
   implement highly-efficient methods of handling the replication
   stream without being constrained by the need to maintain a live,
   working DIT database while doing so.


7.2. Semantics of the Full Replication Protocol


   Full replication creates a completely new set of entries in that
   replica; any existing entries in that replica at the start of the
   replication operation are removed before the LDAP requests in the
   replication stream are processed.

   The only LDAP operation allowed in a full update stream is add.
   Clients MUST NOT send any other type of update operation in the full
   update stream. If any other LDAP operation is received as part of
   the update stream, the server MUST return unwillingToPerform as the
   response for the operation.


   If the full update sequence fails for some reason (e.g. a connection
   is abruptly broken in the middle of an otherwise-successful update
   sequence) the server MUST remove any entries created during the
   update sequence, thereby leaving the replica in a known state.


7.3. Semantics of the Incremental Replication Protocol


   Incremental replication performs a series of incremental changes to
   the replica; existing entries in the replica are only affected if
   explicitly modified in some way by the update operations contained
   in the replication stream.

   All LDAP v3 update operations--add, modify, delete, and moddn--are
   allowed in the incremental replication stream. If a non-update
   operation is received as part of the replication stream, the server
   MUST return unwillingToPerform as the response for the operation.

. Notes To Implementers



          Individual Submission - Expires September 10, 2000
Harrison & Sermersheim                                              11

                LDAP Bulk Update/Replication Protocol     March, 2000


   It is RECOMMENDED that, if possible, the consumer LDAP server refer
   non-replication requests for the replica being updated to another
   server containing that replica during the time that consumer LDAP
   server has the replica off-line for replication.

   Implementations MAY choose to perform the operations in the
   replication stream with special permissions to improve performance.

. Security Considerations

   Implementations should ensure that a supplier making a Bulk
   Update/Replication request is bound with appropriate permissions.
   There is a potential for loss of data, especially with the full
   update protocol, which removes all entries in a replica as part of
   its operation. Second, forcing the removal of all entries in a
   replica may consume large amounts of server resources. Third, unlike
   other replication protocols, no existing replication agreement
   between supplier and consumer is required. These risks increase if
   the consumer server also processes the replication stream with
   special permissions to improve performance. For these reasons,
   implementers should carefully consider which identities or
   permissions are required to perform Bulk Update/Replication Protocol
   operations and take steps to ensure that only connections bound with
   appropriate permissions are allowed to perform them.

   The data contained in the replication stream may contain passwords
   and other sensitive data.  Care should be taken to properly
   safeguard this information while in transit between supplier and
   consumer.

. Document Revision History

10.1. draft-rharrison-lburp-00.txt

   Initial Draft

10.2. draft-rharrison-lburp-01.txt

   Adjusted LBURP protocol to use extended requests for all operations.
   LDAP update operations are now encapsulated within the LBURP
   Operation 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.

          Individual Submission - Expires September 10, 2000
Harrison & Sermersheim                                              12

                LDAP Bulk Update/Replication Protocol     March, 2000



   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.

. References

   [FRAMING]
        Stokes, Ellen, and Gordon Good, ôExtended Operations for
        Framing LDAP Operationsö, UNPUBLISHED INTERNET-DRAFT: ldup-
        framing.txt.

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

   [LDIF]
        Gordon Good, "LDAP Data Interchange Format (LDIF)", INTERNET-
        DRAFT: draft-good-ldap-ldif-04.txt, 22 June 1999.

   [ReqsKeywords]
        Scott Bradner. "Key Words for use in RFCs to Indicate
        Requirement Levels". RFC 2119.

. Author's Addresses

   Roger Harrison
   Novell, Inc.
   122 E. 1700 S.
   Provo, UT 84606
   +1 801 861 2642
   roger_harrison@novell.com

   Jim Sermersheim
   Novell, Inc.
   122 E. 1700 S.
   Provo, UT 84606
   +1 801 861 3088
   jimse@novell.com


Full Copyright Statement

   "Copyright (C) The Internet Society (date). All Rights Reserved.
   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation may be prepared, copied, published


          Individual Submission - Expires September 10, 2000
Harrison & Sermersheim                                              13

                LDAP Bulk Update/Replication Protocol     March, 2000


   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
































          Individual Submission - Expires September 10, 2000
Harrison & Sermersheim                                              14