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

["Steven Legg" <steven.legg@adacel.com.au>]

Kurt,

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
> Sent: Friday, 21 July 2000 19:02
> To: steven.legg@adacel.com.au
> Cc: ietf-ldapext@netscape.com
> Subject: RE: I-D ACTION:draft-ietf-ldapext-refer-00.txt
> 
> 
> 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.

The referral model is what Roland described except that it needs to be
generalized to account for the effects of replication, and some of the
details of the distribution knowledge representation could be different
to avoid compromising LDUP.

> 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.

Some of it is well defined and well practiced in X.500 but we still need
the new ideas because of the consequences of multi-master replication.

> 
> 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.

I'm not familiar with DNS zone delegation so Roland's proposal looked
to me like it was inspired just by the X.500 distributed knowledge model.
It has the same sorts of references in the same sorts of places.

> >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).

After a quick read of the DNS RFCs I have two, possibly bogus,
observations to make.

Firstly, DNS doesn't look like a multi-master environment.
All name servers holding authoritative data for a particular zone
can trace back to the same original configuration file. All changes
occur at, and are propagated from, this original file. That's single
master replication even though the single master is just a text file.

Secondly, the resource records are the same everywhere they are stored
regardless of whether they are cached or authoritative, and regardless
of what name server holds them. DNS would be messy if the records were
represented differently depending on location, just as LDUP/URP will be
messy if shared data has different representations depending on the
context of the directory server.

> 
> >> 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 this case the DSA specific data is whether the DSE represents a
reference or entry contents. It's one, or the other, or with LDUP it
can be both. This varies from server to server.
In X.500 that information would be held by the dseType (DSA-specific).
For the moment I'm assuming that the presence of the refer attribute
tells us the DSE is a reference without it saying anything about whether
the DSE has normal entry content.

The shareable data is the refer attribute (distributedOperation
is appropriate) and any other non-DSA-specific entry contents
(including the object class).

> 
> >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...

Yes, "near the end". The presence of the referral object class is
incidental to the task of generating referrals.

> 
> >> 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?

Sorry for the confusion. There's important context that I neglected
to make explicit. For a DSE that contains both referral information
and entry contents;

If the DSE is in an area of replication that is singly or jointly mastered
and the refer attribute references the server itself, or one of the other
masters, then the entry contents are used and the refer attribute is
ignored.

If the DSE is in an area of replication that is read-only and the refer
attribute references the server itself then the refer attribute is ignored.
If the refer attribute references some other server it will be a master,
so whether the entry contents or a referral is returned will depend
on service controls like dontUseCopy.

If the DSE is not in an area of replication and the refer attribute
references the server itself the refer attribute is ignored.

Otherwise the entry contents are ignored.

Of course the above would need to be generalized to account for multiple
values of the refer attribute.

> 
> >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.

Some aspects of the X.500 distribution and/or replication model are
worth using for both DISP and LDUP compatibility (like the clean
separation between DSA-shared and DSA-specific data) but other
aspects don't apply in the multi-master environment (like planes of
information). What we need is not quite like anything that has gone
before in the directory space.

> 
> 
> >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.

Yeah, sorry again.

Regards,
Steven

> 
> >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.
> 
>