idnits 2.17.1 draft-zeilenga-ldap-txn-10.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 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 503. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 474. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 481. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 487. 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 IETF Trust 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? (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.) -- The document date (8 July 2007) is 6135 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3062' is mentioned on line 107, but not defined == Unused Reference: 'DONTUSECOPY' is defined on line 462, but no explicit reference was found in the text -- No information found for draft-zeilenga-ldap-noop-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'NO-OP' -- No information found for draft-zeilenga-ldap-relax-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'RELAX' -- No information found for draft-zeilenga-ldap-dontusecopy-xx - is the name correct? Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Kurt D. Zeilenga 3 Intended Category: Standard Track Isode Limited 4 Expires in six months 8 July 2007 6 LDAP Transactions 7 9 Status of Memo 11 This document is intended to be, after appropriate review and 12 revision, submitted to the IESG for consideration as a Proposed 13 Standard. Distribution of this memo is unlimited. Technical 14 discussion of this document will take place on the IETF LDAP 15 Extensions mailing list . Please send editorial 16 comments directly to the author . 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware have 20 been or will be disclosed, and any of which he or she becomes aware 21 will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering Task 24 Force (IETF), its areas, and its working groups. Note that other 25 groups may also distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference material 30 or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Copyright (C) The IETF Trust (2007). All Rights Reserved. 40 Please see the Full Copyright section near the end of this document 41 for more information. 43 Abstract 45 Lightweight Directory Access Protocol (LDAP) update operations, such 46 as Add, Delete, and Modify operations, have atomic, consistency, 47 isolation, durability (ACID) properties. Each of these update 48 operations act upon an entry. It is often desirable to update two or 49 more entries in a single unit of interaction, a transaction. 50 Transactions are necessary to support a number of applications 51 including resource provisioning. This document extends LDAP to 52 support transactions. 54 1. Overview 56 This document extends the Lightweight Directory Access Protocol (LDAP) 57 [RFC4510] to allow clients to relate a number of update operations 58 [RFC4511] and have them preformed as one unit of interaction, a 59 transaction. As with distinct update operations, each transaction has 60 atomic, consistency, isolation, and durability (ACID) properties 61 [ACID]. 63 This extension consists of two extended operations, one control, and 64 one unsolicited notification message. The Start Transaction operation 65 is used to obtain a transaction identifier. This identifier is then 66 attached to multiple update operations to indicate that they belong to 67 the transaction using the Transaction Specification control. The End 68 Transaction is used to settle (commit or abort) the transaction. The 69 Aborted Tranaction Notice is provided by the server to notify the 70 client that the server is no longer willing or able to process an 71 outstanding transaction. 73 1.1. Conventions and Terminology 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in BCP 14 [RFC2119]. 79 Protocol elements are described using ASN.1 [X.680] with implicit 80 tags. The term "BER-encoded" means the element is to be encoded using 81 the Basic Encoding Rules [X.690] under the restrictions detailed in 82 Section 5.1 of [RFC4511]. 84 DSA stands for "Directory System Agent" (a server). DSE stands for 85 "DSA-specific entry". 87 2. Elements of an LDAP Transaction 88 2.1. Start Transaction Request and Response 90 A Start Transaction Request is an LDAPMessage of CHOICE extendedReq 91 where the requestName is IANA-ASSIGNED-OID.1 and the requestValue is 92 absent. 94 A Start Transaction Response is an LDAPMessage of CHOICE extendedRes 95 sent in response to a Start Transaction Request. Its responesName is 96 absent. When the resultCode is success (0), responseValue is present 97 and contains a transaction identifier. Otherwise, the responseValue 98 is absent. 100 2.2. Transaction Specification Control 102 A Transaction Specification control is an LDAPControl where the 103 controlType is IANA-ASSIGNED-OID.2, the criticality is TRUE, and the 104 controlValue is a transaction identifer. The control is appropriate 105 for update requests including Add, Delete, Modify, and ModifyDN 106 (Rename) requests [RFC4511], as well as the Password Modify requests 107 [RFC3062]. 109 2.3. End Transactions Request and Response 111 An End Transaction Request is an LDAPMessage of CHOICE extendedReq 112 where the requestName is IANA-ASSIGNED-OID.3 and the requestValue is 113 present and contains a BER-encoded settlementValue. 115 settlementValue ::= SEQUENCE { 116 commit BOOLEAN DEFAULT TRUE, 117 identifier OCTET STRING } 119 A commit value of TRUE indicates a request to commit the transaction 120 identified by the identifier. A commit value of FALSE indicates a 121 request to abort the identified transaction. 123 An End Transaction Response is an LDAPMessage sent in response to a 124 End Transaction Request. Its response name is absent. The 125 responseValue when present contains a BER-encoded MessageID. The 126 responseValue is always absent when the resultCode is success (0). 128 2.4. Aborted Transaction Notice 130 The Aborted Transaction Notice is an Unsolicited Notification message 131 where the responseName is IANA-ASSIGNED-OID.4 and responseValue is 132 present and contains a transaction identifier. 134 3. An LDAP Transaction 136 3.1. Extension Discovery 138 To allow clients to discover support for this extension, servers 139 implementing this specification SHOULD publish IANA-ASSIGNED-OID.1 and 140 IANA-ASSIGNED-OID.3 as values of the 'supportedExtension' attribute 141 [RFC4512] within the Root DSE, and publish the IANA-ASSIGNED-OID.2 as 142 a value of the 'supportedControl' attribute [RFC4512] of the Root DSE. 144 A server MAY choose to advertise this extension only when the client 145 is authorized to use it. 147 3.2. Starting a Transaction 149 A client wishing to preform a sequence of directory updates as an 150 transaction issues a Start Transaction Request. A server which is 151 willing and able to support transactions responds to this request with 152 a Start Transaction Response providing a transaction identifier and 153 with a resultCode of success (0). Otherwise, the server responds with 154 a Start Transaction Response with a result code other than success 155 indicating the nature of the failure. 157 The transaction identifier provided upon successful start of a 158 transaction is used in subseqent protocol messages to identify this 159 transaction. 161 3.3. Specification of a Transaction 163 The client then can issue one or more update requests, each with a 164 Transaction Specification control containing the transaction 165 identifier indicating the updates are to processed as part of the 166 transaction. Each of these update request MUST have a different 167 MessageId value. If the server is unwilling or unable to attempt to 168 process the requested update operation as part of the transaction, the 169 server immediately returns the approrpiate response to the request 170 with a resultCode indicating the nature of the failure. Otherwise, 171 the server immediately returns success (0) and the defers further 172 processing of the operation is then deferred until settlement. 174 If the server becomes unwilling or unable to continue the 175 specification of a transaction, the server issues an Aborted 176 Transaction Notice with a non-success resultCode indicating the nature 177 of the failure. All operations that were to be processed as part of 178 the transaction are implicitly abandoned. Upon receipt of an Aborted 179 Transaction Notice, the client is to discontinue all use of the 180 transaction identifier as the transaction is null and void. Any 181 future use of identifier by the client will result in a response 182 containing a non-success resultCode. 184 3.4. Transaction Settlement 186 A client requests settlement of transaction by issuing an End 187 Transaction request for the transaction indicating whether it desires 188 the transaction to be committed or aborted. 190 Upon receipt of a request to abort the transaction, the server is to 191 abort the identified transaction (abandoning all operations which are 192 part of the transaction) and indicate that it has done so by returning 193 an End Transaction response with a resultCode of success (0). 195 Upon receipt of a request to commit the transaction, the server 196 processes all update operations of the transaction as one atomic, 197 durable, isolated, and consistent action with each requested update 198 being processed in turn. Either all of the requested updates are to 199 be successfully applied or none of the requested are to be applied. 200 The server returns an End Transaction Response with a resultCode of 201 success (0) and no responseValue to indicate all the requested updates 202 were applied. Otherwise, the server returns an End Transaction with 203 an non-success resultCode indicating the nature of the failure. If 204 the failure is associated with a particular update request, a 205 responseValue containing its MessageID is returned. If the failure 206 was not associated with any particular update request, no 207 responseValue is returned. 209 There is no requirement that a server serialize transactions, or 210 updates requested outside of a transaction. That is, a server MAY 211 process multiple commit requests (from one or more clients) acting 212 upon different sets of entries concurrently. A server MUST avoid 213 deadlock. 215 3.5. Miscellaneous Issues 217 Transactions cannot be nested. 219 Each LDAP transaction should be initiated, specified, and settled 220 within a stable security context. Between the Start request and the 221 End response, the peers SHOULD avoid negotiating new security 222 associations and/or layers. 224 Upon receipt of a Bind or Unbind request, the server SHALL abort any 225 and all outstanding transactions without notice and nullify their 226 identifiers. 228 4. Interaction with Other Extensions 230 The LDAP Transaction extension may be used with many but not all LDAP 231 control extensions designed to extend Update (and possibly other) 232 operations. The remainder of this subsection discusses interaction 233 with a number of control extensions. Interaction with other control 234 extensions may be discussed in other documents, in particular in 235 control extension specifications. 237 4.1. Assertion Control 239 The Assertion [RFC4528] control is appropriate for use with update 240 requests specified as part of a transaction. The evaluation of the 241 assertion is performed as part of the transaction. 243 The Assertion control is inappropriate for use with either the 244 Transaction Start or End extended operations. 246 4.2. ManageDsaIT Control 248 The ManageDsaIT [RFC3296] control is appropriate for use with update 249 requests specified as part of a transaction. 251 The ManageDsaIt control is inappropriate for use with either the 252 Transaction Start or End extended operations. 254 4.3. No-Op Control 256 The No-Op [NO-OP] control is appropriate for use with the Transaction 257 Start or End extended operations. 259 The No-Op control is not appropriate for update requests specified as 260 part of a transaction. A server supporting both the No-Op control 261 extension and this extension SHALL regard a request containing both 262 controls as a protocol violation. As both of the No-Op and 263 Transaction Specification request controls are required to be marked 264 as critical, a server implementing one of these request controls, or 265 neither, is expected to return unavailableCriticalExtension as 266 prescribed by [RFC4511]. 268 4.4. Proxied Authorization Control 269 The Proxied Authorization [RFC4370] control is appropriate for use 270 with the Transaction Start extended operation, but not the Transaction 271 End extended operation or any update request specified as part of a 272 transaction. 274 To request that a transaction be performed under a different 275 authorization, the client provides a Proxied Authorization control 276 with the Transaction Start request. If the client is not authorized 277 to assume the requested authorization identity, the server is to 278 return the authorizationDenied (123) resultCode in its response. 279 Otherwise, further processing of the request and transaction is 280 performed under the requested authorization identity. 282 Any proxied authorization request attached to an update request 283 specified as part of a transaction, or attached to a Transaction end 284 request, is to be regarded as a protocol error. 286 4.5. Read Entry Controls 288 [[Alternative to consider: allow read entry controls on update 289 requests and return entries with end transaction response.]] 291 The Pre- and Post-Read Entry [RFC4527] controls are inappopriate for 292 use with update requests specified as part of a transactions. A 293 server supporting the Read Entry controls extension and this extension 294 SHALL regard a request containing both controls as a protocol 295 violation. As the Transaction Specification request control is 296 required to be marked critical, a server not implementing the 297 transactions extension is expected to return unavailable extension as 298 prescribed by [RFC4511]. A server that implements the transactions 299 extension but not the read entry extension is expected to, if the read 300 entry control is critical, return unavailableCriticalExtension or, if 301 the read entry control is non-critical, ignore the read entry control. 303 The Pre- and Post-Read Entry controls are also inapprorpiate for use 304 with the Transaction Start and End extended operations. 306 4.6. Relax Rules Control 308 The Relax Rules [RELAX] control is appropriate for use with update 309 requests specified as part of a transaction. 311 The Relax Rules control is inappropriate for use with either the 312 Transaction Start or End extended operations. 314 5. Distributed Directory Considerations 316 The LDAP/X.500 models provide for distributed directory operations, 317 including server-side chaining and client-side chasing of referrals. 319 This document does not preclude servers from chaining operations which 320 are part of a transaction. However, if a server does attempt such 321 chaining, it MUST ensure that transaction semantics are provided. 323 This mechanism defined by this document does not support client-side 324 chasing. Grouping cookies used to identify the transaction are 325 specific to a particular client/server session. 327 The LDAP/X.500 models provide for a single-master/multiple-shadow 328 replication architecture. There is no requirement that changes made 329 to the directory based upon processing a transaction be replicated as 330 one atomic action. Hence, clients SHOULD NOT assume tight data 331 consistency nor fast data convergence of shadow copies unless they 332 have prior knowledge that these properties are provided. Note that 333 [dontUseCopy] control may be used in conjunction with the LDAP search 334 request to ask for the return of the authoritative copy of the entry. 336 6. Security Considerations 338 Transactions mechanisms may be the target of denial-of-service 339 attacks, especially where implementation lock shared resources for the 340 duration of a transaction. 342 General security considerations [RFC4510], especially those associated 343 with update operations [RFC4511], apply to this extension. 345 7. IANA Considerations 347 It is requested that Internet Assigned Numbers Authority (IANA) make 348 the following assignments. 350 7.1. Object Identifier 352 Assignment of an LDAP Object Identifier [RFC4520] to identify the 353 protocol elements specified in this document this document is 354 requested. 356 Subject: Request for LDAP Object Identifier Registration 357 Person & email address to contact for further information: 358 Kurt Zeilenga 360 Specification: RFC XXXX 361 Author/Change Controller: IESG 362 Comments: Identifies protocol elements for LDAP Transactions 364 7.2. LDAP Protocol Mechanism 366 Registration of the protocol mechanisms [RFC4520] specified in this 367 document is requested. 369 Subject: Request for LDAP Protocol Mechanism Registration 370 Object Identifier: see table 371 Description: see table 372 Person & email address to contact for further information: 373 Kurt Zeilenga 374 Specification: RFC XXXX 375 Author/Change Controller: IESG 376 Comments: 378 Object Identifier Type Description 379 ------------------- ---- ---------------------------------- 380 IANA-ASSIGNED-OID.1 E Start Transaction Extended Request 381 IANA-ASSIGNED-OID.2 C Transaction Specification Control 382 IANA-ASSIGNED-OID.3 E End Transaction Extended Request 383 IANA-ASSIGNED-OID.4 N Aborted Transaction Notice 385 Legend 386 ------------------------ 387 C => supportedControl 388 E => supportedExtension 389 N => Unsolicited Notice 391 8. Acknowledgments 393 The author gratefully acknowledges the contributions made by Internet 394 Engineering Task Force participants. 396 9. Author's Address 398 Kurt D. Zeilenga 399 Isode Limited 401 Email: Kurt.Zeilenga@Isode.COM 403 10. References 405 [[Note to the RFC Editor: please replace the citation tags used in 406 referencing Internet-Drafts with tags of the form RFCnnnn where 407 possible.]] 409 10.1. Normative References 411 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 412 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 414 [RFC3296] Zeilenga, K., "Named Subordinate References in 415 Lightweight Directory Access Protocol (LDAP) 416 Directories", RFC 3296, July 2002. 418 [RFC4370] Weltman, R., "LDAP Proxied Authentication Control", RFC 419 4370, Feb. 2006. 421 [RFC4510] Zeilenga, K. (editor), "LDAP: Technical Specification 422 Road Map", RFC 4510, June 2006. 424 [RFC4511] Sermersheim, J. (editor), "LDAP: The Protocol", RFC 425 4511, June 2006. 427 [RFC4512] Zeilenga, K. (editor), "LDAP: Directory Information 428 Models", RFC 4512, June 2006. 430 [RFC4527] Zeilenga, K., "LDAP Read Entry Controls", RFC 4527, June 431 2006. 433 [RFC4528] Zeilenga, K., "LDAP Assertion Control", RFC 4528, June 434 2006. 436 [X.680] International Telecommunication Union - 437 Telecommunication Standardization Sector, "Abstract 438 Syntax Notation One (ASN.1) - Specification of Basic 439 Notation", X.680(2002) (also ISO/IEC 8824-1:2002). 441 [X.690] International Telecommunication Union - 442 Telecommunication Standardization Sector, "Specification 443 of ASN.1 encoding rules: Basic Encoding Rules (BER), 444 Canonical Encoding Rules (CER), and Distinguished 445 Encoding Rules (DER)", X.690(2002) (also ISO/IEC 446 8825-1:2002). 448 [NO-OP] Zeilenga, K., "LDAP No-Operation Control", draft- 449 zeilenga-ldap-noop-xx.txt, a work in progress. 451 [RELAX] Zeilenga, K., "LDAP Relax Rules Control", draft- 452 zeilenga-ldap-relax-xx.txt, a work in progress. 454 10.2. Informative References 456 [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority 457 (IANA) Considerations for the Lightweight Directory 458 Access Protocol (LDAP)", RFC 4520, BCP 64, June 2006. 460 [ACID] Section 4 of ISO/IEC 10026-1:1992. 462 [DONTUSECOPY] Zeilenga, K., "LDAP Don't Use Copy Control", draft- 463 zeilenga-ldap-dontusecopy-xx.txt, a work in progress. 465 Intellectual Property 467 The IETF takes no position regarding the validity or scope of any 468 Intellectual Property Rights or other rights that might be claimed to 469 pertain to the implementation or use of the technology described in 470 this document or the extent to which any license under such rights 471 might or might not be available; nor does it represent that it has 472 made any independent effort to identify any such rights. Information 473 on the procedures with respect to rights in RFC documents can be found 474 in BCP 78 and BCP 79. 476 Copies of IPR disclosures made to the IETF Secretariat and any 477 assurances of licenses to be made available, or the result of an 478 attempt made to obtain a general license or permission for the use of 479 such proprietary rights by implementers or users of this specification 480 can be obtained from the IETF on-line IPR repository at 481 http://www.ietf.org/ipr. 483 The IETF invites any interested party to bring to its attention any 484 copyrights, patents or patent applications, or other proprietary 485 rights that may cover technology that may be required to implement 486 this standard. Please address the information to the IETF at 487 ietf-ipr@ietf.org. 489 Full Copyright 491 Copyright (C) The IETF Trust (2007). 493 This document is subject to the rights, licenses and restrictions 494 contained in BCP 78, and except as set forth therein, the authors 495 retain all their rights. 497 This document and the information contained herein are provided on an 498 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 499 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 500 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 501 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 502 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 503 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.