RE: Beginning taxonomy for finding LDAP servers.

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

But you dont need to do this with X.500 systems  - so why have this
approach.

Hypothetical situation ....

Dear Mr customer,  if you buy all these non distributed LDAP servers you
will also have to buy one or two more (for relibility) that point to the
ones you thought you wanted in the first place. In addition you will
need some "additional" resource to manage these servers... In addition
the comms pipes bewteen these servers will require more bandwidth
because of referred searches. Now as we have proposed a number of LDAP
servers because each department in your organisation wants to own its
information and determine its own access controls on that information,
because of the lack of capability in these LDAP servers means that we
now have to replicate all the user information of the system to/from and
between have EACH department with a server and that each and every
department   manages ALL the user portions of the directory information
- for the whole organisation and its customers.....

By the way - the more this system scales up  - the worse it will get -
operationally and in costs.


There is another way that avoids this mess and operational cost - use a
distributed X.500 directory system....


Which one would you buy?

regards alan

> -----Original Message-----
> From:	David Chadwick 
> Sent:	Wednesday, May 12, 1999 5:12 AM
> To:	ietf-ldapext@netscape.com; Jeff.Hodges@stanford.edu; Ryan Moats
> Subject:	RE: Beginning taxonomy for finding LDAP servers.
> 
> 
> > 
> > Well, yes there are sub-approaches, and so I would modify that
> portion of
> > the taxonomy to be:
> > 
> > Method: Referrals
> > 
> > In LDAPv3, servers can return referrals to the client if the server
> has
> > knowledge of where a query might be satisfiable.  Two ways of
> deploying
> > referral information are deploying an LDAP knowledge server or
> exchanging
> > CIP index objects between servers. An LDAP knowledge server would
> hold
> > cross references to possibly hundreds of other LDAP servers, so that
> a
> > client would only need to know about its local LDAP server and the
> > knowledge server. 
> 
> As pointed out in my other message, the local LDAP server can also 
> act as a knowledge server for the organisation, so that clients only 
> need to point to their own corporate server.
> 
> David
> 
> > If CIP index objects are exchanged between LDAP
> > servers, then those objects can also carry URL information for
> providing
> > referalls to clients. In this case, the client would only need to
> know
> > about the local server. In both cases, the local server could be
> > discovered by one of the previous methods discussed.
> > 
> > Hopefully, this addresses both methods.
> > 
> > Ryan
> > 
> > 
> 
> 
> ***************************************************
> 
> David Chadwick
> IT Institute, University of Salford, Salford M5 4WT
> Tel +44 161 295 5351  Fax +44 161 745 8169
> *NEW* Mobile +44 790 167 0359 *NEW*
> Email D.W.Chadwick@iti.salford.ac.uk
> Home Page  http://www.salford.ac.uk/its024/chadwick.htm
> Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
> X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
> Entrust key validation string MLJ9-DU5T-HV8J
> 
> ***************************************************