idnits 2.17.1 draft-zeilenga-ldap-txn-08.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 on line 396. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 367. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 374. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 380. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 384), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** 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 -- 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 (25 June 2006) is 6512 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 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 7 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 OpenLDAP Foundation 4 Expires in six months 25 June 2006 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 Internet Society (2006). 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. However, It is often desirable to 49 update two or more entries in a single unit of interaction, a 50 transaction. Transactions are necessary to support a number of 51 applications including resource provisioning. This document defines 52 an LDAP extension to support transactions. 54 1. Overview 56 This document extends the Lightweight Directory Access Protocol (LDAP) 57 [RFC4510] to allow clients to group a number of related update 58 operations [RFC4511] and have them preformed as one unit of 59 interaction, a transaction. As with distinct update operations, each 60 transaction has atomic, consistency, isolation, and durability 61 ([ACID]) properties. 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 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 used notify the client the server is no 70 longer willing or able to process an outstanding transaction. 72 1.1. Conventions and Terminology 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in BCP 14 [RFC2119]. 78 Protocol elements are described using ASN.1 [X.680] with implicit 79 tags. The term "BER-encoded" means the element is to be encoded using 80 the Basic Encoding Rules [X.690] under the restrictions detailed in 81 Section 5.1 of [RFC4511]. 83 DSA stands for "Directory System Agent" (a server). DSE stands for 84 "DSA-specific entry". 86 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, responseValue is present and 97 contains a transaction identifier. Otherwise, the responseValue is 98 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 extended 107 request [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. 128 2.5. 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 135 3.1. Extension Discovery 137 To allow clients to discover support for this extension, servers 138 implementing this specification SHOULD publish IANA-ASSIGNED-OID.1 and 139 IANA-ASSIGNED-OID.3 as values of the 'supportedExtension' attribute 140 [RFC4512] within the Root DSE, and publish the IANA-ASSIGNED-OID.2 as 141 a value of the 'supportedControl' attribute [RFC4512] of the Root DSE. 143 A server MAY choose to advertise this extension only when the client 144 is authorized to use it. 146 3.2. Starting an Transactions 148 A client wishing to preform a sequence of directory updates as an 149 transaction issues a Start Transaction Request. A server which is 150 willing and able to support transactions responds to this request with 151 a Start Transaction Response providing a transaction identifier and 152 with a resultCode of success. Otherwise, the server responds with a 153 Start Transaction Response wth a result code other than success 154 indicating the nature of the failure. 156 The transaction identifier provided upon successful start of a 157 transaction is used in subseqent protocol messages to identify this 158 transaction. 160 3.3. Specification of a Transaction 162 The client then may issue may issue one or more update requests, each 163 with a Transaction Specification control containing the transaction 164 identifier indicating the updates are to processed as part of the 165 transaction. Each of these update request MUST have a different 166 MessageId value. If the server is unwilling or unable to attempt to 167 process the requested update operation as part of the transaction, the 168 server immediately returns the approrpiate response to the request 169 with a resultCode indicating the nature of the failure. Otherwise, 170 the server immediately returns success and the defers further 171 processing of the operation is then deferred until settlement. 173 If the server becomes unwilling or unable to continue the 174 specification of a transaction, the server issues an Aborted 175 Transaction Notice with a non-success resultCode indicating the nature 176 of the failure. All operations that were to be processed as part of 177 the transaction are implicitly abandoned. Upon receipt of an Aborted 178 Transaction Notice, the client is to discontinue all use of the 179 transaction identifier as the transaction is null and void. Any 180 future use of identifier by the client will result in a response 181 containing a non-success resultCode. 183 3.4. Transaction Settlement 185 A client requests settlement of transaction by issuing an End 186 Transaction request for the transaction indicating whether it desires 187 the transaction to be committed or aborted. 189 Upon receipt of a request to abort the transaction, the server is to 190 abort the identified transaction (abandoning all operations which are 191 part of the transaction) and indicate that it has done so by returning 192 an End Transaction response with a resultCode of success. 194 Upon receipt of a request to commit the transaction, the server 195 processes all update operations of the transaction as one atomic, 196 durable, isolated, and consistent action with each requested update 197 being processed in turn. Either all of the requested updates are to 198 be successfully applied or none of the requested are to be applied. 199 The server returns an End Transaction Response with a resultCode of 200 success and no responseValue to indicate all the requested updates 201 were applied. Otherwise, the server returns an End Transaction with 202 an non-success resultCode indicating the nature of the failure. If 203 the failure is associated with a particular update request, a 204 responseValue containing its MessageID is returned. If the failure 205 was not associated with any particular update request, no 206 responseValue is returned. 208 There is no requirement that a server serialize transactions, or 209 updates requested outside of a transaction. That is, a server MAY 210 process multiple commit requests (from one or more clients) acting 211 upon different sets of entries concurrently. A server MUST avoid 212 deadlock. 214 4. Interaction with Update Operation Control Extensions 216 TBD 218 4.1. Assertion Control 220 4.2. ManageDsaIT Control 222 4.3. Modify Control 224 4.3. No-Op Control 226 4.4. Read Entry Controls 227 4.5. Relax Rules Control 229 5. Distributed Directory Considerations 231 The LDAP/X.500 models provide for distributed directory operations 232 including server-side chaining and client-side chasing of operations. 234 This document does not preclude servers from chaining operations which 235 are part of a transaction. However, if a server does attempt such 236 chaining, it MUST ensure that transaction semantics are provided. 238 This mechanism defined by this document does not support client-side 239 chasing. Grouping cookies used to identify the transaction are 240 specific to a particular client/server session. 242 The LDAP/X.500 models provide for a single-master/multiple-shadow 243 replication architecture. There is no requirement that changes made 244 to the directory based upon processing a transaction be replicated as 245 one atomic action. Hence, clients SHOULD NOT assume tight data 246 consistency nor fast data convergence of shadow servers unless they 247 have prior knowledge that such properties are provided. Though this 248 mechanism could be used to support replication, use in replication is 249 not described in this document. 251 6. Security Considerations 253 Transactions mechanisms may be the target of denial-of-service 254 attacks. Implementors should provide safeguards to ensure these 255 mechanisms are not abused. 257 General security considerations [RFC4510], especially associated with 258 update operations [RFC4511], apply to this extension. 260 7. IANA Considerations 262 It is requested that Internet Assigned Numbers Authority (IANA) make 263 the following assignments. 265 7.1. Object Identifier 267 Assignment of an LDAP Object Identifier [RFC4520] to identify the 268 protocol elements specified in this document this document is 269 requested. 271 Subject: Request for LDAP Object Identifier Registration 272 Person & email address to contact for further information: 273 Kurt Zeilenga 274 Specification: RFC XXXX 275 Author/Change Controller: IESG 276 Comments: Identifies protocol elements for LDAP Transactions 278 7.2. LDAP Protocol Mechanism 280 Registration of the protocol mechanisms [RFC4520] specified in this 281 document is requested. 283 Subject: Request for LDAP Protocol Mechanism Registration 284 Object Identifier: see table 285 Description: see table 286 Person & email address to contact for further information: 287 Kurt Zeilenga 288 Specification: RFC XXXX 289 Author/Change Controller: IESG 290 Comments: 292 Object Identifier Type Description 293 ------------------- ---- ----------------------------------------- 294 IANA-ASSIGNED-OID.1 E Start Transaction Extended Request 295 IANA-ASSIGNED-OID.2 C Transaction Specification Control 296 IANA-ASSIGNED-OID.3 E End Transaction Extended Request 298 8. Acknowledgments 300 The author gratefully acknowledges the contributions made by members 301 of the Internet Engineering Task Force. 303 9. Author's Address 305 Kurt D. Zeilenga 306 OpenLDAP Foundation 308 Email: Kurt@OpenLDAP.org 310 10. References 312 [[Note to the RFC Editor: please replace the citation tags used in 313 referencing Internet-Drafts with tags of the form RFCnnnn where 314 possible.]] 316 10.1. Normative References 318 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 319 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 321 [RFC4510] Zeilenga, K. (editor), "LDAP: Technical Specification 322 Road Map", RFC 4510, June 2006. 324 [RFC4511] Sermersheim, J. (editor), "LDAP: The Protocol", RFC 325 4511, June 2006. 327 [RFC4512] Zeilenga, K. (editor), "LDAP: Directory Information 328 Models", RFC 4512, June 2006. 330 [X.680] International Telecommunication Union - 331 Telecommunication Standardization Sector, "Abstract 332 Syntax Notation One (ASN.1) - Specification of Basic 333 Notation", X.680(2002) (also ISO/IEC 8824-1:2002). 335 [X.690] International Telecommunication Union - 336 Telecommunication Standardization Sector, "Specification 337 of ASN.1 encoding rules: Basic Encoding Rules (BER), 338 Canonical Encoding Rules (CER), and Distinguished 339 Encoding Rules (DER)", X.690(2002) (also ISO/IEC 340 8825-1:2002). 342 10.2. Informative References 344 [ACID] Section 4 of ISO/IEC 10026-1:1992. 346 [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority 347 (IANA) Considerations for the Lightweight Directory 348 Access Protocol (LDAP)", RFC 4520, BCP 64, June 2006. 350 [X.500] International Telecommunication Union - 351 Telecommunication Standardization Sector, "The Directory 352 -- Overview of concepts, models and services," 353 X.500(1993) (also ISO/IEC 9594-1:1994). 355 [X.501] International Telecommunication Union - 356 Telecommunication Standardization Sector, "The Directory 357 -- Models," X.501(1993) (also ISO/IEC 9594-2:1994). 359 Intellectual Property 360 The IETF takes no position regarding the validity or scope of any 361 Intellectual Property Rights or other rights that might be claimed to 362 pertain to the implementation or use of the technology described in 363 this document or the extent to which any license under such rights 364 might or might not be available; nor does it represent that it has 365 made any independent effort to identify any such rights. Information 366 on the procedures with respect to rights in RFC documents can be found 367 in BCP 78 and BCP 79. 369 Copies of IPR disclosures made to the IETF Secretariat and any 370 assurances of licenses to be made available, or the result of an 371 attempt made to obtain a general license or permission for the use of 372 such proprietary rights by implementers or users of this specification 373 can be obtained from the IETF on-line IPR repository at 374 http://www.ietf.org/ipr. 376 The IETF invites any interested party to bring to its attention any 377 copyrights, patents or patent applications, or other proprietary 378 rights that may cover technology that may be required to implement 379 this standard. Please address the information to the IETF at 380 ietf-ipr@ietf.org. 382 Full Copyright 384 Copyright (C) The Internet Society (2006). 386 This document is subject to the rights, licenses and restrictions 387 contained in BCP 78, and except as set forth therein, the authors 388 retain all their rights. 390 This document and the information contained herein are provided on an 391 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 392 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 393 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 394 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 395 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 396 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.