idnits 2.17.1 draft-zeilenga-ldap-txn-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2119], [RFC2251]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 243 has weird spacing: '...for the purpo...' == 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 (16 June 2002) is 7985 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'LDAPIANA' is defined on line 204, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) -- No information found for draft-ietf-ldapbis-iana-xx - is the name correct? == Outdated reference: A later version (-01) exists of draft-ietf-ldapbis-ldapv3-ts-00 -- No information found for draft-zeilenga-ldap-grouping-xx - is the name correct? Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Kurt D. Zeilenga 3 Intended Category: Experimental OpenLDAP Foundation 4 Expires in six months 16 June 2002 6 LDAPv3 Transactions 7 9 Status of Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 This document is intended to be, after appropriate review and 15 revision, submitted to the RFC Editor as an Experimental document. 16 Distribution of this memo is unlimited. Technical discussion of this 17 document will take place on the IETF LDAP Extension Working Group 18 mailing list . Please send editorial 19 comments directly to the author . 21 Internet-Drafts are working documents of the Internet Engineering Task 22 Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as ``work in progress.'' 29 The list of current Internet-Drafts can be accessed at 30 . The list of 31 Internet-Draft Shadow Directories can be accessed at 32 . 34 Copyright 2002, The Internet Society. All Rights Reserved. 36 Please see the Copyright section near the end of this document for 37 more information. 39 Abstract 41 Lightweight Directory Access Protocol (LDAP) update operations have 42 atomic properties upon individual entries. However, it is often 43 desirable to update two or more entries as one atomic action, a 44 transaction. Transactions are necessary to support a number of 45 applications including resource provisioning and information 46 replication. This document defines an LDAP extension to support 47 transactions. 49 Conventions 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in BCP 14 [RFC2119]. 55 Protocol elements are described using ASN.1 [X.680]. The term 56 "BER-encoded" means the element is to be encoded using the Basic 57 Encoding Rules [X.690] under the restrictions detailed in Section 5.1 58 of [RFC2251]. 60 1. Overview 62 This document extends LDAP [LDAPTS] to allow clients to group a number 63 of related update operations and have them preformed as one atomic 64 action, a transaction. The mechanism uses the grouping mechanism 65 provided by [GROUP] to relate operations of the transaction. The 66 createGrouping operation is used to obtain a group cookie which is 67 used to identify operations which are apart of the transaction. The 68 group cookie can be viewed as a transaction identifier. The 69 endGrouping operation is used to settle (commit or abort) the 70 transaction. 72 This specification will likely be significantly enhanced before it 73 progressed. In particular, clarification of transaction semantics and 74 better error handling will likely be added. A ''prepare'' capability 75 may also be added. 77 Editor's Note: 78 The object identifiers appearing in this draft are fictious. The 79 top-level OID 1.1 is be replaced before this draft is published as 80 an RFC. 82 2. Specification of a Transaction 84 Servers implementing this specification SHOULD publish the 85 transactionGroupingType as a value of the supportedGroupingTypes 86 attribute contained within the Root DSE. 88 transactionGroupingType ::= 1.1.1 ;; fictious 90 A client wishing to preform a transaction MUST issue a 91 createGroupingRequest with a createGroupType of 92 transactionGroupingType and no createGroupValue. A server which is 93 willing and able to support transactions SHALL return a 94 createGroupingResponse with a success result code, a 95 createGroupCookie, and no createGroupValue. Otherwise the server 96 SHALL return a non-success result code, no createGroupCookie, and no 97 createGroupValue. 99 The client MAY then attach a GroupingControl to subsequent update 100 operations (modify or moddn) to indicate that they are to be processed 101 as part of the transaction per [GROUP], Section 3.5. If the server is 102 willing and able to attempt to process operation as part of the 103 transaction, the server SHALL return success. If the server is 104 unwilling or unable to attempt to process the operation as part of the 105 transaction, the server SHALL return a non-successful result code. 107 If the server becomes unwilling or unable to continue the 108 specification of a transaction, the server SHOULD issue a 109 endGroupNotice. Any future use of cookie by the client SHALL result 110 in a response containing a non-success result code. 112 Upon receipt of a endGroupingNotice, the client SHOULD discontinue all 113 use of the grouping cookie. The client SHOULD NOT issue an 114 endGroupingRequest for the grouping cookie as the transaction is null 115 and void. 117 A client requests settling of transaction by issuing an 118 endGroupingRequest where the groupingCookie is the group cookie 119 identify the transaction. The absence of any endGroupingValue 120 indicates a commit request. The presence of an empty endGroupValue 121 indicates an abort request. The endGroupValue MUST be empty if 122 provided. 124 The endGroupingResponse of success indicates the settle action was 125 successfully. No endGroupingValue is provided with the 126 endGroupingResponse. 128 3. Transaction Semantics 130 Upon request to commit the transaction, the server perform the 131 operations as one atomic action. Operations belonging to the 132 transaction are applied in the request order. If any operation fails, 133 the contents of target objects is left unchanged and a non-success 134 result code is returned indicating the nature of the failure. 136 There is no requirement that a server serialize transactions. That 137 is, a server MAY process multiple transactions commit requests (from 138 one or more clients) acting upon different sets of entries 139 concurrently. A server MUST ensure concurrent processing of 140 transactions provides the atomic properties described above. A server 141 MUST avoid deadlock. 143 4. Distributed Directory Considerations 145 The LDAP/X.500 models provide for distributed directory operations 146 including server-side chaining and client-side chasing of operations. 148 This document does not disallow servers from chaining operations which 149 are part of a transaction. However, if a server does allow such 150 chaining, it MUST ensure that transaction semantics detailed above are 151 provided. 153 This mechanism defined by this document does not support client-side 154 chasing. Grouping cookies used to identify the transaction are 155 specific to a particular client/server session. 157 The LDAP/X.500 models provide for a single-master/multiple-slave 158 replication architecture. This document states no requirement that 159 changes made to the directory based upon processing a transaction be 160 replicated as one atomic action. That is, the client SHOULD NOT 161 assume tight data consistency nor fast data convergence at slave 162 servers unless they have a priori knowledge that such is provided. 163 Though this mechanism could be used to support replication, such use 164 is not described in this document. 166 The LDAP/X.500 models do not currently support a multi-master 167 replication architecture and, hence, not considered by this 168 specification. 170 5. Security Considerations 172 Transactions mechanisms and related grouping operations may be the 173 target of denial of service attacks. Implementors should provide 174 safeguards to ensure these mechanisms are not abused. 176 6. IANA Considerations 178 No IANA assignments are required. 180 The OID was assigned [ASSIGN] by OpenLDAP Foundation under its 181 IANA assigned private enterprise allocation [PRIVATE] for use in this 182 specification. 184 7. Acknowledgments 186 The author gratefully acknowledges the contributions made by members 187 of the Internet Engineering Task Force. 189 8. Author's Address 191 The author may be contacted as follows: 192 Kurt D. Zeilenga 193 OpenLDAP Foundation 194 196 9. Normative References 198 [RFC2119] S. Bradner, "Key Words for use in RFCs to Indicate 199 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 201 [RFC2251] M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access 202 Protocol (v3)", RFC 2251, December 1997. 204 [LDAPIANA] K. Zeilenga, "IANA Considerations for LDAP", 205 draft-ietf-ldapbis-iana-xx.txt, a work in progress. 207 [LDAPTS] J. Hodges, R. Morgan, "Lightweight Directory Access 208 Protocol (v3): Technical Specification", 209 draft-ietf-ldapbis-ldapv3-ts-00.txt. 211 [GROUP] K. Zeilenga, "LDAPv3: Grouping of Related Operations", 212 draft-zeilenga-ldap-grouping-xx.txt, a work in progress. 214 [X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) - Specification 215 of Basic Notation", X.680, 1994. 217 [X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic, 218 Canonical, and Distinguished Encoding Rules", X.690, 1994. 220 10. Informative References 222 [X.500] ITU-T, "The Directory: Overview of Concepts, Models, and 223 Services", X.500, 1993. 225 [X.501] ITU-T, "The Directory: Models", X.501, 1993. 227 [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations", 228 http://www.openldap.org/foundation/oid-delegate.txt. 230 [PRIVATE] IANA, "Private Enterprise Numbers", 231 http://www.iana.org/assignments/enterprise-numbers. 233 Copyright 2002, The Internet Society. All Rights Reserved. 235 This document and translations of it may be copied and furnished 236 to others, and derivative works that comment on or otherwise explain 237 it or assist in its implementation may be prepared, copied, published 238 and distributed, in whole or in part, without restriction of any 239 kind, provided that the above copyright notice and this paragraph 240 are included on all such copies and derivative works. However, 241 this document itself may not be modified in any way, such as by 242 removing the copyright notice or references to the Internet Society 243 or other Internet organizations, except as needed for the purpose 244 of developing Internet standards in which case the procedures for 245 copyrights defined in the Internet Standards process must be 246 followed, or as required to translate it into languages other than 247 English. 249 The limited permissions granted above are perpetual and will not 250 be revoked by the Internet Society or its successors or assigns. 252 This document and the information contained herein is provided on 253 an "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE 254 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS 255 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 256 OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 257 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 258 PURPOSE.