Re: draft minutes from Chicago meeting

[Christopher Lukas <lukas@cs.wisc.edu>]

Mark Wahl wrote:

> 5. Referrals
> 
> The referrals document had gone through last call and significant
> comments on it were received.  This will be split into two separate
> drafts: one on the hierarchical (superior/subordinate refererence)
> use of referrals, and the other on a CIP-like mesh on referrals.
> The two drafts will progress independently, as the hierarchical part
> appears to have consensus to move to standards track, while the
> mesh part is still under discussion.

I'm sorry I missed out on the last call, but I still have some concerns
with the hierarchical use of referrals part -- the "Named Reference"
part, I assume. Since the document is going to be split and modified,
however, it seems like I have the opportunity to squeeze in an idea
here.

As I described in an earlier message, the main thing that bothers me is
that the operation of named referrals according to the document doesn't
seem complete to me. The issue I'm trying to get across is that with the
current document, some searches seem to me to be handled inconsistently.

This may repeat some of what I had in an earlier message, but here I try
to illustrate what I see to be inconsistent.

Server 1 contains the following referral:
dn: o=UW,c=US
ref: ldap://server2/o=UW,c=US


Server 2 contains all the records for o=UW,c=US (as well as the
o=UW,c=US entry):
dn: o=UW,c=US
<...attrs...>

dn: cn=Chris,o=UW,c=US
<...attrs...>

dn: cn=John,o=UW,c=US
<...attrs...>

etc.

1) If the client performs a SUBTREE search on server 1 with base
"o=UW,c=US" for "(cn=Chris)", according to the document, it will get a
referral to server 2 at which point the client will issue the same
search to server 2 and retrieve the matching record
(cn=Chris,o=UW,c=US).

2) If the client performs a BASE search on server 1 with base
"cn=Chris,o=UW,c=US" for "(objectclass=*)", server 1 will probably
return it's "superior reference" if it has one. If server 1 does not
have a superior reference, the record won't be found. If it does,
sending a search to it is an unneeded extra step (because server 1 knows
exactly what server holds "o=UW,c=US").


What I'm trying to get across is that it would be nice if, given the
search I describe in (2), server 1 could simply return a referral to the
appropriate server using the knowledge it contains rather than kick the
client to the server that knows where all the "o=*,c=US" parts of the
tree are.

I think that server 1 could, instead, figure out that _part_ of the base
DN being searched for in (2) is a reference that it contains and simply
return a referral to that. 

Why:
- it would allow a network of servers to exist where each server could
know what part of the tree is held by the others and no central server
is required to actually hold a higher part of the tree (e.g. in this
example there need be no c=US server that knows what servers all of the
o=*,c=US entries reside on).
- it would eliminate one step in the search

I don't think this is a fundamental change, and I do think it is useful.
Granted, it does appear contrary to the whole heirarchical namespace
concept because I think it would even further separate the namespace
from the actual location of the data, but maybe this is good.

I think allowing something like this allows a more decentralized system.
We do have reasons to want to do this.

If anyone has any ideas on how something like this should be done in the
current framework, I'd appreciate hearing them.


Thanks.

- Chris






------------------------
Christopher E. Lukas
Internet Scout Project 
http://scout.cs.wisc.edu