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

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

Hi,

I'm having trouble following the bit about replicating the refer attribute.
I agree that it should be a DSA-specific attribute. 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?

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. I think this complicates Steven's argument. (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.
> 
>