RE: Naming of ACLs - LDAP deficiencies

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

> -----Original Message-----
> From:	dboreham@netscape.com [SMTP:dboreham@netscape.com]
> Sent:	Saturday, May 02, 1998 1:11 AM
> To:	ietf-ldapext@netscape.com
> Subject:	Re: Naming of ACLs, Replication etc
> 
> Alan Lloyd wrote: 
> 	        So why did the draft LDAP ACL document add extensions to
> the 
> 	protocol for ACI or permissions
> Better ask the authors. I'd say that it looks like something that'snot
> needed, and which should probably be removed from the document. 
> 	  As said my mum in london does not have a URL stamped on her
> head.
> But she does have a DN stamped there ? 
> 
> 
	No but I think there are those inventing directory protocols
think she should. But what about other things.
	 
	I name this ship  QE2@someplace.sea  or
http://www.bigthing.water.world !


> 	        Absolutely not..I think the LDAP development model has
> proved 
> 	that designing information systems from a "protocol perspective"
> is 
> 	absolutely flawed.
> And the X.500/OSI development model by contrast has proved, what ? 
> 
	That object oriented systems and distributed design is
fundamental for directory systems, that the big bad old OSI stack in all
its glory which was far to big to develop by the whole of the IT
industry is 130kbytes, that ASN.1 is not too complex that the whole
world would not understand it - and the ISO and ITU got something right
in terms of engineering , information tranfer transparency, object
modelling and scaleable directory systems and its associated engineering
tools 10 years in front of LDAP.
	Thats all.

	Want some real comparisons:

	Protocol Data Transparency:
		LDAP string based - has to label things Binary -
transparency bodged in.
		X.500 uses ASN.1 - data transparent.

	Protocol Efficiency
		LDAP string based - genery twice as many bytes on the
wire than ASN.1 tagging. 	LDAP seen to have 100% more overheads
than  X.500 DAP.
		X.500 uses ASN.1 - data efficient.


	Multi Server Navigation
		LDAP uses referrals/one level searches for browsing  -
lots of interserver interactions when server boundaries are met,
Probably means that top level LDAP 	servers 	system 	and the
Internet will be over engineered by 10,000%.
		X.500 uses a List operation - no wasted interserver
traffic when DSA boundaries are met.


	Multi Server Searching
		LDAP uses referrals back to the client- lots of  client
- server interactions and dealing fragmented results.
		X.500 uses a inter server distribution - generally
designed to have one system response to the client.


	Certificate Path Processing
		LDAP cannot do these in a wider environment - therefore
EC is impossible with LDAP servers
		X.500 deals with distribution and certificates
naturally.


	Name Based Attributes - See Also, Role Occupant, Memberm Group
of Names, Mail Lists, etc
		LDAP cannot do these in a wider environment - therefore
wider business application of directories is impossible with LDAP
servers
		X.500 deals with distribution and distributed name
referencies naturally.


	Attribute Labelling/Contexts
		LDAP uses labelling by "$" string values in attributes -
makes access controls - when LDAP gets them a mess.
		X.500 defined contexts as seperate items than the
attribute values.


	DIT Management Model
		LDAP uses parts of X.500's management model but really
has not defined one yet - unmanageable DITs is not a good feature to
have in a directory
		X.500 defines a managenment model for operational
attributes, Access Controls, Schema, Collective attributes.....


	Distribution
		LDAP does this by client base referrals - ie two or more
LDAP servers must be configured by the LDAP configuration army.
		X.500 uses DSP and deals with distribution naturally
with server to server operations.


	Replication
		How LDAP does this is under discussion..
		X.500 uses DISP and deals with distribution naturally
with server to server operations.



	Master/Copy Data selection
		LDAP does not do because it does not have distribution
or replication coordinated
		X.500 uses entry marking and DISP and DSP with DAP
parameters to control selection.


	 Access Controls
		LDAP - this is still under discusion - but because LDAP
has no management model, no distribution and not much of an
authentication model - that will be 	impossible to deal with across a
wider environment and have domain based rules.
		X.500 deals with the 5 dimensional Authentication/Access
Control issues across a distributed environment correctly.


	Access Rights - ability to read.
		LDAP does not do this - no read service and no access
controls.
		X.500 uses Read services - with Modify rights request.


	Conflict of protocol Extensions
		LDAP has applied Paged results and Persistent Searches
and lately transaction control - these will not work in combination and
also add even more 	difficulties when referrals are encountered.
		X.500 has no such conflict because it is
object/operations based and uses a distributed server paradigm.


	Signed Operations
		LDAP does this because of its string based encoded
protocol - can this be done
		X.500 by using parametered ASN.1 naturally permits this
- and it works?


	Configuration Overheads
		LDAP only servers because they use client based
referrals must be manually configured everytime a new server is added to
the system
			(the LDAP configuration army)
		X.500 is distributed so each server is interconnected
(via DSP) and appears on line as part of the system one that server is
connected to another.


	Deterministic Performance. 
		LDAP, because it applies interserver navigation and
distributed searching by hand configuration and client based referals,
performance will be non deterministic.
		X.500 as a coherent distributed system can provide
deterministic results.


	Authentication Framework - X.509
		LDAP is attempting to introduce this.
		X.500 designed this 10 years ago.


	Confusing specifications
		LDAP has introduced fragments of X.500 specifications in
its error resposnes - yet these processes do not apply in non X.500 LDAP
servers.
		X.500 has a well defined error management model which
aligned to its distributed system model.


	Interserver Management
		LDAP has not ventured into this space yet.
		X.500 deals with replication and distribution management
through the use of DOP.


	Collective Attributes
		LDAP does not provide this feature.
		X.500 provides this feature.


	As said see below:

>         LDAP has ended up twice the code size, half the functionality,
> 
> half the information flexibility and twice as slow on the wire as DAP.
> 
> 
> Curious, I've not heard of an X.500 directory which is less than 
> an of magnitude slower than the fastest LDAP directory 
> server implementation with which I'm familiar. Mostly they seem to be 
> two orders of magnitude slower. 
> 
Pehaps most are  - but there are some that are not

we publish our performance figures for 20 DSAs, mms of entries-
interconnected and with one DUA (LDAP and DAP)
Have not seen any of this capability published for 20 LDAP servers
(interconnected by client based referrals) . 

dont forget these tests must have lots of complex searches, full access
controls,  any mix of attribute retrievals.


I will add what to me is the most fundamental issue here - there is a
different between a standard and its implementation. One cannot blame a
standard because it was implemented badly - or it is not understood.

However, one can blame a standard when it is so weak, fragile,
inconsistent and limited when something else exists and for the same
code size and when implemented correctly does twice as much in half the
time and provides the utility needed for distributed directory systems.

Some one on this list once said - that "directories are far to important
to us all to make a mess of it" -- or something like that. I agree ...



Please read the above and what do you think has happened. And do let me
know if I am wrong - or there is more to add.

I would like to think that most of the readers on this list work for
companies that spend their valuable R&D dollors to provide scaleable
quality information products. Why is their no debate re these LDAP
weaknesses?

Lets the customers decide - and if suppliers want to build products
which incorporate and deliver the problems that was solved by an
international  standard that was written 10 years ago,  then that is
their choice. After all an X.500  DSA is a whopping 12mbytes and a DAP
stack 130KB.


In the standards process I do not mind working on integrating LDAP
technologies with X.500 - But I aboslutely object to turning directory
standards into a mess. I believe in fixing things as we go.


regards alan



> 
>