idnits 2.17.1 draft-zeilenga-ldap-txn-07.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 385. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 356. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 363. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 369. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 373), 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 (5 March 2006) is 6624 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) -- No information found for draft-ietf-ldapbis-roadmap-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Roadmap' -- No information found for draft-ietf-ldapbis-protocol-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Protocol' -- No information found for draft-ietf-ldapbis-models-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Models' -- No information found for draft-ietf-ldapbis-bcp64-xx - is the name correct? Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 14 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 5 March 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 and information 52 replication. This document defines an LDAP extension to support 53 transactions. 55 1. Overview 57 This document extends the Lightweight Directory Access Protocol (LDAP) 58 [Roadmap] to allow clients to group a number of related update 59 operations [Protocol] and have them preformed as one unit of 60 interaction, a transaction. As with distinct update operations, each 61 transaction has atomic, consistency, isolation, and durability 62 ([ACID]) properties. 64 This extension consists of two extended operations, one control, and 65 one unsolicited notification message. The Start Transaction operation 66 is used to obtain a transaction identifier. This identifier is then 67 attached to multiple update operations to indicate that they belong to 68 transaction using the Transaction Specification control. The End 69 Transaction is used to settle (commit or abort) the transaction. The 70 Aborted Tranaction Notice is used notify the client the server is no 71 longer willing or able to process an 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.2 of [Protocol]. 84 DSA stands for "Directory System Agent" (a server). DSE stands for 85 "DSA-specific entry". 87 2. Elements of an LDAP Transaction 89 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 requests [Protocol]. 108 2.3. End Transactions Request and Response 110 An End Transaction Request is an LDAPMessage of CHOICE extendedReq 111 where the requestName is IANA-ASSIGNED-OID.3 and the requestValue is 112 present and contains a BER-encoded settlementValue. 114 settlementValue ::= SEQUENCE { 115 commit BOOLEAN DEFAULT TRUE, 116 identifier OCTET STRING } 118 A commit value of TRUE indicates a request to commit the transaction 119 identified by the identifier. A commit value of FALSE indicates a 120 request to abort the identified transaction. 122 An End Transaction Response is an LDAPMessage sent in response to a 123 End Transaction Request. Its response name is absent. The 124 responseValue when present contains a BER-encoded MessageID. 126 2.5. Aborted Transaction Notice 128 The Aborted Transaction Notice is an Unsolicited Notification message 129 where the responseName is IANA-ASSIGNED-OID.4 and responseValue is 130 present and contains a transaction identifier. 132 3. An LDAP Transaction 134 3.1. Extension Discovery 135 To allow clients to discover support for this extension, servers 136 implementing this specification SHOULD publish IANA-ASSIGNED-OID.1 and 137 IANA-ASSIGNED-OID.3 as values of the 'supportedExtension' attribute 138 [Models] within the Root DSE, and publish the IANA-ASSIGNED-OID.2 as a 139 value of the 'supportedControl' attribute [Models] of the Root DSE. 141 A server MAY choose to advertise this extension only when the client 142 is authorized to use it. 144 3.2. Starting an Transactions 146 A client wishing to preform a sequence of directory updates as an 147 transaction issues a Start Transaction Request. A server which is 148 willing and able to support transactions responds to this request with 149 a Start Transaction Response providing a transaction identifier and 150 with a resultCode of success. Otherwise, the server responds with a 151 Start Transaction Response wth a result code other than success 152 indicating the nature of the failure. 154 The transaction identifier provided upon successful start of a 155 transaction is used in subseqent protocol messages to identify this 156 transaction. 158 3.3. Specification of a Transaction 160 The client then may issue may issue one or more update (add, delete, 161 modify, modifyDN) requests, each with a Transaction Specification 162 control containing the transaction identifier indicating the updates 163 are to processed as part of the transaction. Each of these update 164 request MUST have a different MessageId value. If the server is 165 unwilling or unable to attempt to process the requested update 166 operation as part of the transaction, the server immediately returns 167 the approrpiate response to the request with a resultCode indicating 168 the nature of the failure. Otherwise, the server immediately returns 169 success and the defers further processing of the operation is then 170 deferred until settlement. 172 If the server becomes unwilling or unable to continue the 173 specification of a transaction, the server issues an Aborted 174 Transaction Notice with a non-success resultCode indicating the nature 175 of the failure. All operations that were to be processed as part of 176 the transaction are implicitly abandoned. Upon receipt of an Aborted 177 Transaction Notice, the client is to discontinue all use of the 178 transaction identifier as the transaction is null and void. Any 179 future use of identifier by the client will result in a response 180 containing a non-success resultCode. 182 3.4. Transaction Settlement 184 A client requests settlement of transaction by issuing an End 185 Transaction request for the transaction indicating whether it desires 186 the transaction to be committed or aborted. 188 Upon receipt of a request to abort the transaction, the server is to 189 abort the identified transaction (abandoning all operations which are 190 part of the transaction) and indicate that it has done so by returning 191 an End Transaction response with a resultCode of success. 193 Upon receipt of a request to commit the transaction, the server 194 processes all update operations of the transaction as one atomic, 195 isolated action with each requested update being processed in turn. 196 Either all of the requested updates are to be successfully applied or 197 none of the requested are to be applied. The server returns an End 198 Transaction Response with a resultCode of success and no responseValue 199 to indicate all the requested updates were applied. Otherwise, the 200 server returns an End Transaction with an non-success resultCode 201 indicating the nature of the failure. If the failure is associated 202 with a particular update request, a responseValue containing its 203 MessageID is returned. If the failure was not associated with any 204 particular update request, no responseValue is returned. 206 There is no requirement that a server serialize transactions, or 207 updates requested outside of a transaction. That is, a server MAY 208 process multiple commit requests (from one or more clients) acting 209 upon different sets of entries concurrently. A server MUST avoid 210 deadlock. 212 4. Distributed Directory Considerations 214 The LDAP/X.500 models provide for distributed directory operations 215 including server-side chaining and client-side chasing of operations. 217 This document does not preclude servers from chaining operations which 218 are part of a transaction. However, if a server does allow such 219 chaining, it MUST ensure that transaction semantics are provided. 221 This mechanism defined by this document does not support client-side 222 chasing. Grouping cookies used to identify the transaction are 223 specific to a particular client/server session. 225 The LDAP/X.500 models provide for a single-master/multiple-shadow 226 replication architecture. This document states no requirement that 227 changes made to the directory based upon processing a transaction be 228 replicated as one atomic action. That is, the client SHOULD NOT 229 assume tight data consistency nor fast data convergence at shadow 230 servers unless they have prior knowledge that such service is 231 provided. Though this mechanism could be used to support replication, 232 use in replication is not described in this document. 234 The LDAP/X.500 models do not currently support a multi-master 235 replication architecture and, hence, not considered by this 236 specification. 238 5. Security Considerations 240 Transactions mechanisms may be the target of denial of service 241 attacks. Implementors should provide safeguards to ensure these 242 mechanisms are not abused. 244 General security considerations [Roadmap], especially associated with 245 update operations [Protocol], apply to this extension. 247 6. IANA Considerations 249 In accordance with [BCP64bis], it is requested that Internet Assigned 250 Numbers Authority (IANA) make the following assignments. 252 6.1. Object Identifier 254 Assignment of an LDAP Object Identifier to identify the protocol 255 elements specified in this document this document is requested. 257 Subject: Request for LDAP Object Identifier Registration 258 Person & email address to contact for further information: 259 Kurt Zeilenga 260 Specification: RFC XXXX 261 Author/Change Controller: IESG 262 Comments: Identifies protocol elements for LDAP Transactions 264 6.2. LDAP Protocol Mechanism 266 Registration of the protocol mechanisms specified in this document is 267 requested. 269 Subject: Request for LDAP Protocol Mechanism Registration 270 Object Identifier: see table 271 Description: see table 272 Person & email address to contact for further information: 274 Kurt Zeilenga 275 Specification: RFC XXXX 276 Author/Change Controller: IESG 277 Comments: 279 Object Identifier Type Description 280 ------------------- ---- ----------------------------------------- 281 IANA-ASSIGNED-OID.1 E Start Transaction Extended Request 282 IANA-ASSIGNED-OID.2 C Transaction Specification Control 283 IANA-ASSIGNED-OID.3 E End Transaction Extended Request 285 7. Acknowledgments 287 The author gratefully acknowledges the contributions made by members 288 of the Internet Engineering Task Force. 290 8. Author's Address 292 Kurt D. Zeilenga 293 OpenLDAP Foundation 295 Email: Kurt@OpenLDAP.org 297 9. References 299 [[Note to the RFC Editor: please replace the citation tags used in 300 referencing Internet-Drafts with tags of the form RFCnnnn where 301 possible.]] 303 9.1. Normative References 305 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 306 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 308 [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification 309 Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in 310 progress. 312 [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", 313 draft-ietf-ldapbis-protocol-xx.txt, a work in progress. 315 [Models] Zeilenga, K. (editor), "LDAP: Directory Information 316 Models", draft-ietf-ldapbis-models-xx.txt, a work in 317 progress. 319 [X.680] International Telecommunication Union - 320 Telecommunication Standardization Sector, "Abstract 321 Syntax Notation One (ASN.1) - Specification of Basic 322 Notation", X.680(2002) (also ISO/IEC 8824-1:2002). 324 [X.690] International Telecommunication Union - 325 Telecommunication Standardization Sector, "Specification 326 of ASN.1 encoding rules: Basic Encoding Rules (BER), 327 Canonical Encoding Rules (CER), and Distinguished 328 Encoding Rules (DER)", X.690(2002) (also ISO/IEC 329 8825-1:2002). 331 9.2. Informative References 333 [ACID] Section 4 of ISO/IEC 10026-1:1992. 335 [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP", 336 draft-ietf-ldapbis-bcp64-xx.txt, a work in progress. 338 [X.500] International Telecommunication Union - 339 Telecommunication Standardization Sector, "The Directory 340 -- Overview of concepts, models and services," 341 X.500(1993) (also ISO/IEC 9594-1:1994). 343 [X.501] International Telecommunication Union - 344 Telecommunication Standardization Sector, "The Directory 345 -- Models," X.501(1993) (also ISO/IEC 9594-2:1994). 347 Intellectual Property Rights 349 The IETF takes no position regarding the validity or scope of any 350 Intellectual Property Rights or other rights that might be claimed to 351 pertain to the implementation or use of the technology described in 352 this document or the extent to which any license under such rights 353 might or might not be available; nor does it represent that it has 354 made any independent effort to identify any such rights. Information 355 on the procedures with respect to rights in RFC documents can be found 356 in BCP 78 and BCP 79. 358 Copies of IPR disclosures made to the IETF Secretariat and any 359 assurances of licenses to be made available, or the result of an 360 attempt made to obtain a general license or permission for the use of 361 such proprietary rights by implementers or users of this specification 362 can be obtained from the IETF on-line IPR repository at 363 http://www.ietf.org/ipr. 365 The IETF invites any interested party to bring to its attention any 366 copyrights, patents or patent applications, or other proprietary 367 rights that may cover technology that may be required to implement 368 this standard. Please address the information to the IETF at 369 ietf-ipr@ietf.org. 371 Full Copyright 373 Copyright (C) The Internet Society (2006). 375 This document is subject to the rights, licenses and restrictions 376 contained in BCP 78, and except as set forth therein, the authors 377 retain all their rights. 379 This document and the information contained herein are provided on an 380 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 381 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 382 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 383 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 384 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 385 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.