RE: I-D ACTION:draft-ietf-ldapext-refer-00.txt

["Lloyd, Alan" <Alan.Lloyd@ca.com>]

Sorry to but in here - but I am also a bit lost with the rationale behind
referal stuf - to this detail. At the operational level (not the theoretical
- probable situation level) - when one builds a distributed large scale
directory service that contains load balancing, fault tolerance, alternate
DSA features (implied replica DSAs) anywhere - when one needs a distributed
mesh.. and read only, multi master, update only, modes of operations - One
realises the knowledge issues are not just referral attributes but back bone
control properties..

I think where we are coming from is that we have this stuff operational - eg
load balancing, fault tolerant mesh systems supporting WEB TV - V-ISP
services - and the details proposed - well they seem to be a liitle
extraordinary and rely on very intelligent browser devices to deal with
them.

Can you imagine my mum on her digital WEB TV looking for her sisters phone
number - and a response = "Please follow ref:nssr..."

To me refrrals are bad news - directory service users - DONT WANT THEM...one
needs to have a distributed / replicated seamless directory service..

Can you see the telephone working this way? "dont try here.. try there"..or
try else where - but I dont know where.

regards alan


-----Original Message-----
From: Ramsay, Ron 
Sent: Tuesday, July 25, 2000 11:21 AM
To: steven.legg@adacel.com.au
Cc: ietf-ldapext@netscape.com
Subject: RE: I-D ACTION:draft-ietf-ldapext-refer-00.txt


Steven,

Thank you for your response.

I have followed your argument elsewhere regarding interpreting the refer
attribute. I find it difficult to travel with you on this one.

First, let me review what I have said about the refer attribute. I believe
that it should not be replicated except possibly in the situation where you
wish to create an identical but read-only copy.

You have tried to show how the refer attribute could be interpreted by a
replica receiving it. For example, if the reference is (you), discard the
attribute and use the normal entry contents. If the reference is not (you),
though, we should ask what the reference represents. I may have received it
from a colocated DSA but I may receive a more recent value from a DSA on the
other side of the world. I guess if it is more recent, I use it? I'm
guessing that if I did use it, it would not be appropriate. Maybe I should
be using the entry contents that I received from the master. In this case
you would look at the 'dontUseCopy' option. (Isn't that DAP-only?)

If a refer attribute is updated, will it be replicated? I guess it would,
but it is possible that it was only updated to fix a problem with the
replication where it was actually given the wrong value.

References are the means by which a distributed DIT is created. Allowing
them to be replicated means that rules will have to be created outside the
LDAP model to handle them. This seems to me to be worse than the problem we
are trying to solve. We will probably need more options as well. For
example, ;read-only will help with dont-use-copy:

    refer, refer;sub, refer;sub;read-only.

Ron.

-----Original Message-----
From: Steven Legg [mailto:steven.legg@adacel.com.au]
Sent: Monday, 24 July 2000 18:21
To: Ramsay, Ron
Cc: ietf-ldapext@netscape.com
Subject: RE: I-D ACTION:draft-ietf-ldapext-refer-00.txt



Ron,

> -----Original Message-----
> From: Ramsay, Ron [mailto:Ron.Ramsay@ca.com]
> Sent: Friday, 21 July 2000 16:36
> To: steven.legg@adacel.com.au; 'Kurt D. Zeilenga'
> Cc: ietf-ldapext@netscape.com
> Subject: RE: I-D ACTION:draft-ietf-ldapext-refer-00.txt
>
>
> Hi,
>
> I'm having trouble following the bit about replicating the
> refer attribute.
> I agree that it should be a DSA-specific attribute.

I didn't say that. The current usage of distributedOperation
is appropriate, at least for the cases of refer;sub, refer;nssr
and refer;cross. But refer;sup and refer;me really should be
dSAOperation since their values are only useful to the local server
(so there is a case for the use of separate attribute types instead of
attribute options).

> But my
> conclusion would
> be that it *cannot* be replicated.
>
> I suppose, under master-slave replication, you could specify that all
> entries are copied verbatim (though the refer attribute may
> now point to a
> DSA which is no longer, eg, local), but for master-master
> replication there
> would seem to be no situation in which the attribute can be
> replicated. (I
> should have given a long-sentence alert!) In multi-master replication,
> presumably one of the replicas has the actual entry. If this entry is
> updated, the updates will be sent to the other masters, so
> they now have
> (parts of) the whole entry. The refer attribute now seems to be
> out-of-place?

It does, but we have various ways to deal with this situation.

1) We could choose to never replicate the refer attribute (make it
completely DSA-specific). However there are good reasons for replicating
sub & nssr. For example, it's not unreasonable for me to want to create
a read-only replica of a master server that contains all the same
distributed knowledge references. Having to manually maintain the
references in the read-only replica would be annoying.

2) We could put special case processing into LDUP to drop the refer
attribute in the circumstances where it would be "out of place".
Given that the determination of "out of place" is dependent on a
changeable replication topology, the propagation delays of same,
and the properties of the yet to be defined partial replication,
I'm a bit wary of this solution.

3) Allow the refer attribute (except ;me & ;sup) to be replicated
like any other DSA-shared attribute and define the semantics so that
it is ignored whenever, and for as long as, it is considered
"out of place". This is the line I've been following.
I think we can define this with more certainty than 2.

>
> I should think the entry itself is DSA-specific!
>
> Note that, if NSSRs are retained, the NSSR will actually be
> carried in a
> real entry.

If the NSSR is like the X.500 NSSR then it is carried in the immediate
superior entry of the unspecified naming context(s). So yes, replication
aside, that is a real entry with a regular object class (i.e. not referral).

> I think this complicates Steven's argument.

Not too much I think. Any of the unspecified naming contexts could be
present as a result of a replication agreement, in which case they are no
different from any local subordinate entries that were already
present (I'm assuming that refer;nssr allows local subordinates
to be present also). The awkward part is that we might not be able to
tell whether *all* the unspecified subordinates have been replicated.
To be safe referral/continuation references would have to be returned,
so a client might end up collecting more duplicates than if the NSSR
were absent.

I'm not sure that solution 2) could do much better for NSSRs. Neither
the supplier nor the consumer can determine with 100% certainty in
all cases whether the NSSR should be replicated.

Regards,
Steven