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

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

> -----Original Message-----
> From:	dboreham@netscape.com [SMTP:dboreham@netscape.com]
> Sent:	Wednesday, April 15, 1998 1:25 AM
> To:	Alan Lloyd
> Cc:	ietf-ldapext@netscape.com
> Subject:	Re: draft-ietf-ldapext-ldapv3-txn-00.txt
> 
> Alan Lloyd wrote:
> 
> >         The section on Isolation (6.) does not say explicitly that
> > resources are locked or not. My comments say that is impossible to
> > lock
> > resources because of threading and persistence searches and what can
> > stop major deadlocks, but on the other hand resource locking is
> needed
> >
> > because of my examples mentioned eg Renames. It seems a dilemma to
> say
> >
> > the least.
> >
> >         I did work on multi nodal mainframe systems where resource
> > locking was fundamental, but as a fall back we had a deadlock watch
> > dog
> > arrangement which would knock of "hogging or stalled" applications.
> > Such
> > features in a directory service could again leave Users in a quandry
> > as
> > to what state the DIB would be left in if the watchdog fired.
> >
> >         The point here is that the protocol design is easy for the
> > "transaction"- but not having a resource locking process/mechanism
> or
> > philosophy for determining for dealing with it or what constitutes
> an
> > unfriendly transaction that should be dumped - will lead to
> > irregulaties
> > in the service - to say the least.
> >
> >         It will be dangerous to say that "during a transaction all
> > resources will be locked" and that the transaction could contain a
> > persisten search (for example) which relies on another User or
> another
> >
> > transation to trigger the completion of the initial transaction.
> 
> I see. Here we are in complete agreement. I suspect that
> thoughts in the minds of the authors weren't committed
> sufficiently clearly to paper.
> 
	And that I find the most worrying aspect of this LDAP approach -
because without a System and Information model which is clearly defined
(as per X.500), then all one can do is add a feature based on a belief -
and that feature can mess up all that has gone before . QED

	ie The object(entry) in a directory system is the basis for
atomicity - this is a fundamental principle - an engineering principle.
This transaction thing - violates that to a point where:
	It is impossible to implement- or if it is - the system  will be
just a mess.
	LDAP will end up as a List of Directory Access Problems.


	It is a sad state of affairs that LDAP is touted as the
Directory service when its extensions seem to be in total conflict with
a directory model and even themselves.

	Hopefully some of those "consultant reports" which seem to say
LDAP does everything should get into reality mode and look at these
major issues and conflicts.

	eg. I still cannot see how certficate path processing will be
achieved on an open and wider scale with LDAP servers - its impossible.
And building a transaction mechanism on non distributed - client to
server only environment is really not worth the effort.

	Why the preaching - again. LDAP with its useless access control,
its high configuration requirements and its inability to deal with
certficates - are the real problems.
	I think its wrong to add to a technology with these problems a
conflicting principle such as this transaction idea and make yet more
problems - 

	Customers do not want technical ideas that dont interwork - they
want commercial solutions.

	regards alan