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

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 03:47 PM 7/21/00 +1000, Steven Legg wrote:
>> >That would be so if server A and server B both had references to some
>> >third server, but I was talking about the situation where server A
>> >masters the entry, server B has a reference to the entry in server A,
>> >and server C replicates from both server A and server B. 
>> Server A tells
>> >server C that the object class is say, organization, while 
>> server B tells
>> >server C that the object class is referral.
>> 
>> Yes, this is quite different.  This requires C to maintain clear
>> separation of information which A is authority over and information
>> which B is authority over and to restrict updates to accordingly.
>
>You're sort of progressing down the path of X.525's planes of information,

Well, I'm trying to understand the referral model were proposing.
Is it the X.500 model with planes of information with DSAspecific,
DSAshared, distributed operational attributes or something
else.  It seems we're mixing in new ideas which are not well
defined.

In particular, the old namedref proposal (and my updated version)
seems much akin to DNS zone delegation model than the X.500 model.
(Which needs to be better specified)

Rolands proposal seems to mix of the two models which I find
quite confusing.

>which is fine for single master replication but isn't meaningful in a
>multi-master environment where servers have joint authority over
>shared data. There really needs to be only one version of the shared data
>for multi-master replication.

I think the DNS zone delegation model better support multi-master
environments.  However, it has other limitations (such as upon
the types of knowledge information that can be represented).

>> When DSE are replicated, receiving server must have a clear
>> mechanism for determining the update is associated with the
>> portion of the DSE.  I've suggested one approach, there are others.
>
>To be replication friendly, information in a DSE that is different from
>one server to another needs to be in DSA-specific attributes if it is
>reflected in any attributes at all.

Yes, but 'refer' is distributedOperation and, if DSA-specific, why
would your replicate it?

>In X.500 the specialness of DSEs
>containing references to other DSAs is captured in the dseType,
>a DSA-specific operational attribute. It looks to me that LDAP needs
>something like it, though in this case the refer attribute itself
>would be enough. Roland's description of the processing that takes place
>depends only on the presence of the refer attribute. The object class
>of the entry containing the refer attribute doesn't get a mention that
>I could see. The definition of the referral object class near the end
>is pretty much incidental.

Excepting when creating an entry to represent a subordinate referral...

>> This is my primary concern.  I am not sure it makes sense
>> to change an entry into an subordinate reference just by
>> adding a 'refer' attribute.  I believe you should have to
>> delete the entry and add a 'referral' entry.  I also think
>> that a 'referral' entry MUST have a 'refer' attribute.
>
>If you add a refer attribute to an existing entry then the other
>attributes in the entry become meaningless and might as well
>be removed.

But the server can hold both the entry and the referral DSE.
Are saying it cannot hold both?

>An LDAP DSE type attribute would help if you feel there is a
>need to make a more emphatic display of the fundamental change in the
>nature of the DSE.

What I think is we either need to follow more closely the X.500
model (including planes of information) or we describe another
model.


>With LDUP it would be possible for a replica to hold both the
>actual entry contents and the refer attribute, which is basically what
>you get if you just add a refer attribute to an existing entry.

Note you just said the entries contents are ignored if a 'refer'
attribute is present.

>We would need to define what that means.

Exactly.

>> 
>> The implication is that certain DSEtype changes make little
>> (or no) sense and using the presence or lack of presence of
>> an attribute type (or types) to indicate such may not be
>> optimal.
>
>Do I take this to mean that you like the fact that an object class
>definition mandates what can and can't be in a referral DSE?

This too!  I like the fact that referral object class is structural
and disallows certain modifications of the allowed/required attributes.

>There are other ways to do that, like writing down the requirements, 
>which is how X.500 deals with the permitted usage of most of the
>operational attributes.

Yes.