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

From: "Ramsay, Ron" <[email-masked]>
Date: Fri, 21 Jul 2000 16:36:23 +1000

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:[email-masked]]
Sent: Friday, 21 July 2000 15:48
To: 'Kurt D. Zeilenga'
Cc: [email-masked]
Subject: RE: I-D ACTION:draft-ietf-ldapext-refer-00.txt

Kurt,

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:[email-masked]]
> Sent: Thursday, 20 July 2000 14:29
> To: [email-masked]
> Cc: [email-masked]
> 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.
> 
>

---

From: "Steven Legg" <[email-masked]>
Date: Mon, 24 Jul 2000 18:20:30 +1000

Ron,

> From: Ramsay, Ron [mailto:[email-masked]]
> Sent: Friday, 21 July 2000 16:36
> To: [email-masked]; 'Kurt D. Zeilenga'
> 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

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.

> 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

---

From: "David Chadwick" <[email-masked]>
Date: Tue, 25 Jul 2000 14:53:05 +0100

> 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 would disagree. Both X.500 and DNS allow references to be 
replicated.

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

Not necessarily so. Image the case of a country level LDAP referral 
server with a subordinate reference to an organisation LDAP 
server. If the country level server is now part of a pan-European 
(say) set of country level multi-masters, then the organisation entry 
still is not held by any of them, and the sub ref is still valid when 
held by all the country LDAP servers.

David

***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
Email [email-masked]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************