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

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

>>> Mark Ennis <mark.ennis@adacel.com> 6/21/04 10:48:20 PM >>>
>Jim,
>
>The operationProgress becomes important in name resolution when DSAs 
>have subordinate/superior relationships. Traditionally LDAP servers are 
>defined as "First-level DSAs" which means that the operationProgress 
>information is of little value in processing of referrals.

I'm not sure I agree with this statement. Many LDAP servers are required to be populated with the context prefixes of the naming contexts they hold. Some allow a superior referral, but others don't. I think the distributed data model has never been fully defined for LDAP servers, so to date, the servers are a mish-mash of different elements of First Level DSAs and non First Level DSAs. 
Regardless of that, I am interested in finding out what scenarios require operationProgress.

>It is not true that a receiving DSA will not get a nameResolutionPhase 
>of "completed". This can occur when processing a search operation, where 
>name resolution has completed, but the scope of the search includes a 
>reference to a subordinate DSA. 

You're right * I wasn't thinking.

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

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

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

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

>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