RE: gluing directories with draft-ietf-ldapext-locate-02.txt

["Lloyd, Alan" <Alan.Lloyd@ca.com>]

I don't quite follow this but a few personal comments:

We (OpenDirectory) didn't sweep the information model of X.500 under the
carpet. That is why I commented the way we did about LDAP and continually
tried to remind people that directories are about "standard - distributed
information systems". In fact because of this situation, we at OD put 32
patents on our design  of the X.500 information model re its implementation
and  industry strength back end. 

For those old timers who did ASN.1 - and had ASN.1 compilers - and took the
X.500 ASN.1 protocol specs from the standards - and fed them into the
compilers (just like the world does with C++, etc) - to produce code for the
X.500 protocols automatically, etc. 
ie. The last problem we had was the "complexity" writing the code of the
"X.500 protocols"  - that was the easy bit. However, the processing of them
at the OO information level is somewhat different. 

Hence my views on LDAP.. why hand craft  (and still handcraft) something in
that after five years (LDAP - that does not have a Distributed, secure
information model ) - when one can get a compiler (ASN.1) to produce about
70% of DAP automatically in 10 minutes for something (X.500) which does have
a system design. This is not an issue today of course as all directories
support the current LDAP - as far as practicable. However, LDAP servers have
very limited directory capabilities - eg. no distribution.

Many of the problems with LDAP are self inflicted - ie The biggest mistake
of LDAP was and still is --- Take  (X.500) a secure. managed, coherent
distributed OO information system - that includes standard naming and schema
for global use and certificate based authentication systems, etc  - 
See that as a client access protocol issue (DAP) (10% of X.500)   - and then
try to redesign it with out using the models and tools that the original
system was designed with (eg. ASN.1 compilers).

This is like looking at a 747 - saying its too complex -  criticise it to
death,  then hype up about building a "simple" replacement  - and then start
engineering the door using tools that only deal with woodwork -. 

It's the engineering principles that get me with LDAP. No models as you
state, no views about information security or distributed systems and their
operational and financial impacts on business organisations, etc. No wonder
the LDAP server approach to business is fraught with operational risk and
costs.

I am sorry to say that after a few decades in large scale system engineering
-  with systems that runs large scale business's . There is no such thing as
a simple solution to a complex problem. And a few lines of schema and
protocol in a "spec" is about .000000001% of the issue when building large
scale, reliable business information systems.

A few things to note:

1. Simple Client-Server protocols - do not make distributed, secure
information systems....

2. Adding simple server features to protocols that do not apply to large
scale distributed, secure information systems - is a futile exercise.

3. As the global carriers evolve and integrate the Internet, TV and
Telephone services of this planet, tweaks, and unscaleable features to
"protocol" will become questioned. (One does not update the Telephone
network protocols without considerable thought and money!)

It has taken about 5 years to get LDAP to where it is. It took 4 years to
get the whole of the 1988 X.500 standards released. If LDAP is still about
70% of DAP and DAP is about 10% of X.500 - Will it be that "LDAP"  replaces
X.500 in about 2050?


Regards alan


	-----Original Message-----
	From:	Harald Tveit Alvestrand 
	Sent:	Thursday, May 18, 2000 7:43 AM
	To:	Lloyd, Alan; Tom Jordan; Lloyd, Alan; Sukanta Ganguly;
Lloyd, Alan; ietf-ldapext@netscape.com; Kurt@OpenLDAP.org
	Subject:	RE: gluing directories with
draft-ietf-ldapext-locate-02.txt

	At 22:03 15.05.2000 -0400, Lloyd, Alan wrote:
	>Thanks for the response - but the SRV thing - well it still does
not address
	>why directories are needed and the applications they serve - and
the
	>information model designs that relate Users to Services....

	one of the problems that have plagued both X.500 and LDAP is that
this 
	information model design was largely swept under the carpet.
	If you ask "why do we need directories", the answer that everyone(?)
agrees 
	on seems to be "of COURSE we need directories".

	the fact that intra-organization phone lookup and
business-to-business cert 
	retrieval (to pick 2 examples at random) are rather different
operations 
	don't stop us from agreeing that "the directory is the answer".

	It is not strange that we've got problems.

	                         Harald

	--
	Harald Tveit Alvestrand, EDB Maxware, Norway
	Harald.Alvestrand@edb.maxware.no