idnits 2.17.1 draft-spacek-ldapext-syncrepl-transaction-01.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 (November 18, 2015) is 3083 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 November 18, 2015 5 Expires: May 21, 2016 7 The Lightweight Directory Access Protocol (LDAP) Content Synchronization 8 Operation with Transactions 9 draft-spacek-ldapext-syncrepl-transaction-01 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 May 21, 2016. 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 . . . . . . . . . . . . . . . . . . . . . 4 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 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 114 absent. 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 TODO: THIS SHOULD BE CLARIFIED BY FURTHER UPDATES TO TRANSACTION RFCs 133 Please note that [RFC5805] defined that LDAP Transactions have 134 atomic, consistency, isolation, durability (ACID) properties without 135 further specification of the "isolation" level. This extension 136 assumes that an isolation property guarantees that uncommited changes 137 are generaly not visible to LDAP clients and thus not returned in the 138 Content Synchronization Operation results. 140 4.1. Refresh stage 142 The refresh stage of the Content Synchronization Operation is 143 unaffected by Transaction Notification Control. The control affects 144 neither Content Determination nor protocol messages sent during the 145 refresh stage. 147 Transaction-aware clients MUST treat the refresh stage as a single 148 transaction. Messages that mark end of the refresh stage are defined 149 in [RFC4533]. 151 4.2. Persist stage 153 Existing protocol messages and semantics defined by [RFC4533] are not 154 changed. The protocol flow in the persist stage is extended only 155 with Start and End Transaction Notification Messages. 157 A Start Transaction Notification Message MUST be sent to a client 158 when a transaction is successfully commited but before any of the 159 changes contained in the transaction are sent to the client. 161 The Start Transaction Notification Message MUST be followed by all 162 Change notification messages as defined in the persist stage of 163 [RFC4533]. A server MUST NOT interleave changes made in multiple 164 transactions to ensure that Start and End messages unambiguously 165 identify one transaction. 167 An End Transaction Notification Message MUST be sent immediatelly 168 after all Change notifications for given transaction were sent to the 169 client. This message signalizes to the client that the transaction 170 marked by the Start Transaction Notification Message is complete and 171 all changes can be commited. 173 5. IANA Considerations 175 TBD 177 6. Security Considerations 179 This document merely adds information about transaction boundaries to 180 the existing Content Synchronization Operation. This is believed not 181 to add any security risk. 183 7. Normative References 185 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 186 Requirement Levels", BCP 14, RFC 2119, March 1997. 188 [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol 189 (LDAP): The Protocol", RFC 4511, June 2006. 191 [RFC4533] Zeilenga, K. and J. Choi, "The Lightweight Directory 192 Access Protocol (LDAP) Content Synchronization Operation", 193 RFC 4533, June 2006. 195 [RFC5805] Zeilenga, K., "Lightweight Directory Access Protocol 196 (LDAP) Transactions", RFC 5805, March 2010. 198 Author's Address 200 Petr Spacek 201 Red Hat, Inc. 203 Email: pspacek@redhat.com