[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Regarding <draft-ietf-ldapext-knowledge-00.txt>

Date sent:      	Tue, 20 Jul 1999 15:38:33 -0600
From:           	"Sukanta Ganguly" <SGANGULY@novell.com>
To:             	<m.wahl@critical-angle.com>, <d.w.chadwick@iti.salford.ac.uk>,
 	<howes@netscape.com>
Subject:        	Regarding <draft-ietf-ldapext-knowledge-00.txt>

> Hi,
>    Before I start with my analysis of
> <draft-ietf-ldapext-knowledge-00.txt>, I would like to introduce myself to
> the GURU's of Directory. My name is Mr. Sukanta Ganguly ( the prefix is
> required or else poeple think its a she rather than a he ;-) ), and I work
> for Novell in Provo, UT.
>    After reading the proposal I had the following questions/doubts in my
> mind. I believe the gist of the proposal was to provide some sort of
> connectivity between different LDAP servers in order to provide a
> distributed tree like design. Right ?

Correct. But more than that. Connectivity between a forest of LDAP 
trees. i.e. different (possibly distributed) LDAP trees that are not 
part of the same global namespace.

> (You guys may have a much deeper
> reasoning which I probably did not get in my first read)
>   1) If so then, I think the idea of "sharedRef" and "privateRef" is
> unclear to me. What is the value of having two different kinds of
> references. What exactly does "privateRef" provide which could not be
> accomplished by "sharedRef" ?

sharedRef can be shared between all LDAP servers in the same distributed 
DIT domain. They work just fine irrespective of the server they are stored in.eg. a 
ref to o=salford,c=gb LDAP server can be held by any server in our distributed global
namespace.
privateRefs on the other hand are private to the server they are stored in and 
cannot sensibly be shared to other LDAP servers without some 
modification or changes being made to them. An example of the 
latter is myRef. If I give you a copy it is can no longer be called 
myRef by you - you would need to change it to say "david'sRef".

>   2) With the "sharedRef" I can understand the need and value of
> "cross" type, but what is the relevance of the other three types ? The
> other three types specified, namely, "sub", "nssr" and "external" do seem
> to serve any specific value. ( Atleast I did not get it). From what I see
> of the "cross" type is that it is an indication of a replica of the LDAP
> naming domain. 


Not necessarily so. A cross ref may be to a single server that is not 
replicated. For example the salford server can hold a cross ref to the
dc=novell, dc=com server. If there are multiple values then the 
server is replicated.

>Especially, the "external" type, If it is around to
> represent a totally different domain then how good would it be as a
> referral system. A referral mechanism is valuable when a system cannot
> satisfy a clients needs but knows about somebody else who can. It that
> scenario a referral is useful and needed. But the naming domain are
> different then the search/location domains are completely different and
> hence it should be irrelevant.

this is there to cater for the case when organisations do not follow any global naming rules
For example, Bigcorp in Switzerland sets up an ldap server with the 
name of o=Bigcorp. And a completely different org in the US does 
the same thing. So we cannot have two O entries holding completely 
different information. These servers would hold references to the 
other servers using the external type of reference.

>   3) The types in the "privateRef" are also very confusing to me. (I am
> already confused with the use of this special reference type.) Are the
> "supplier" and "consumer" types a mechanism to bring in a concept of
> master and slave replicas in LDAP? Since LDAP does not preclude a notion
> of such model I think it should not matter at all. (Please help me
> understand where does it matter.)

You are correct that they are there for replication reasons. 
(primarily for the single master situation). The LDUP group is also 
working on this, and so some alignment will be needed (my ID was 
written prior to the LDUP work)

>    4) Also, in general, how does it matter to keep knowledge of whether
> the referral type is "sup" or "sub". (A simple dn comparison should be in
> the position to provide this knowledge. )

Because a sup reference has no name component that goes with it. 
It is held in the root DSE and points to any LDAP server nearer the 
root. (You do not know if fact what naming context it holds). There is 
the other type of ref "immedSup" which I did not add in the ID, but 
will do in the next version, that points to named superior. YOu may 
be getting confused with the immedSup reference. You are right that 
a name comparison for sub and immedSup can tell you whether a 
reference is to a subordinate or superior. But by holding this piece 
of data no name comparision is necessary - it is purely a tradeoff 
between processing and storage - the usual computing tradeoff.


Hope the above helps

David

> 
> I would really appreciate if you guys help me see light here.
> 
> Regards
> Sukanta Ganguly
> 
> 
> 
> 


***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
*NEW* Email D.W.Chadwick@salford.ac.uk *NEW*
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

***************************************************