Lightweight Directory Access Protocol (LDAP) Transactions
RFC 5805

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: RFC Editor <rfc-editor@rfc-editor.org>
Cc: The IESG <iesg@ietf.org>, <iana@iana.org>, ietf-announce@ietf.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.