Subject: Re: namedref-00: manageDsaIt question

From: "David Chadwick" <[email-masked]>
Date: Tue, 3 Aug 1999 23:54:39 +0100

From:           	"Kurt D. Zeilenga" <[email-masked]>
Organization:   	OpenLDAP <http://www.openldap.org/>

> Given a scenerio as outlined on p5 but with the addition of a server A
> masters "c=us", server B masters "o=abc,c=us", and server C has replicas
> of "c=US" and "o=abc,c=us", what does server C return when base search
> with ManageDSAit for "o=abc,c=us" return?

Firstly, if I understand your scenario correctly, server C holds a 
copy of the o=abc,c=us naming context. You are working in a single 
master replication mode, so the DSE o=abc,c=us will be flagged by 
server C as a shadow (or copy)  rather than as an entry. Server C 
may also hold a supplier reference to server B, and also a master 
reference to server B as operational attributes in this DSE. (Note 
these reference types come from the X.500 documents. The LDUP 
group are currently working on an information model for replication 
which may be different to the X.500 one and the knowledge 
references may be held in subentries.)

Now to answer your question.
If the administrative user invokes a base search on the o=abc,c=us 
entry in server C, the user will obtain whatever attributes from this
entry he requested according to his attribute description list. If he
requests knowledge references to be returned they will be, 
otherwise they
wont be. Server C will not normally return a referral since it can answer
the users request from the copy of the entry that it holds.

> 
> I would suspect it should return the "o=abc,c=us" referral entry
> replicated from A and not the entry replicated from B.

There is no such thing as a referral entry. A referral is an element of
protocol pointing to another server. Servers hold DSEs, and some DSEs may
hold ref operational attributes (or knowledge references) as well as other
attributes. Ref attributes are turned into referrals by processing at the
server. This is one of the clear distinctions that I have tried to make in
my knowledge ID, that is not so clearly made in the named ref ID.

> 
> This leads me to believe that a server should, when given any operation
> with a ManageDSAit control, use the parent DN to determine which backend
> (DSA) to obtain the target entry from.  

This is not my understanding of how it should work. A server that 
holds only a ref attribute in a DSE, will, if it receives a search 
request do one of 3 things depending upon the manageDsaIT control

i) if the control is missing, return a referral based on the value of the
ref attribute ii)if the control is present, return the ref operational
attribute in the result (providing it was asked for by the admin user)
iii) return a null result if the user did not ask for the ref attribute
and the control was present.

> However, doing so against server
> B would to return a superior/default referral (hopefully to A).  That
> seems, oddly enough, quite reasonable to me.

I dont go along with this. A request to search o=abc, c=us to server B
should always return a result as server B is the master for this entry.

Hope this helps

David

> 
> I'd appreciate some clarification in this area.
> 
> Kurt
> 
> 

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

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 [email-masked] *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

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 03 Aug 1999 17:57:13 -0700

Maybe I should give a another example.

server M masters two naming contexts
	"o=abc,c=us"
	"ou=hq,o=abc,c=us"

and replicates just "o=abc,c=us" to X and just "ou=hq,o=abc,c-us" to Y
and both to Z.  X, Y and Z refer requests to which they do not hold to M.

In name context "o=abc,c=us", the following named reference exists:
	dn: ou=hq,o=abc,c=us
	ou: hq
	ref: ldap://Y/ou=hq,o=abc,c=us
	ref: ldap://Z/ou=hq,o=abc,c=us
	objectclass: referral
	objectclass: extensibleObject

and the entries "o=abc,c=us" and "ou=hq,o=abc,c=us" both exist in their respective
naming contexts.

A. If a client does a ManageDsaIT enabled base search for "ou=hq,o=abc,c=us" against
server X, X should respond with the referral object in the "o=abc,c=us" context.

B. If a client does a ManageDsaIT enabled base search for "ou=hq,o=abc,c=us" against
server Y, Y could respond with either:
	1. the actual "ou=hq,o=abc,c=us" entry or
	2. a referral the superior server Z.

C. If a client does a ManageDSAIT enabled base search for "ou=hq,o=abc,c=us" against
server Z, Z could respond with either
	1. the actual "ou=hq,o=abc,c=us" entry or
	2. the referral object "ou=hq,o=abc,c=us" held in "o=abc,c=us" context.

D. If a client does a ManageDSAIT enabled base search for "ou=hq,o=abc,c=us" against
server M, M could respond with either
	1. the actual "ou=hq,o=abc,c=us" entry or
	2. the referral object "ou=hq,o=abc,c=us" held in "o=abc,c=us" context.

Cases C and D, to me, are the interesting cases.  If the servers Z and M return the
actual entry than the ManageDsaIT won't let the client manage the referral object held
in the superior naming context.  If you allow Z and M to return the referral object,
than it makes sense to me that option 2 should result in case B.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 05 Aug 1999 14:20:48 -0700

Belay my last response.  I've provide another example:

Server A masters "o=abc,c=us"
Server B masters "ou=hq,o=abc,c=us"

server M holds replicates of
	"o=abc,c=us"
	"ou=hq,o=abc,c=us"

As such, the are separate naming contexts as they are mastered
by different servers.

X holds a replica of "o=abc,c=us" naming context.
Y holds a replica of "ou=hq,o=hq,c=us" naming context.
Z holds a replica of both "o=abc,c=us" and "ou=hq,o=hq,c=us" naming
contexts.

X, Y and Z refer requests to which they do not hold to M.

and the entries "o=abc,c=us" and "ou=hq,o=abc,c=us" both exist in their respective naming contexts.

A. If a client does a ManageDsaIT enabled base search for
"ou=hq,o=abc,c=us" against server X, X should respond with
the referral object in the "o=abc,c=us" context.

B. If a client does a ManageDsaIT enabled base search for
"ou=hq,o=abc,c=us" against server Y, Y could respond with either:
	1. the actual "ou=hq,o=abc,c=us" entry or
	2. a referral the superior server Z.

C. If a client does a ManageDSAIT enabled base search for
"ou=hq,o=abc,c=us" against server Z, Z could respond with either
	1. the actual "ou=hq,o=abc,c=us" entry or
	2. the referral object "ou=hq,o=abc,c=us" held in "o=abc,c=us" context.

D. If a client does a ManageDSAIT enabled base search for
"ou=hq,o=abc,c=us" against server M, M could respond with either
	1. the actual "ou=hq,o=abc,c=us" entry or
	2. the referral object "ou=hq,o=abc,c=us" held in "o=abc,c=us" context.

Cases C and D, to me, are the interesting cases.  If the servers
Z and M return the actual entry than the ManageDsaIT won't let the
client manage (compare,search) the referral object held in the superior
naming context.  If you allow Z and M to return the referral object,
than it makes sense to me that option 2 should result in case B.

Kurt