idnits 2.17.1 draft-rharrison-lburp-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 772. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 742. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 749. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 755. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'APPLICATION 23' is mentioned on line 264, but not defined -- Looks like a reference, but probably isn't: '0' on line 374 -- Looks like a reference, but probably isn't: '1' on line 266 == Missing Reference: 'APPLICATION 24' is mentioned on line 272, but not defined -- Looks like a reference, but probably isn't: '10' on line 274 -- Looks like a reference, but probably isn't: '11' on line 275 ** Obsolete normative reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 3383 (Obsoleted by RFC 4520) -- Obsolete informational reference (is this intentional?): RFC 2830 (Obsoleted by RFC 4510, RFC 4511, RFC 4513) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT R. Harrison 3 draft-rharrison-lburp-05.txt J. Sermersheim 4 Intended Category: Informational Y. Dong 5 Novell, Inc. 6 October, 2005 8 LDAP Bulk Update/Replication Protocol 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 This document is intended to be, after appropriate review and 18 revision, submitted to the RFC Editor as an Informational document. 19 Distribution of this memo is unlimited. Technical discussion of 20 this document will take place on the mailing list 21 . Please send editorial comments directly to the 22 author . 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other documents 31 at any time. It is inappropriate to use Internet-Drafts as 32 reference material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.html 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Abstract 42 The Lightweight Directory Access Protocol (LDAP) Bulk 43 Update/Replication Protocol (LBURP) allows an LDAP client to perform 44 a bulk update to an LDAP server. The protocol frames a sequenced 45 set of update operations within a pair of LDAP extended operations 46 to notify the server that the update operations in the framed set 47 are related in such a way that the ordering of all operations can be 48 preserved during processing even when they are sent asynchronously 49 by the client. Update operations can be grouped within a single 50 protocol message to maximize the efficiency of client-server 51 communication. 53 The protocol is suitable for efficiently making a substantial set 54 of updates to the entries in an LDAP server. 56 Table of Contents 58 1. Introduction......................................................2 59 2. Conventions used in this document.................................3 60 3. Overview of Protocol..............................................3 61 3.1. Update Initiation...............................................3 62 3.2. Update Stream...................................................3 63 3.2.1. LBURPUpdateRequest ...........................................3 64 3.2.2. LBURPUpdateResponse ..........................................4 65 3.3. Update Termination..............................................4 66 3.4. Applicability of Protocol.......................................4 67 4. Description of Protocol Flow......................................4 68 5. Elements of Protocol..............................................5 69 5.1. StartLBURPRequest ..............................................6 70 5.1.1. updateStyleOID................................................6 71 5.2. StartLBURPResponse..............................................6 72 5.2.1. maxOperations.................................................7 73 5.3. LBURPUpdateRequest..............................................7 74 5.3.1. sequenceNumber................................................7 75 5.3.2. UpdateOperationList...........................................7 76 5.4. LBURPUpdateResponse.............................................8 77 5.4.1. OperationResults..............................................8 78 5.5. EndLBURPRequest.................................................9 79 5.5.1. sequenceNumber................................................9 80 5.6. EndLBURPResponse................................................9 81 6. Semantics of the Incremental Update Style.........................9 82 7. General LBURP Semantics..........................................10 83 8. Security Considerations..........................................10 84 9. IANA Considerations..............................................11 85 9.1. LDAP Object Identifier Registrations...........................11 86 Normative References................................................11 87 Authors' Addresses..................................................12 88 Appendix A - Document Revision History..............................12 89 Intellectual Property Rights........................................14 91 1. Introduction 93 This protocol arose from the need to allow an LDAP client to 94 efficiently present large quantities of updates to an LDAP server 95 and have the LDAP server efficiently process them. LBURP 96 introduces a minimum of new operational functionality to the LDAP 97 protocol because the update requests sent by the client 98 encapsulate standard LDAP [RFC2251] update operations. However, 99 this protocol greatly facilitates bulk updates by allowing the 100 client to send the update operations asynchronously and still 101 allow the server to maintain proper ordering of the operations. 102 It also allows the server to recognize the client's intent to 103 perform a potentially large set of update operations and then to 104 change its processing strategy to more efficiently process the 105 operations. 107 2. Conventions used in this document 109 Imperative keywords defined in RFC 2119 [RFC2119] are used in this 110 document, and carry the meanings described there. 112 All Basic Encoding Rules (BER) [X.690] encodings follow the 113 conventions found in Section 5.1 of [RFC2251]. 115 The term "supplier" applies to an LDAP client or an LDAP server 116 (acting as a client) that supplies a set of update operations to a 117 consumer. 119 The term "consumer" applies to an LDAP server that consumes (i.e. 120 processes) the sequenced set of update operations sent to it by a 121 supplier. 123 3. Overview of Protocol 125 LBURP frames a set of update operations within a pair of LDAP 126 extended operations that mark the beginning and end of the update 127 set. These updates are sent via LDAP extended operations, each 128 containing a sequence number and a list of one or more update 129 operations to be performed by the consumer. Except for the fact 130 that they are grouped together as part of a larger LDAP message, 131 the update operations in each subset are encoded as LDAP update 132 operations and use the LDAP Abstract Syntax Notation One (ASN.1) 133 [X.680] message types specified in [RFC2251]. 135 3.1. Update Initiation 137 The protocol is initiated when a supplier sends a 138 StartLBURPRequest extended operation to a consumer as a 139 notification that a stream of associated LBURPUpdateRequests will 140 follow. The supplier associates semantics with this stream of 141 requests by including the OID of the bulk update/replication style 142 in the StartLBURPRequest. The consumer responds to the 143 StartLBURPRequest with a StartLBURPResponse message. 145 3.2. Update Stream 147 After the consumer responds with a StartLBURPResponse, the 148 supplier sends a stream of LBURPUpdateRequest messages to the 149 consumer. Messages within this stream may be sent asynchronously 150 to maximize the efficiency of the transfer. The consumer responds 151 to each LBURPUpdateRequest with an LBURPUpdateResponse message. 153 3.2.1. LBURPUpdateRequest 154 Each LBURPUpdateRequest contains a sequence number identifying its 155 relative position within the update stream and an 156 UpdateOperationList containing an ordered list of LDAP update 157 operations to be applied to the DIT. The sequence number enables 158 the consumer to process LBURPUpdateRequest messages in the order 159 they were sent by the supplier even when they are sent 160 asynchronously. The consumer processes each LBURPUpdateRequest 161 according to the sequence number by applying the LDAP update 162 operations in its UpdateOperationList to the DIT in the order they 163 are listed. 165 3.2.2. LBURPUpdateResponse 167 When the consumer has processed the update operations from an 168 UpdateOperationList, it sends an LBURPUpdateResponse to the 169 supplier indicating the success or failure of the update 170 operations contained within the corresponding LBURPUpdateRequest. 172 3.3. Update Termination 174 After the supplier has sent all of its LBURPUpdateRequest 175 messages, it sends an EndLBURPRequest message to the consumer to 176 terminate the update stream. Upon servicing all LBURPOperation 177 requests and receiving the EndLBURPRequest, the consumer responds 178 with an EndLBURPResponse, and the update is complete. 180 3.4. Applicability of Protocol 182 LBURP is designed to facilitate the bulk update of LDAP servers. 183 It can also be used to synchronize directory information between a 184 single master and multiple slaves. 186 No attempt is made to deal with the issues associated with 187 multiple-master replication environments (such as keeping 188 modification times of attribute values) so that updates to the 189 same entry on different replicas can be correctly ordered. For 190 this reason, when LBURP alone is used for replication, proper 191 convergence of the data between all replicas can only be assured 192 in a single-master replication environment. 194 4. Description of Protocol Flow 196 This section describes the LBURP protocol flow and the information 197 contained in each protocol message. Throughout this section, the 198 client or server acting as a supplier is indicated by the letter 199 "S", and the server acting as a consumer is indicated by the 200 letter "C". The construct "S -> C" indicates that the supplier is 201 sending an LDAP message to the consumer, and "C -> S" indicates 202 that the consumer is sending an LDAP message to the supplier. 203 Note that the protocol flow below assumes that a properly- 204 authenticated LDAP session has already been established between 205 the supplier and consumer. 207 S -> C: StartLBURPRequest message. The parameter is: 209 1) OID for the LBURP update style (see section 210 5.1.1). 212 C -> S: StartLBURPResponse message. The parameter is: 214 1) An optional maxOperations instruction 215 (see section 5.2.1). 217 S -> C: An update stream consisting of zero or more 218 LBURPUpdateRequest messages. The requests MAY be sent 219 asynchronously. The parameters are: 221 1) A sequenceNumber specifying the order of 222 this LBURPUpdateRequest with respect to the 223 other LBURPUpdateRequest messages in the update 224 stream. 226 2) LBURPUpdateRequest.updateOperationList, a list 227 of one or more LDAP update operations. 229 The consumer processes the LBURPUpdateRequest messages 230 in the order of their sequence numbers and applies the 231 LDAP update operations contained within each 232 LBURPUpdateRequest to the DIT in the order they are 233 listed. 235 C -> S: LBURPUpdateResponse message. This is sent when the 236 consumer completes processing the update operations 237 from each LBURPUpdateRequest.updateOperationList. 239 S -> C: EndLBURPRequest message. This is sent after the 240 supplier sends all of its LBURPUpdateRequest messages 241 to the consumer. The parameter is: 243 1) A sequence number which is one greater than the 244 sequence number of the last LBURPUpdateRequest 245 message in the update stream. This allows the 246 EndLBURPRequest to also be sent asynchronously. 248 C -> S: EndLBURPResponse message. This is sent in response to 249 the EndLBURPRequest after the consumer has serviced 250 all LBURPOperation requests. 252 5. Elements of Protocol 254 LBURP uses two LDAP ExtendedRequest messages--StartLBURPRequest 255 and EndLBURPRequest--to initiate and terminate the protocol. A 256 third LDAP ExtendedRequest message--LBURPUpdateRequest--is used to 257 send update operations from the supplier to the consumer. These 258 three requests along with their corresponding responses comprise 259 the entire protocol. 261 LBURP request messages are defined in terms of the LDAP 262 ExtendedRequest [RFC2251] as follows: 264 ExtendedRequest ::= [APPLICATION 23] SEQUENCE { 265 requestName [0] LDAPOID, 266 requestValue [1] OCTET STRING OPTIONAL 267 } 269 LBURP response messages are defined in terms of the LDAP 270 ExtendedResponse [RFC2251] as follows: 272 ExtendedResponse ::= [APPLICATION 24] SEQUENCE { 273 COMPONENTS of LDAPResult, 274 responseName [10] LDAPOID OPTIONAL, 275 response [11] OCTET STRING OPTIONAL 276 } 278 5.1. StartLBURPRequest 280 The requestName value of the StartLBURPRequest is OID IANA- 281 ASSIGNED-OID.1. 283 The requestValue of the StartLBURPRequest contains the BER- 284 encoding of the following ASN.1: 286 StartLBURPRequestValue ::= SEQUENCE { 287 updateStyleOID LDAPOID 288 } 290 LDAPOID is defined in [RFC2251] section 4.1.2. 292 5.1.1. updateStyleOID 294 The updateStyleOID is an OID that uniquely identifies the LBURP 295 update style being used. This document defines one LBURP update 296 semantic style that can be transmitted between the 297 StartLBURPRequest and EndLBURPRequest. The updateStyleOID is 298 included in the protocol for future expansion of additional update 299 styles. For example, a future specification might define an 300 update style with semantics to replace all existing entries with a 301 new set of entries and thus only allows the Add operation. 303 The updateStyleOID for the LBURP Incremental Update style is IANA- 304 ASSIGNED-OID.7. The semantics of this update style are described 305 in section 6. 307 5.2. StartLBURPResponse 309 The responseName of the StartLBURPResponse is the OID 310 IANA-ASSIGNED-OID.2. 312 The optional response element contains the BER-encoding of the 313 following ASN.1: 315 StartLBURPResponseValue ::= maxOperations 317 maxOperations ::= INTEGER (0 .. maxInt) 319 maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- 321 5.2.1. maxOperations 323 When present, the value of maxOperations instructs the supplier to 324 send no more than that number of update operations per 325 LBURPUpdateRequest.updateOperationList (see section 5.3.2). If 326 the consumer does not send a maxOperations value, it MUST be 327 prepared to accept any number of update operations per 328 LBURPUpdateRequest.updateOperationList. The supplier MAY send 329 fewer but MUST NOT send more than maxOperations update operations 330 in a single LBURPUpdateRequest.updateOperationList. 332 5.3. LBURPUpdateRequest 334 The LBURPUpdateRequest message is used to send a set of zero or 335 more LDAP update operations from the supplier to the consumer 336 along with sequencing information that enables the consumer to 337 maintain the proper sequencing of multiple asynchronous 338 LBURPUpdateRequest messages. 340 The requestName of the LBURPUpdateRequest is the OID 341 IANA-ASSIGNED-OID.5. 343 The requestValue of an LBURPOperation contains the BER-encoding of 344 the following ASN.1: 346 LBURPUpdateRequestValue ::= SEQUENCE { 347 sequenceNumber INTEGER (1 .. maxInt), 348 updateOperationList UpdateOperationList 349 } 351 5.3.1. sequenceNumber 353 The sequenceNumber orders associated LBURPOperation requests. 354 This enables the consumer to process LBURPOperation requests in 355 the order specified by the supplier. The supplier MUST set the 356 value of sequenceNumber of the first LBURPUpdateRequest to 1, and 357 MUST increment the value of sequenceNumber by 1 for each 358 succeeding LBURPUpdateRequest. In the unlikely event that the 359 number of LBURPUpdateRequest messages exceeds maxInt, a 360 sequenceNumber value of 1 is deemed to be the succeeding sequence 361 number following a sequence number of maxInt. 363 5.3.2. UpdateOperationList 364 The UpdateOperationList is a list of one or more standard LDAP 365 update requests and is defined as follows: 367 UpdateOperationList ::= SEQUENCE OF SEQUENCE{ 368 updateOperation CHOICE { 369 addRequest AddRequest, 370 modifyRequest ModifyRequest, 371 delRequest DelRequest, 372 modDNRequest ModifyDNRequest 373 }, 374 controls [0] Controls OPTIONAL 375 } 377 AddRequest, ModifyRequest, DelRequest, and ModifyDNRequest are 378 defined in sections 4.6, 4.7, 4.8, and 4.9 of [RFC2251]. 380 The LDAP update requests in the UpdateOperationList MUST be 381 applied to the DIT in the order in which they are listed. 383 5.4. LBURPUpdateResponse 385 An LBURPUpdateResponse message is sent from the consumer to the 386 supplier to signal that all of the update operations from the 387 UpdateOperationList of an LBURPUpdateRequest have been completed 388 and to give the results for the update operations from that list. 390 The responseName of the LBURPUpdateResponse is the OID 391 IANA-ASSIGNED-OID.6. 393 If the consumer server cannot successfully decode an 394 LBURPUpdateRequest in its entirety, the resultCode for the 395 corresponding LBURPUpdateResponse is set to protocolError and the 396 response element is omitted. Updates from the LBURPUpdateRequest 397 SHALL NOT be committed to the DIT in this circumstance. 399 If the status of all of the update operations being reported by an 400 LBURPUpdateResponse message is success, the resultCode of the 401 LBURPUpdateResponse message is set to success and the response 402 element is omitted. 404 If the status of any of the update operations being reported by an 405 LBURPUpdateResponse message is something other than success, the 406 resultCode for the entire LBURPUpdateResponse is set to other to 407 signal that the response element is present. 409 5.4.1. OperationResults 411 When a response element is included in an LBURPUpdateResponse 412 message it contains the BER-encoding of the following ASN.1: 414 OperationResults ::= SEQUENCE OF OperationResult 415 OperationResult ::= SEQUENCE { 416 operationNumber INTEGER, 417 ldapResult LDAPResult 418 } 420 An OperationResult is included for each operation from the 421 UpdateOperationList that failed during processing. 423 5.4.1.1. operationNumber 425 The operationNumber identifies the LDAP update operation from the 426 UpdateOperationList of the LBURPUpdateRequest that failed. 427 Operations are numbered beginning at 1. 429 5.4.1.2. ldapResult 431 The ldapResult included in the OperationResult is the same 432 ldapResult that would be sent for the update operation that failed 433 if it had failed while being processed as a normal LDAP update 434 operation. LDAPResult is defined in [RFC2251] section 4.1.10. 436 5.5. EndLBURPRequest 438 The requestName of the EndLBURPRequest is the OID 439 IANA-ASSIGNED-OID.3. 441 The requestValue contains the BER-encoding of the following ASN.1: 443 EndLBURPRequestValue::= SEQUENCE { 444 sequenceNumber INTEGER (1 .. maxInt) 445 } 447 5.5.1. sequenceNumber 449 The value in sequenceNumber is one greater than the last 450 LBURPUpdateRequest.sequenceNumber in the update stream. It allows 451 the server to know when it has received all outstanding 452 asynchronous LBURPUpdateRequests. 454 5.6. EndLBURPResponse 456 The responseName of the EndLBURPResponse is the OID IANA-ASSIGNED- 457 OID.4. 459 There is no response element in the EndLBURPResponse message. 461 6. Semantics of the Incremental Update Style 463 The initial state of entries in the consumer's DIT plus the 464 LBURPUpdateRequest messages in the update stream collectively 465 represent the desired final state of the consumer's DIT. All LDAP 466 update operations defined in [RFC2251]--Add, Modify, Delete, and 467 Modify DN--are allowed in the incremental update stream. All of 468 the semantics of those operations are in effect, so for instance, 469 an attempt to add an entry that already exists will fail just as 470 it would during a normal LDAP Add operation. 472 7. General LBURP Semantics 474 The consumer server may take any action required to efficiently 475 process the updates sent via LBURP, as long as the final state is 476 equivalent to that which would have been achieved if the updates 477 in the update stream had been applied to the DIT using normal LDAP 478 update operations. 480 The LBURPUpdateRequest messages that form the update stream MAY be 481 sent asynchronously by the supplier to the consumer. This means 482 that the supplier need not wait for an LBURPUpdateResponse message 483 for one LBURPUpdateRequest message before sending the next 484 LBURPUpdateRequest message. 486 When the LBURP update stream contains a request that affects 487 multiple DSAs, the consumer MAY choose to perform the request or 488 return a resultCode value of affectsMultipleDSAs. As with any 489 LDAP operation, a consumer MAY send a resultCode value of referral 490 as part of the OperationResult element for any operation on an 491 entry that it does not contain. If the consumer is configured to 492 do so, it MAY chain on behalf of the supplier to complete the 493 update operation instead. 495 While a consumer server is processing an LBURP update stream, it 496 may choose to not service LDAP requests on other connections. 497 This provision is designed to allow implementers the freedom to 498 implement highly-efficient methods of handling the update stream 499 without being constrained by the need to maintain a live, working 500 DIT database while doing so. 502 If a consumer chooses to refuse LDAP operation requests from other 503 suppliers during LBURP update, it is RECOMMENDED that the consumer 504 refer those requests to another server that has the appropriate 505 data to complete the operation. 507 Unless attribute values specifying timestamps are included as part 508 of the update stream, updates made using LBURP are treated the 509 same as other LDAP operations wherein they are deemed to occur at 510 the present. Consumers MAY store timestamp values sent by 511 suppliers but are not required to do so. 513 Implementations may choose to perform the operations in the update 514 stream with special permissions to improve performance. 516 Consumer implementations should include functionality to detect 517 and terminate connections on which an LBURP session has been 518 initiated but information (such as an LBURPUpdateRequest or the 519 EndLBURPRequest) needed to complete the LBURP session is never 520 received. A timeout is one mechanism that can be used to 521 accomplish this. 523 8. Security Considerations 525 Implementations should ensure that a supplier making an LBURP 526 request is properly authenticated and authorized to make the 527 updates requested. There is a potential for loss of data if 528 updates are made to the DIT without proper authorization. If 529 LBURP is used for replication, implementers should note that 530 unlike other replication protocols, no existing replication 531 agreement between supplier and consumer is required. These risks 532 increase if the consumer server also processes the update stream 533 with special permissions to improve performance. For these 534 reasons, implementers should carefully consider which permissions 535 should be required to perform LBURP operations and take steps to 536 ensure that only connections appropriate authorization are allowed 537 to perform them. 539 The data contained in the update stream may contain passwords and 540 other sensitive data. Care should be taken to properly safeguard 541 this information while in transit between supplier and consumer. 542 The StartTLS [RFC2830] operation is one mechanism that can be used 543 to provide data confidentiality and integrity services for this 544 purpose. 546 As with any asynchronous LDAP operation, it may be possible for an 547 LBURP supplier to send asynchronous LBURPUpdateRequest messages to 548 the consumer faster than the consumer can process them. Consumer 549 implementers should take steps to prevent LBURP suppliers from 550 interfering with the normal operation of a consumer server by 551 issuing a rapid stream of asynchronous LBURPUpdateRequest messages. 553 9. IANA Considerations 555 Registration of the following values is requested [RFC3383]. 557 9.1. LDAP Object Identifier Registrations 559 Upon publication of this document, it is requested that IANA 560 register LDAP Object Identifiers identifying the protocol elements 561 defined in this technical specification. The following 562 registration template is provided: 564 Subject: Request for LDAP OID Registration 565 Person & email address to contact for further information: 566 Roger Harrison 567 rharrison@novell.com 568 Specification: RFCXXXX 569 Author/Change Controller: IESG 570 Comments: 572 Seven delegations will be made under the assigned OID. The 573 following 6 OIDs are Protocol Mechanism OIDs of type "E" 574 (supportedExtension): 576 IANA-ASSIGNED-OID.1 StartLBURPRequest LDAP ExtendedRequest message 577 IANA-ASSIGNED-OID.2 StartLBURPResponse LDAP ExtendedResponse 578 message 579 IANA-ASSIGNED-OID.3 EndLBURPRequest LDAP ExtendedRequest message 580 IANA-ASSIGNED-OID.4 EndLBURPResponse LDAP ExtendedResponse message 581 IANA-ASSIGNED-OID.5 LBURPUpdateRequest LDAP ExtendedRequest message 582 IANA-ASSIGNED-OID.6 LBURPUpdateResponse LDAP ExtendedResponse 583 message 585 The following 1 OID is a Protocol Mechanism OID of type "F" 586 (supportedFeature): 588 IANA-ASSIGNED-OID.7 LBURP Incremental Update style OID 590 Normative References 592 [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate 593 Requirement Levels", BCP 14, RFC 2119, March 1997. 595 [RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight 596 Directory Access Protocol (v3)", RFC 2251, December 597 1997. 599 [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority 600 (IANA) Considerations for the Lightweight Directory 601 Access Protocol (LDAP)", BCP 64, RFC 3383, September 602 2002. 604 [X.680] ITU-T Recommendation X.680 (07/2002) | ISO/IEC 8824- 605 1:2002 "Information Technology - Abstract Syntax 606 Notation One (ASN.1): Specification of basic notation" 608 [X.690] ITU-T Rec. X.690 (07/2002) | ISO/IEC 8825-1:2002, 609 "Information technology - ASN.1 encoding rules: 610 Specification of Basic Encoding Rules (BER), Canonical 611 Encoding Rules (CER) and Distinguished Encoding Rules 612 (DER)", 2002. 614 Informative References 616 [RFC2830] Hodges, J., et al, "Lightweight Directory Access 617 Protocol (v3):Extension for Transport Layer Security", 618 RFC 2830, May 2000. 620 Authors' Addresses 622 Roger Harrison 623 Novell, Inc. 624 1800 S. Novell Place 625 Provo, UT 84606 626 +1 801 861 2642 627 rharrison@novell.com 629 Jim Sermersheim 630 Novell, Inc. 631 1800 S. Novell Place 632 Provo, UT 84606 633 +1 801 861 3088 634 jimse@novell.com 636 Yulin Dong 637 Novell, Inc. 638 1800 S. Novell Place 639 Provo, UT 84606 640 +1 801 861 4940 641 ydong@novell.com 643 Appendix A - Document Revision History 645 [Note to RFC Editor: Please remove this appendix upon publication 646 of this Internet-Draft as an RFC.] 648 A.1. draft-rharrison-lburp-00.txt 650 Initial Draft 652 A.2. draft-rharrison-lburp-01.txt 654 Adjusted LBURP protocol to use extended requests for all 655 operations. LDAP update operations are now encapsulated within 656 the LBURPUpdateRequest for two reasons: (1) To allow the inclusion 657 of operation ordering information. This allows LDAP servers to 658 maintain the proper ordering of updates even in cases where multi- 659 threaded stacks present update operations to the server out-of- 660 sequence. (2) To allow multiple update operations to be sent from 661 client to server in a single request. This was a natural evolution 662 of the changes made for (1) and allows the protocol to make more 663 efficient use of network bandwidth, 665 Converted references to LDUP extended operations to use a new LDAP 666 Framed Operations Protocol. 668 Specified OIDs used for the protocol and extended operations. 670 Changed requirement that a server "MUST NOT" service non-LBURP 671 requests during a full update to a "MAY choose to not" service 672 non-LBURP requests during a full update. This gives implementers 673 the option to do what is needed without imposing a requirement 674 that may not be needed by some implementations. 676 A.3. draft-rharrison-lburp-02.txt 677 Clarified error responses in cases where one or more of the update 678 operations in the UpdateOperationList of the LBURPUpdateRequest 679 fail. 681 Utilized the extended partial response and the LBURPUpdateStatus 682 message to allow the consumer to give status on deferred 683 operations and documented this in the protocol flow and elements 684 of protocol. 686 Updated the ASN.1 definition of UpdateOperationList to allow the 687 inclusion of a control on each individual update operation. 689 Made cosmetic changes to the names of the protocol elements to 690 clarify their meanings. 692 Clarified the semantics of the protocol and added additional notes 693 to implementers and security considerations based on 694 implementation and field experience. 696 A.4. draft-rharrison-lburp-03.txt 698 Based on ldup working group feedback, the ability to defer 699 processing operations was removed along with the LBURPUpdateStatus 700 message. 702 Due to ongoing work in the ldapext working group on LDAP framing 703 and grouping, references to the LDAP framing protocol were 704 replaced with direct ASN.1 productions and associated text 705 explaining the framing semantics needed for the protocol. 707 A.5. draft-rharrison-lburp-04.txt 709 Removed LBURP Full Update style due to lack of current 710 implementation. 712 Editorial changes to bring document into conformance with current 713 RFC and Internet-Draft content and formatting requirements. 715 Other editorial changes to fix typographical or grammatic errors 716 or to clarify intent. 718 Added IANA Considerations section and moved OID specifications to 719 fall within the IANA-assigned OID subarc requested for assignment. 721 A.6. draft-rharrison-lburp-06.txt 723 Updated security considerations to (1) include both authentication 724 and authorization of LBURP suppliers and (2) suggest StartTLS as a 725 mechanism to protect sensitive data in transit between supplier 726 and consumer. 728 Clarified the types of OIDs requested from IANA in IANA 729 Considerations section. 731 Fixed citations to X.680 and X.690. 733 Intellectual Property Rights 735 The IETF takes no position regarding the validity or scope of any 736 Intellectual Property Rights or other rights that might be claimed 737 to pertain to the implementation or use of the technology 738 described in this document or the extent to which any license 739 under such rights might or might not be available; nor does it 740 represent that it has made any independent effort to identify any 741 such rights. Information on the procedures with respect to rights 742 in RFC documents can be found in BCP 78 and BCP 79. 744 Copies of IPR disclosures made to the IETF Secretariat and any 745 assurances of licenses to be made available, or the result of an 746 attempt made to obtain a general license or permission for the use 747 of such proprietary rights by implementers or users of this 748 specification can be obtained from the IETF on-line IPR repository 749 at http://www.ietf.org/ipr. 751 The IETF invites any interested party to bring to its attention 752 any copyrights, patents or patent applications, or other 753 proprietary rights that may cover technology that may be required 754 to implement this standard. Please address the information to the 755 IETF at ietf-ipr@ietf.org. 757 Full Copyright Statement 759 Copyright (C) The Internet Society (2005). 761 This document is subject to the rights, licenses and restrictions 762 contained in BCP 78, and except as set forth therein, the authors 763 retain all their rights. 765 This document and the information contained herein are provided on 766 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 767 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 768 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 769 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 770 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 771 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 772 PARTICULAR PURPOSE.