RE: draft-ietf-ldapext-ldapv3-txn-00.txt

[Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>]

Some comments on the draft.

It is not clear how:
a) That opening a transaction can "reserve" resources that may be
deleted or renamed through the course of the transaction. Items in the
DIB will get modified by a transaction (hence the need for a
transaction), but during this process other users may delete or name
modify the same resources. Eg the Transaction says modify BILL to FRED
and then Modify FRED to JIM. At the same time another User has deleted
BILL or renamed it to JACK.

b) That reading an entry within a transaction to update its attribute
value, when other users can change the value during the process, can be
dealt with.


The fundamental issues with transactions is not the fact we can bound
operations within the transaction construct, the major effort is to
design mechanisms that lock resources within a system to ensure the
transaction is atomic regardless of other users trying to get at those
resources.

In a multi threaded machine which is needed for directory services this
resource locking could be a problem.
The draft does describe that all "transacted" operations occur at once -
but at once in a real system can be extended because of the client
timing issues - ie may be minutes.
During this time higher powered clients may have got their modifications
completed so that the lower priority transaction then fails.
Perhaps the use of object oriented design in directory systems as named
objects has in fact already defined the smallest form of atomicity.
Extending this will cause yet more service consistency issues.


Server Operation State -Recording
Applying transactions to directory operations means that the server must
rember state. If Searches are applied to transactions to determine
should an update is performed. 
eg.
Search Subtree FOO-Co for Org Persons where title is manager and salary
greater than 250k- Then rename entries to FOO-Co, HighPaidManagers,
name..
What happens if the Search is an LDAP  persistent search within a
transaction - waiting for a salary change to occur, this means that
resource locking is not practicable.


System Design....
Although the draft states its for a single server (ie. not distributed
interconnected servers), the intent IMHO of directory services is to
deal with the wider distriuted environment.
eg LDAP transactions into an X.500 directory system of interconnected
servers - will be an issue. 

So either this LDAP feature MUST only be applied to a single LDAP
server. OR any LDAP User accessing a distributed LDAP server/X.500 world
will be denied the service. This seems to defeat the purpose of the LDAP
standard to be a uniform access method!???

I would like to see that any extension to LDAP eg. results sorting,
persistent searches and transaction mode operations is dealt with in
terms of their collective use over one server and their use with many
referred servers is discussed. It seems that in the LDAP client to
SINGLE server world, protocol extensions can be easily applied to a
point where the LDAP client is built in conjunction with a specific LDAP
server. But in the operational world the client (and the User) now needs
to be aware of these extensions, whose server they are directed at, and
what happens should mid "transaction" referrals are returned and what to
do if the extensions (eg.transactions) work on one server and not on
others. ie we now have a service consistency issue which does make
client software complex and no doubt problematic.



My point is as always - its easy to write draft protocol specs between a
client and a single server and call that a standard. Its not so easy to
get compatible services or distributed services working to the point
where the user has a seamless and consistent services delivered by N
servers from many suppliers . So is it possible, that before we write
yet more extensions to the LDAP protocol - can we write down under what
circumstances a User will use them, how these "transactions are
constructed" from a User perspective and how that user knows which
server to direct them at and what happens if referrals are received
during the transaction.

just thoughts

regards alan.

The more extensions that are designe for single server operations - the
worse this issue will become.

> -----Original Message-----
> From:	dboreham@netscape.com [SMTP:dboreham@netscape.com]
> Sent:	Tuesday, April 14, 1998 11:38 AM
> To:	ietf-ldapext@netscape.com
> Subject:	draft-ietf-ldapext-ldapv3-txn-00.txt
> 
> Further to the brief discussion about transactions in LDAP 
> at the LA meeting, here is a draft which builds on work done 
> at Hitachi and Netscape over the past year. 
> I'm not posting this to the IETF repository because we feel 
> that it's not quite ready, but that the time is now right to 
> present the work to the list and open up a discussion. 
>   
>   << File: draft-ietf-ldapext-ldapv3-txn-00.txt >>