[ldapext] Distributed Operations: Comments

[Apurva Kumar <kapurva@in.ibm.com>]

Jim,

I had a couple of observations on the distributed operations draft
(revision: 01):

(i) fields like traceInformation and searchedSubtrees have more to do with
distributed operations rather than the particular mechanism being used
(chaining/referral etc). E.g. looping could occur with referrals, so
traceInformation should be included in ContinuationReference. But IMO, a
better solution is to delink such control information (visited URIs and
searched subtrees) from the operation being progressed and include them as
controls.

(ii) while the draft considerably simplifies distributed operations from
X.518, I feel much less is required to reliably use the referral and
chaining mechanisms in LDAP. Existing LDAP mechanisms for referral
generation and  using referrals for progressing operations are well
understood and widely implemented. Chaining is simply following a referral
at a DSA instead of the client. These basic mechanisms can be supported by
controls which keep track of visited URIs and searched subtrees.

E.g. a client or a DSA could include a distributedOperation control:

distributedOpControlValue ::= SEQUENCE {
    visitedURIs   SEQUENCE OF LDAPURL,
    searchedSubtrees   SEQUENCE OF LDAPDN OPTIONAL
}

DSAs encountered as the operation progresses (by either referral or
chaining mechanism) will perform loop detection, update these fields (if no
loops were found) and send them back in a response control (in case of
referral) or include the updated control in chained operation request(s).
The response control will also include a result code describing the status
of the distributed operation.

Regards,
Apurva
-----


Apurva Kumar,
Research Staff Member,
IBM India Research Lab
Phone: +91-11-26861100
Fax: +91-11-26861555


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