idnits 2.17.1 draft-spacek-ldapext-syncrepl-transaction-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year -- The document date (June 29, 2015) is 3223 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) ** Downref: Normative reference to an Experimental RFC: RFC 4533 ** Downref: Normative reference to an Experimental RFC: RFC 5805 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Spacek 3 Internet-Draft Red Hat, Inc. 4 Intended status: Standards Track June 29, 2015 5 Expires: December 31, 2015 7 The Lightweight Directory Access Protocol (LDAP) Content Synchronization 8 Operation with Transactions 9 draft-spacek-ldapext-syncrepl-transaction-00 11 Abstract 13 This document specifies LDAP Control which extends the persist stage 14 of the Content Synchronization Operation with information about LDAP 15 transaction boundaries. This information can be used to support 16 application-level transactions or for application-level 17 optimizations. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 31, 2015. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Document Conventions . . . . . . . . . . . . . . . . . . . . 3 55 3. Elements of the LDAP Content Synchronization with 56 Transactions . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.1. Transaction Notification Control . . . . . . . . . . . . 3 58 3.2. Start Transaction Notification Message . . . . . . . . . 3 59 3.3. End Transaction Notification Message . . . . . . . . . . 3 60 4. Interaction with the Content Synchronization Operation . . . 3 61 4.1. Refresh stage . . . . . . . . . . . . . . . . . . . . . . 4 62 4.2. Persist stage . . . . . . . . . . . . . . . . . . . . . . 4 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 68 1. Introduction 70 The LDAP Content Synchronization Operation [RFC4533] and LDAP 71 Transactions [RFC5805] are not integrated, which makes the Content 72 Synchronization Operation less useful. 74 The client using the Content Synchronization Operation has no 75 information of which changes were part of a single transaction. As a 76 result, the client cannot replicate transaction semantics reliably, 77 especially when a connection to an LDAP server is interrupted in the 78 middle of the persist stage of the Content Synchronization Operation. 80 Some clients could use the information where an LDAP transaction 81 started and ended for transactions at application level to guarantee 82 consistency of application data. Altenatively, some applications can 83 use transaction boundaries for optimizations when further processing 84 of the data is triggered by the end of a transaction. This might 85 allow the application to save some overhead by processing changes in 86 groups. 88 2. Document Conventions 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 Term "transaction identifier" has the same definition as in 95 [RFC5805]. 97 3. Elements of the LDAP Content Synchronization with Transactions 99 Existing protocol messages and semantics defined by [RFC4533] are not 100 changed. The protocol flow is only extended with Transaction 101 Notification Control, Start, and End Transaction Notification 102 Messages. 104 3.1. Transaction Notification Control 106 The Transaction Notification Control is an LDAPControl [RFC4511] 107 where the controlType is "TBD1" and the controlValue is absent. The 108 criticality may be TRUE or FALSE. 110 3.2. Start Transaction Notification Message 112 The Start Transaction Notification message is an IntermediateResponse 113 [RFC4511] where the responseName is "TBD2" and the responseValue is a 114 transaction identifier as defined in [RFC5805]. 116 3.3. End Transaction Notification Message 118 The End Transaction Notification message is an IntermediateResponse 119 [RFC4511] where the responseName is "TBD3" and the responseValue is 120 absent. 122 4. Interaction with the Content Synchronization Operation 124 The client requests information about LDAP Transaction to be added to 125 the Content Synchronization Operation by sending Transaction 126 Notification Control along with a SearchRequest Message that contains 127 a Sync Request Control [RFC4533]. All attempts to use Transaction 128 Notification Control without Sync Request Control MUST be denied with 129 the unwillingToPerform [RFC4511] result code. 131 Please note that [RFC5805] defined that LDAP Transactions have 132 atomic, consistency, isolation, durability (ACID) properties without 133 further specification of the "isolation" level. This extension 134 assumes that an isolation property guarantees that uncommited changes 135 are generaly not visible to LDAP clients and thus not returned in the 136 Content Synchronization Operation results. 138 4.1. Refresh stage 140 The refresh stage of the Content Synchronization Operation is 141 unaffected by Transaction Notification Control. The control affects 142 neither Content Determination nor protocol messages sent during the 143 refresh stage. 145 Transaction-aware clients MUST treat the refresh stage as a single 146 transaction. Messages that mark end of the refresh stage are defined 147 in [RFC4533]. 149 4.2. Persist stage 151 Existing protocol messages and semantics defined by [RFC4533] are not 152 changed. The protocol flow in the persist stage is extended only 153 with Start and End Transaction Notification Messages. 155 A Start Transaction Notification Message MUST be sent to a client 156 when a transaction is successfully commited but before any of the 157 changes contained in the transaction are sent to the client. The 158 message MUST contain transaction identifier which was used to 159 identify the transaction in the protocol exchange with the client 160 that did modifications to the data as defined in [RFC5805]. 162 TODO: Is it a good idea? Should we rather define an Ignore-own- 163 writes control? 165 The transaction identifier allows the client to distinguish its own 166 transactions from other's transactions done on the same server and to 167 optimize the client's behavior. [RFC5805] section 5 defines 168 transaction identifiers as specific to a particular LDAP association, 169 so clients have to take into account that a transaction identifier 170 will not match if changes are done on a different server than the 171 Content Synchronization Operation. 173 The Start Transaction Notification Message MUST be followed by all 174 Change notification messages as defined in the persist stage of 175 [RFC4533]. A server MUST NOT interleave changes made in multiple 176 transactions to ensure that Start and End messages unambiguously 177 identify one transaction. 179 An End Transaction Notification Message MUST be sent right after all 180 Change notifications for given transaction were sent to the client. 181 This message signalizes to the client that the transaction marked by 182 the Start Transaction Notification Message is complete and all 183 changes can be commited. 185 5. IANA Considerations 187 TBD 189 6. Security Considerations 191 This document merely adds information about transaction boundaries to 192 the existing Content Synchronization Operation. The only potential 193 information leak is a transaction identifier returned in a Start 194 Transaction Notification Message. This is believed not to add any 195 security risk. 197 7. Normative References 199 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 200 Requirement Levels", BCP 14, RFC 2119, March 1997. 202 [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol 203 (LDAP): The Protocol", RFC 4511, June 2006. 205 [RFC4533] Zeilenga, K. and J. Choi, "The Lightweight Directory 206 Access Protocol (LDAP) Content Synchronization Operation", 207 RFC 4533, June 2006. 209 [RFC5805] Zeilenga, K., "Lightweight Directory Access Protocol 210 (LDAP) Transactions", RFC 5805, March 2010. 212 Author's Address 214 Petr Spacek 215 Red Hat, Inc. 217 Email: pspacek@redhat.com