[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

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