RE: Beginning taxonomy for finding LDAP servers.

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

Yes - this issue is dealt with by navigation/knowledge within X.500
distributed directory systems - 
I think the issue of finding disconnected - non distributed servers has
to be dealt with by knowledge stored somewhere - Its just a case of
quantity, scale and where - Unfortunately this approach will always hit
scaleing issues and be expensive to configure - so any mechanism that
means handraulically configuring "knowledge" will hit a wall.

I would also like to say that distributed directory services can be
"subject" based ie.. Books - Subject, Subect,, etc and in addition
directory systems can include lagacy databases as search engines - so
any mechanism used should not be considered as compatable with DNS, etc


I think the same issue will apply to this knowledge management issue -
that has hit the "referral" between LDAP servers and replication issue.

ie. Many are announcing that their LDAP servers support referrals. How
ever, in an authenticated environment, if server A refers you to server
B and then you access server B. Server B must have your entry in it so
that you can be authenticated. And if those users on server B want to
see server A then server B has to be replicated to server A. ie a
Referral mechanism becomes pointless in an authenticated world - because
it implies one has to replicate everything to everywhere. Impossible.

It follws that if this is the case for free standing non distributed
LDAP servers - replicate to everywhere - how does the other "distributed
knowledge issue work"?

I detect conflict here and an aweful lot of operational human effort to
run LDAP only systems.

Delivering configuration of distributed namespace without the system
performing distributed mutual authentication - (as per X.500) is not a
viable approach. Simply because - in LDAP world you will have to
replicate - everything to everywhere.

Sorry to be me again - but I do get concerned that more mechanisms like
this just create more configuration and replication - without any added
utility.

X.500 provides distributed knowledge and distributed mutual
authentication to slove these issues.

regards alan


> -----Original Message-----
> From:	Ryan Moats 
> Sent:	Friday, May 07, 1999 5:22 AM
> To:	ietf-ldapext@netscape.com
> Subject:	Beginning taxonomy for finding LDAP servers.
> 
> Since the mailing list seems to have come back today, I am resending
> this...
> 
> Hi all-
> 
> Since I've been thinking on and off about this problem for a good long
> while now, I thought I'd kick off the discussion by listing the ways
> that
> I know of for finding LDAP servers.  I'm beginning to envision the
> work item on the LDAPEXT charter resulting in an informational level
> document
> (which I am volunteering to author or co-author as the case may be).
> 
> So...
> 
> 
> For LDAP clients finding Servers there are several different methods.
> This list is not complete, but should be considered the beginning of
> a taxonomy.
> 
> Method: Client configuration
> 
> In this case, the client administrator configures it with a list of
> known
> LDAP servers
> to send queries to.  This list will be right (initially), but
> modification
> to the list
> requires client updates and doesn't scale real well.
> 
> Method: WK DNS alias
> 
> If the DIT uses the "dc-naming scheme", then it is possible to
> construct the
> DNS names of potential servers using well known DNS aliases.  Without
> the
> use of
> the dc-naming scheme, it is possible to construct potential names
> based on
> the client's
> DNS name.  This has the shortcoming of being inexact and not
> supporting
> client roaming
> well when tunneling is not used.
> 
> Method: Service Location Protocol
> 
> A client that supports the service location protcol could do a SLP
> query for
> LDAP servers.
> This requires that the network be using SLP and and that the servers
> announce themselves.
> This method has the scaling drawbacks of SLP since it depends on that
> method.
> 
> Method: "discovery"
> 
> Besides using other methods, this method involves storing either the
> DN or
> related URL
> in the DNS in some way.  This method requires an administrator to
> configure
> the DNS with the
> information and the idea of storing either a DN or a URL in the DNS is
> a
> controversial one.
> The i-d that expounds this idea will not be renewed and is being taken
> off
> the service location
> WG's workplan.  This method would require persuation of the IESG to
> even
> reach
> experimental status.
> 
> Method: DHCP extensions
> 
> An expired internet-draft proposed using DHCP to deliver information
> about
> LDAP servers to a
> DHCP client. This requires that (a) the information be configured into
> the
> DHCP server and that
> the client both support DHCP and this extension.  Such a method would
> require resubmitting the
> DHCP and getting approval for it.
> 
> Method: CIP index objects
> 
> If LDAP servers are exchanging CIP index objects, then they can also
> exchange URL information for
> providing referalls to clients.  This would help by allowing a client
> to
> query a local server
> (that it discovered by one of the previous methods) and receive a
> referal to
> a non-local LDAP server
> which it could then query.
> 
> Comments are welcome as well as additional method brainstorming.
> 
> Ryan Moats