RE: Search over referrals (Re: LAST CALL: draft-ietf-ldapext-ref erral-00.txt)

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

	-----Original Message-----
	From:	dboreham@netscape.com [SMTP:dboreham@netscape.com]
	Sent:	Wednesday, April 08, 1998 12:42 AM
	To:	Alan Lloyd
	Cc:	ietf-ldapext@netscape.com
	Subject:	Re: Search over referrals (Re: LAST CALL:
draft-ietf-ldapext-ref			erral-00.txt)

	Alan Lloyd wrote:

	> > by the customer. But I'm struggling to see how this
	> > affects distributed search, and even more what it has
	> > to do with LDAP ! I need some more education.
	> >
	>         Its just the way in which one uses the DB that makes
the
	> difference - on can store objects as rows, etc or one can be
smarter.
	>         If one is smarter then one can determine what one has
locally
	> and if one has to fire of a distributed search - I assume LDAP
servers
	>
	> do not do distribution so that is not a problem to them.

	I presume you're talking specifically about chaining, which
	LDAP servers don't support ? Reason I ask is because I
	see this words "distribution" and "distributed" banded about,
	but never defined. Presumably definition is in those expensive
white
	documents ?

	Chaining ie DSP is the protocol used between DSAs - but
distribution embraces a lot more such a domain based access controls,
mutual  authentication, consistent knowledge management, etc 
	Expensive documents - we have copies and we aint Microsoft !

	Anyway, I can't answer for other vendors, but if a client
	presented our server a search which required knowledge
	of whether target entries were stored on another server,
	we would resolve that query in much less than 1 millisecond.
	It's just a case of maintaining the appropriate indices, and
	not doing anything stupid. No rocket science involved, I think.

	Yes we do the same without maintaining indicies - because
distributed directories are about distributed name based transaction
systems and if one can get the system to work with names and knowledge
of the distributed context - one does not need all the other underlying
indices mechanisms. The more protocol in a system the less chance there
is of scaling - and the more management is needed.

	I keep thinking that if one keeps adding protocol to solve a
distributed search and retreival information problem (ie a database
issue), eventually one ends up with a pile of protocols and the
associated problems of scaling the protocols. eg. LDAP

	My preference is to fix information management problems in
information systems not add more protocol to cure a symptom that then
creates more problems.

	>         Eg single server  - get me three things of type x in
1,000,000
	>
	> entries, server has one thing of type x - server returns one
x..
	>         distributed servers - get me three things of type x in
	> 3,000,000
	> entries, server a has 1 x - and must fire off searches to
server b and
	>
	> c, etc. eg the database design is critical to distributed
performance.

	Sounds pretty easy. Also sounds like something you
	want to avoid doing because it will not scale.

	That is one view - but its not ours. It works for us and fast.
But re scaling issues See LDAP inefficient navigation issues, see LDAP
Certificate path processing problems, see LDAP inefficient protocol, see
LDAP referal and search results sorting, see LDAP and persistent
searches of many servers and operation state management, see LDAP and
naming contexts and (no) knowledge management. see LDAP and certficate
component matching issues, see LDAP domain based access control
problems.

	Again my view is that many complain about X.500 as an aeroplane
that makes a bit of noise when its in the air - whereas LDAP seems to be
meeting all sorts or scaling problems in the wind tunnel.

	>          LDAP does not do this so no worries eh!

	Yes, life is pretty good here in LDAP-land.

	Thats not what I hear - but I suppose its all relative - If one
is happy with a limited client / server architecture that has a string
based protocol that gets your data from your server - thats good.
	I prefer to deal with distributed scaleable information systems
that contain business level information objects for global use. And call
them directory systems  not "LDAP servers" However, we do through our
X.500 DSA DXlink integrate LDAP servers to give them a distributed
context to work in as a directory system , In addition we can configure
our X.500 compliant access controls in our DSAs to dominate all those
interconnected LDAP servers as being under a corporate domain based
access controls. Wow scaleability at its best.

	> > Now: "directory info into filespace" ?
	>         This was meant to say that RDBs are used for corporate
info
	> and
	> that directories will underpin corporate systems - however
some
	> direcories use good old filespace - as they just deal with
mail
	> addresses.

	I still don't understand this one. Are you saying that one kind
of disk
	block is somehow
	better than another one ? Or some kind of disk block
	managing code is better than another ?

	I think one needs to understand how scaleable Object oriented
named based transaction systems can be applied to relational concepts
and then applied to commercial RDBMS products efficiently really - its
not a disk block issue.
	Its to do with distributed information engineering and applying
that to globally recognised - stable database information products which
already have the commercial integrity and a major investment stream. For
instance we can switch our DIB on line to another DIB because of the
commercial RDB features.

	As said - directories are about information systems which
operate in a common naming context and are inteconnected by the most
efficient protocols (as per X.500) - I dont think they should be a pile
of protocols which lets me get to a local file system. LDAP seems to
have taken the latter direction.


	>         Its an integrity issue re how the directory is
applied. in the
	>
	> business.

	I'll take your word for it. Around here wethink we have plenty
of
	integrity, are you
	questioning ours ?

	No I am not question yours - But I will generally question file
based directory systems.  - RDBs do contain commitment services which we
use - so that if someone pulls the plug on the server while updates (eg.
100s per second) are being performed then the DIB if supported by an RDB
will remain intact - ie it will have integrity. I think that if a cached
based file system directory is used as the DIB and someone pulls the
plug when its updating then what state is the DIB in. 
	Is it hours of recovery and rebuild time. What DB commitment
services are used - generally none . As said big corporates use RDBs for
integrity of their business information. As directories will be used to
support the business in the same and critical context - then surely the
same information storage integrity should be used - Thats why we use and
RDB it in our directory - with automatic indexing on all attributes  -
for distributed performance. 

	Hope this helps

	regards alan