Subject: Need for operationProgress (was: Re: [ldapext] Chained Operation (control, extended op, or op?))

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 22 Jun 2004 20:38:05 -0600

>>> "Ennis, Mark" <[email-masked]> 6/22/04 7:24:08 PM >>>

For the example below, the procedures I was thinking of would work because DSA1 would never attempt DSA2 (they don't keep track of all candidates while taversing the hierarchy). Keeping track of all candidates does seem beneficial though.

Jim

*---- Forwarded Message *----
<snip> 

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.

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: "Ennis, Mark" <[email-masked]>
Date: Wed, 23 Jun 2004 13:41:49 +1000

> For the example below, the procedures I was thinking of would work because DSA1 would never attempt DSA2 (they don't keep track of all candidates while taversing the hierarchy). Keeping track of al…

It can be useful as it potentially allows use of alternate routes 
through the network and can take advantage of systems' differing 
knowledge of available replicas for particular parts of the DIT.

On the other hand it can lead to extra work which ultimately leads to 
the same result.

- Mark.