Lightweight Directory Access Protocol (LDAP) Transactions
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: RFC Editor <email@example.com> Cc: The IESG <firstname.lastname@example.org>, <email@example.com>, firstname.lastname@example.org Subject: Re: Experimental RFC to be: draft-zeilenga-ldap-txn-15.txt The IESG has no problem with the publication of 'LDAP Transactions' <draft-zeilenga-ldap-txn-15.txt> as an Experimental RFC. The IESG would also like the IRSG or RFC-Editor to review the comments in the datatracker (https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=5845&rfc_flag=0) related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the comment log. The IESG contact person is Alexey Melnikov. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-txn-15.txt The process for such documents is described at http://www.rfc-editor.org/indsubs.html. Thank you, The IESG Secretary
Technical Summary Lightweight Directory Access Protocol (LDAP) update operations, such as Add, Delete, and Modify operations, have atomic, consistency, isolation, durability (ACID) properties. Each of these update operations act upon an entry. It is often desirable to update two or more entries in a single unit of interaction, a transaction. Transactions are necessary to support a number of applications including resource provisioning. This document extends LDAP to support transactions. Working Group Summary This document is not the result of any IETF Working Group, it is an independent submission to the RFC Editor. Document Quality Alexey Melnikov has reviewed this specification for conformance with the RFC 4520 requirements for allocation of new LDAP protocol mechanisms (FCFS policy), and for RFC 3932 requirements for conflict with IETF work or processes. Personnel Alexey Melnikov is the Responsible Area Director. RFC Editor Note The IESG believes that this work doesn't conflict with any work done in IETF, so it has no note to insert into this document, and no objection to its publication.