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]
