Re: [ldapext] Chained Operation (control, extended op, or op?)

["Jim Sermersheim" <jimse@novell.com>]

I agree, it needs to state which procedures are to be followed (X.518,
or yet-to-be document procedures in the I-D). I'm struggling with trying
to understand the subtleties of the X.518 procedures enough to judge
which direction is best.

The X.518 procedures are a pain to follow because rather than stating
the problems and then providing solutions, it just provides the solution
and occasionally hints at the problems being solved. I will spend some
time trying to put together a problem set, and then test whether the
procedures I had in mind will solve that set.

This message is getting long, so I'll reply to the remainder in
different messages.

Jim

>>> "Ennis, Mark" <mark.ennis@adacel.com> 6/22/04 7:24:08 PM >>>
Jim,

My concern is not that you are not following X.518, but that you appear

to be implying the X.518 procedures without providing the information 
required by those procedures. I think your draft needs to define the 
procedures for distributed operations for LDAP directories in order to

ensure the information provided in the chaining arguments and results 
are sufficient to the procedures defined.

More response in-line below.

- Mark.

Jim Sermersheim wrote:
>>>>Mark Ennis <mark.ennis@adacel.com> 6/21/04 10:48:20 PM >>>
>>
>>The search will be chained with the 
>>targetObject of the chainingArguments set to the name of the superior
of 
>>the DSE containing the subordinate reference 
> 
> 
> This is not what LDAP returns as the DN part of a referral URI. So if
we did it this way, the target object in a chained operation would be
different from the 'target object' of a referral. If there's a way to
keep the 'target object' consistent between these, I'd prefer it.

If I remember correctly, the argument for using the name of the
superior 
of the subr DSE is so that multiple sibling subr DSEs, where the 
subordinate entries are in the same subordinate DSA, will result in a 
single continuation reference instead of one for each sibling, thereby

reducing the number of chained operations required to complete the 
operation. It also makes the subr and nssr reference types generate 
equivalent continuation references. This may be another reason for the

ChainingResults.alreadySearched field.

> 
> 
>>and the 
>>operationProgress.nameResolutionPhase set to completed (cf. X.518 
>>19.3.2.2.1 7a). This allows the subordinate DSA to confirm the 
>>targetObject is an immSupr DSE and proceed with the search from this

>>point. 
>>If the subordinate DSA cannot resolve the targetObject as an 
>>immSupr DSE then it should generate ServiceError.unableToProceed to 
>>indicate an inconsistency in the hierarchical operational binding
(i.e. 
>>the knowledge) between these DSAs.
> 
> 
> My draft doesn't consider the need for checking the consistency of
the distributed data model. If that is a requirement, I need to refactor
it. I do have a couple questions relating to this.
> 
> 1) Why must the immediatly superior name be passed as the
targetObject? If the receiving DSA knows a chained operation is due to a
subordinate reference (yes, that would require more information than the
draft currently has), and the targetObject is set to the name of the DSE
which caused the referral, then the receiving DSA can examine the parent
of the targetObject if it wishes to perform a consistency check. Are
there other reasons that the parent is sent as the targetObject?

The targetObject is not set to the name of the superior of the subr DSE

during name resolution. It is set to the target object of the
operation, 
which may change from the originally supplied target object due to the

dereferencing of aliases during name resolution. The 
operationProgress.nextRDNToBeResolved informs the subordinate DSA which

RDN in the target object is the name of the context prefix to begin 
local name resolution on.
> 
> 2) LDAP Servers often store a DN in the URI which represents
knowledge information (RFC 3296). This DN does not have to name the DSE
that holds the knowledge information. This can be useful (though
potentially dangerous) when mapping a local name to a different remote
name (let's call this "name mapping"). For example, I may have a server
that holds a subr DSE (well, a RFC 3296 referral) named
id=Sharks,id=MyStuff where the ref attribute holds a value
ldap://zoology.org/order=Selachimorpha,sublcass=Elasmobranchii,class=Chondrichthyes,superclass=Gnathostomata.
I wouldn't clasify this as a good practice, but one that is allowed and
used. If we pass the local name of a reference's parent as the target
object (where that reference holds mapped names), it will surely cause
any validation check to fail (in fact it will cause the operation to
fail regardless of a validation check).

The target object of the chainingArgument is not the superior of the 
subr DSE during name resolution. In the case of a named subordinate 
reference as defined in RFC 3296, it looks to me like a combination of

an alias and a subordinate reference. I would re-write the target
object 
by replacing the resolved portion with the name in the reference and 
then chain the request to the indicated server, if I was following
X.518 
procedures for distributed operation.

> 
> So I guess two questions for the list are:
> a) Is it required that the chained operation facilitate distributed
data consistency checks? If so, must it be done in the same manner as
X.518?
> b) Is it required that the chained operation allow for a distributed
data model where disparate namespaces can be joined via "name mapping"?
> 
> 
>>X.518 assume that the first step for the processing of any operation
is 
>>name resolution. The operationProgress is used to determine if the 
>>hierarchical operation binding (represented by the knowledge such as

>>subordinate and superior references) is consistent. In the absence of

>>the operationProgress, a subordinate DSA, on receiving a request for
a 
>>naming context it does not recognise, will chain the request to a 
>>superior DSA. Where the hierarchical operational binding has become 
>>inconsistent between the superior and subordinate DSA, this could
lead 
>>to a loop condition or an incorrect NameError.noSuchObject.
> 
> 
> Right, for these scenarios I assumed that the return of either of
these errors (loopDetected or noSuchObject) would suffice.

The main difference is that normally ServiceError.unableToProceed is 
used by the X.518 procedures to cause another continuation reference to

be used if one is available, while the NameError.noSuchObject and 
ServiceError.loopDetected cause the operation to complete with an
error. 
This is particularly relevant to processing of non-specific subordinate

references, where the problem is not due inconsistency in the HOB, but

is due to lack of knowledge in the superior about which naming contexts

exist in which subordinate DSAs.

> 
> 
>>The operatonProgress in the traceInformation of the chaining
arguments 
>>is used to support a situation where one DSA contains both superior
and 
>>subordinate parts of the DIT to a second DSA. Because of aliases, the

>>first DSA could have the same request chained to it at different
points 
>>in the name resolution and needs to be able to distinguish between
the 
>>incidents in order to allow the name resolution to complete.
> 
> 
> If the targetObject sent to the first DSA is different each time the
operation is chained to it, it should not detect a loop, and thus allow
name resolution to progress.

I can think of an example where the X.518 procedures would permit the 
same request to be chained to a DSA more than once, each time with the

same target object but a different nextRDNToBeResolved. The example may

not be very likely but is potentially possible in a complex topology.

Suppose we have the following DSAs:

DSA1 has two context prefixes: c=au and ou=development,o=adacel,c=au.
DSA2 has one context prefix: o=adacel,c=au.
DSA3 has one context prefix: ou=view500,ou=development,o=adacel,c=au.

Appropriate hierarchical operational bindings have been established
for:
DSA1 -> DSA2 -> DSA1 -> DSA3.

We are attempting name resolution on 
ou=testing,ou=view500,ou=development,o=adacel,c=au with from DSA1, but

DSA3 in unavailable.

DSA1 attempts name resolution and ends up with two candidate
references, 
one to DSA2 and one to DSA3. Attempting to chain to DSA3 gets an 
unavailable error so the operation is chained to DSA2. DSA2 attempts 
name resolution and chains the operations back to DSA1. DSA1 now has a

second go at the name resolution on the request which fails due to DSA3

being unavailable.

The first attempt DSA1 makes to resolve the target object it has an 
operation progress of { nameResolutionPhase proceeding, 
nextRDNToBeResolved 1 } and the second time of { nameResolutionPhase 
proceeding, nextRDNToBeResolved 3 }. In X.518, the target object is the

same. Without the operation progress information, the chained request 
from DSA2 to DSA1 would generate an incorrect loopDetected error.

The X.518 procedures allow a implementation the choice on how to
proceed 
based on an attempt to chain receiving a busy, unavailable, 
unwillingToPerform or invalidReference error. They can try a different

candidate continuation reference or return an error. This choice leads

to the situation I have described.

I think situations with partial replicas could cause similar situations

to occur.

> 
> 
>>N.B. I have used the ITU-T Rec. X.518 (1993 E) as my reference for
the 
>>X.500 procedures for distributed operations. As far as I am aware
there 
>>are no significant differences in more recent editions of this 
>>recommendation.
>>
>>- Mark.
> 
> 
> Thanks for the feedback. As you can tell, I have not implemented
this, I have only used it as a guide in experimentally implementing
enough of it in an LDAP server to come up to speed enough to start the
I-D. I very much appreciate the help.
> 
> Jim

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext