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

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

Yes its the details - ISO did a common application layer standard call
CCR (Commitment, Concurrency and Recovery) back in the late 80s - which
provides all the distributed transaction interchange. But as usual ( a
bit like LDAP) its so easy to write a spec about a protocols between one
machine and another as a client server. But when it comes to the control
and trust operating over distributed servers woking in a common naming,
security and transaction context - it gets hard.

IMHO LDAP is promoted to be simple - but it does not do anything except
get data from one server at a time. If other servers data is needed -
then bring in the LDAP configuration army. X.500 on the other hand
allows a read/search transaction over many interconnected servers in a
common naming/security and transaction  (object level) context... but
CCR if ever it is applied will permit multi server transaction updates
and thus is more complex..

IF LDAP efforts considered X.500 all too hard  - then update
transactions over distributed interconected servers have got to be
impossible under the same rules. Certainly if one wants to invent a CCR
protocol - its already documented - all one needs is a few $MMMM to make
it work commercially.
(please send a cheque :-) )

For LDAP to do transactions on a single server is "just another bell on
the bike".. and yet more DSA functionality in the client.
 (Perhaps thats where LDAP is going - we have a 1mb DAP client and a
12mb X.500 DSA that has LDAP interfaces , perhaps LDAP will end up with
a 12mb client and 1mb server :-) )))
 I seem to be dealing with the people to want single interface, thin
client, interconnected distributed protected interworking directory
systems. ie they are buying the car (X.500 with LDAP access) and as far
a single server transaction systems go - the directory access protocols
do the job.

just thoughts
alan


> -----Original Message-----
> From:	Harald Tveit Alvestrand [SMTP:Harald.Alvestrand@maxware.no]
> Sent:	Tuesday, April 14, 1998 9:17 PM
> To:	Alan Lloyd; 'dboreham@netscape.com'; Alan Lloyd
> Cc:	ietf-ldapext@netscape.com
> Subject:	RE: draft-ietf-ldapext-ldapv3-txn-00.txt More ..
> 
> Small comment:
> Might the DSAs use a transaction protocol such as that described in
> draft-lyon-itp-nodes-07.txt to coordinate the locking between them?
> 
> The span would go roughly between Client, Server1 and Server2:
> 
> Client -> Server1: Start transaction
>        <- OK
> Client -> Server2: Join transaction
> Server2 -> Server1 (TIP): Join
>         <- OK
> Client <- Server2: OK
> Client -> both servers: Stuff
> Client -> Server1: Finished
> Server1 -> Server2: OK to finish?
> Client -> Server2: Finished
> Server2 -> Server1: Yes, I'm OK to finish
> Server1 -> Server2: Let's do it
> Server2 -> Server1: OK, it's done
> Server1 -> Client: OK
> Server2 -> Client: OK
> 
> This is fairly standard technology, I believe.
> It's getting the details right that hurts.
> 
>                           Harald A
> 
> 
> 
> 
> -- 
> Harald Tveit Alvestrand, Maxware, Norway
> Harald.Alvestrand@maxware.no