RE: RFC 2251 considered harmful

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

Love to give an example - 
It is well known that I think many of the LDAP documents are harmful -
to the User and business/IT  service levels.


IMHO LDAP having a non distributed model that does referrals that can be
cascaded - and then apply controls to that on a single server interface
for sorting means that all the merge /timing/final sorting  complexity
goes into all the clients - ie One is multiplying the complexity - and
therefore the risk

ie.  instead of getting servers to deal with correlation and sorting
which is sensible from a timing and interface perspective and providing
a consistent service to users  - the client software has to deal with
"vaguries of a disjointed system". . The result is a situation where
badly timed responses from  incompatable servers in the referral paths,
will lead to non deterministic results for Users  - however , that is
the price of designing simple protocols that do not have the capability
to work consistently over a distributed system.

I have a wooden wheel - and now I have to make a car....

I wonder what the target service model of ldap will really be - once we
include all the pieces re embedded attribute labels,  access controls
(yet to be defined), arbitary referrals and page sorting and poor multi
server navigation.

I often wonder if a salseman for LDAP systems actually can tell a
customer that a multi server LDAP environment is operationally reliable
- given all the evolution that is going on and the weaknesses in the
LDAP system design areas.


I often wonder if anyone who is actually working on this LDAP direction
would like to write down a service (from a user perspective) model and
reliability model  based on  all the fragments that are being added to
LDAP to make it server oriented (without distribution). And then add to
that model access control concepts.

And then ask the users and business world if they would want it. 



Our business is to build and supply high integrity, high serviceability,
scaleable, distributed directory systems that have proven access control
and security features.

>From this perspective, LDAP is ok as an implementation ideal for simple
clients to access such services. Hence we support it. 

Integrating LDAP servers into an X.500 core service is a good approach
to larger systems because it brings distribution capability to simple
entry level directories (LDAP servers)  - thats why we introduced DXlink
for our DSA. 

Having client controls in the access protocol to control chaining
(distribution) and master /copy entries (replication) is also useful -
thats why we released a free DAP stack with an LDAP style API.

But making a distributed search result or set of (referral) results
correlated in clients is just asking for inconsistent service levels -
and business level people do not want to run on that.


Why is it in the commercial world we have to state service integrity,
reliability scaleability and operational characteristics to deploy
systems - but in this "add a fragment to a protocol" world - no one
seems to consider that fact.

Regards alan


> -----Original Message-----
> From:	dboreham@netscape.com [SMTP:dboreham@netscape.com]
> Sent:	Friday, February 27, 1998 4:32 PM
> To:	ietf-ldapext@netscape.com
> Subject:	Re: RFC 2251 considered harmful
> 
> >So, um, what exactly is the solution to using referrals in a
> >protocol that allows servers in the chain to not support
> >critical extensions?
> >
> >It seems that the safest thing for a client to do is use
> >LDAP v2. :-(.
> 
> I'm having trouble seeing the bear here.
> It all just sounds like a kind of option negotation.
> Can someone give a clear example where 
> extensions and referrals interact disasterously ?
> 
> 
>