RE: draft minutes from Chicago meeting

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

Tim - I support Eric in this 100% and the comments below worry me.

Tim:

A good way to approach the problem, and the approach
that this group will take, is to separate problems
that can be separated and solve them one at a time.
That's all I am saying. You and others should feel
free to continue discussing the merits of requiring
TLS or kerberos or foobaz. Just realize that it's a
separate discussion from selecting the cram-md5-like
non-clear-text authentication mechanism.   -- Tim

Alan:
ie. Solving a problem one at a time hardly verifies one is going in the
right direction. Eg we must build and aeroplane. First of all, it needs
wheels, what do we make them of, Oh we have some wood....thats the
wheels made,  whats the next problem... 

I think that building a scaleable and operational protected directory
system for the Internet and EC so the world can do business on it with
compatable devices.. eg client software that can access the bigger
systems or smaller systems without megabytes or knowledge, options,
referral management..... needs to be worked through.

My views are well known about LDAP...eg some of the extensions in LDAP
v3 just wont work in a distributed large scale directory system - but
they are OK for small address book servers. So instantly with LDAP we
have client software compatability problems.

AND, LDAP V3 and referrals and clients managing master or replicas by
reading the server info - - what a wonderful highy unworkable and
fragile  "solution".

eg. I have to access 3 LDAP servers, A, B and C, In the LDAP world if I
want to be authenticated on to each server, I have to copy all of A to
B, A to C, and if B and C users want to see A we replicate B to A and C
to A and B to C..
 This means I have my password in 3 servers, 1 in the master-A, and 2
replicas.
If I want to change my password and during the process C gets switched
off and A has an error - Comms fails and all that. And then we all
switch on.. what has the client got to do to recover the situation..
What is the password state?

Put 10 replicated servers on line, etc, etc and what does the failure
situation look like then with password management..

Its a good job all these problems were fixed one at a time - eg. LDAP V3
with referrals, clients reading servers to get master/replica status,
and of course client software remembering password status across its
replicas and of course the human effort just needed to deal with all
this replication in a dynamic business/operational environment.

Sorry to me again. I dont believe in fixing one problem at a time.
Becuase one ends up in a mess. I believe in designing systems that to
the best of my ability dont have problems.

I think that what is happening is the LDAP has now made the clients
bigger than DSAs and with more and more options going in them
particularly for security - incompatability and pain will be common
place.

My belief is that a solution to a problem creates more problems, then it
is not a solution.

As you can see LDAP is now creating more and more problems. Perhaps we
should review the design approach.

regards alan



Erik Skovgaard wrote:
snip...