[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Regarding <draft-ietf-ldapext-knowledge-00.txt>
Thanks for the explanation. My comments are embedded below.
Sukanta Ganguly
>>> "David Chadwick" <d.w.chadwick@salford.ac.uk> 07/21/99 11:45AM >>>
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.
========== SG ==================
If we are talking about different namespaces (I don't like the word "global" cause that gives an impression of one namespace for the entire world.), then what is the relevance of keeping the referral. To refer to a particular node of a entirekly different namespace the current server needs to keep the knowledge of that entire namespace. To make it less confusing let me present an example.
Let us have two namespaces "A" and "B". If a server "SA1" within the namespace "A" needs to refer a client, which came to it, to some server "SB1" belonging to namespace "B" then it has to retain the knowledge (i.e the complete structure along with schema) of the namespace "B". This assumption or requirement is not practical and in real life not acceptable. So how can LDAP servers from namespace "A" refer to specific servers in namespace "B".
I think cross namespace references need a better definition and much more rigid operation. Do you agree?
========== SG ==================
> (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".
========== SG ==================
If privateRef is within the server then why would one need it. Since the data that the referal is trying to point is within the same server, why does one need a referal?
========== SG ==================
> 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.
========== SG ==================
My implementation does the processing and hence I do not need the sup or sub. It is simplistic but works fine. I hadn't read you spec when I starting working on this last summer.
========== SG ==================
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
***************************************************