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

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

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

> (I
> found the draft a
> bit unsatisfactory in the area of NSSRs.)
>
> Ron.
>
> -----Original Message-----
> From: Steven Legg [mailto:steven.legg@adacel.com.au]
> Sent: Friday, 21 July 2000 15:48
> To: 'Kurt D. Zeilenga'
> Cc: ietf-ldapext@netscape.com
> Subject: RE: I-D ACTION:draft-ietf-ldapext-refer-00.txt
>
>
>
> Kurt,
>
> > -----Original Message-----
> > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
> > Sent: Thursday, 20 July 2000 14:29
> > To: steven.legg@adacel.com.au
> > Cc: ietf-ldapext@netscape.com
> > Subject: RE: I-D ACTION:draft-ietf-ldapext-refer-00.txt
> >
> >
> > At 12:16 PM 7/20/00 +1000, Steven Legg wrote:
> > >> >> Is an option required?  If not, what is the semantics of
> > >> an optionless
> > >> >> refer attribute?
> >
> > No answer to this yet.
>
> I thought that was a question for Roland, but if you want my opinion,
> it doesn't mean anything. Optionless refer attributes are ignored.
>
> > >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,
> 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.
>
> >
> > >Where a DSE is a placeholder for an entry that isn't held
> > locally that
> > >DSE shouldn't contain shared information that contradicts
> the remote
> > >master entry. It's painful for replication if it does.
> >
> > The proposal suggests using named entries to representing
> references.
> > For a subordinate reference, it proposes that this object have
> > an attributes associates with naming, object class referral, and
> > object class extensible object.  This information my be in
> > contradiction with the actual entry DSE it refers to.
> >
> > 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. 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.
>
> >
> > >> My primary reason of suggesting use of object classes, especially
> > >> for subordinate references, is that the semantics need to be
> > >> established when the entry is instantiated.
> >
> > 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. 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.
>
> 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.
> We would need to define what that means. A refer attribute in
> a read-only
> replica is effectively a reference to the server(s) holding the master
> entry. Whether you send back a referral in this case would depend
> on things like the X.500 dontUseCopy service control. A refer
> attribute
> in a writeable replica could be a self-reference to the server or a
> reference to one of the other mastering servers for that
> entry. In either
> case the refer attribute is ignored. Anything else is processed as
> Roland describes.
>
>
> >
> > >The DSEType is not immutable in X.500
> >
> > Correct, I should have said that DSEtype is not modifiable by the
> > user.
>
> Not directly, but user actions can affect the DSEType. For example,
> adding/removing the administrativeRole attribute changes the admPoint
> bit in the DSEType.
>
> >
> > 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?
> 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.
>
> Regards,
> Steven
>
> >
> > >That depends on how you interpret clause 19 of X.501:1993.
> > It might be
> > >legal for a DSE that is not of type "entry", "alias" or
> "subentry" to
> > >have an objectClass attribute without all the mandatory attributes.
> >
> > The proposal models references as entries, with object classes,
> > with RDN attributes, with musts/may requirements.
> >
> >
>
>