[ldapext] Distributed Procedures Requirements

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

All,

Mark Ennis suggested, and I agree, that more detailed instructions
(than I provided in my rough draft of the chained operation) are needed
for distributed LDAP operations Before diving too deeply into precisely
defining the semantics of the chained operation, I need to get a sense
for what are seen as the required attributes of the LDAP distributed
procedures. So, I've summarized what I believe to be debatable
requirements/goals. I haven't included obvious things like: loop
detection, allowing all operations other than abandon/cancel to be
chained, removing duplicate results, etc.. 

Following is the list, along with a brief description of what the
concept means. If possible, can you provide feedback as to whether you
think each should be included in the considerations or instructions for
chaining operations?

1) PartialOutcomeQualifier (X.511). LDAP has not yet defined this as a
control. If LDAP were to support it, then there are four cases when
chaining that will cause it to be returned:
1.a) When a DSA encounters an unsupported critical control while
progressing a subrequest. (X.518 : 15.5.2)
1.b) When a time limit was exceeded while outstanding subrequests were
in progress. (X.518 : 16.1.4.1)
1.c) When a size limit was exceeded while outstanding subrequests were
in progress. (X.518 : 16.1.4.4)
1.d) When an association between another DSA progressing a subrequest
was lost. (16.1.4.2.3)

As far as I can tell, the use of the PartialOutcomeQualifier has no
bearing on other aspects of the chained operation (no other phases of
the progression of a chained operation rely on its values). Therefore, I
believe considerations and instructions for PartialOutcomeQualifier can
be omitted and left for a future specification.

2 Time and size limit enforcement. Currently, LDAP only allows for
these limit specifications on the search operation. It's reasonable to
assume a future control will be defined which allows a time limit to be
specified for any operation. Regardless of that, I believe the chained
operation specification must include considerations and instructions
where needed to properly handle these limits while chaining.

3) Priority. X.518 basically says all DSAs need to handle this if
present. I don't think considerations need to be made for it.

4) preferChaining, chainingProhibited, localScope. These seem to
obviously need consideration and instructions. BTW, I plan to resubmit
draft-sermersheim-ldap-chaining-xx which introduces these concepts to
LDAP.

5) partialNameResolution. I vote to not make considerations for this,
but I could easily be swayed.

6) nameResolveOnMaster, copyShallDo, dontUseCopy,
dontDereferenceAliases, etc. I think (at least hope) these types of
policies can be noted in a general way rather than cluttering up the
spec with detailed instructions regarding them.

7) scopeOfReferrral (if a referral is returned, it must be within the
specified scope). I vote to ignore this for now. Similarly, some have
asked for a scopeOfChaining (don't chain outside the specified scope). I
think this could be addressed later.

8) Loop Avoidance. While loop detection is obviously required, should
we give instructions for loop avoidance? 

9) Emulated Chained Operation. When a remote DSA does not support the
chained operation, the chaining DSA could emulate (to a degree) the
chaining of the operation by sending the original (or a modification of
the original) operation to the remote DSA. Instructions for modifying
the incoming operation would likely be very similar to what a DUA must
do to follow a referral.

10) Mechanisms for better performance. As was recently brought up, The
X.518 chained operation passes a targetObject of the parent of the next
naming context when chaining a search subrequest. A benefit of this is
that in certain circumstances, a single DSA (holding a number of naming
contexts, all below the same parent) can be contacted once rather than
once for each naming context. I believe this is a marginal reason to
follow the X.518 procedures in this regard.

11) Mechanisms for consistency checks. Another reason pointed at for
passing a targetObject of the parent of the next naming context when
chaining a search subrequest (and also passing operationProgress) is so
that the receiving DSA can perform consistency checks on the distributed
data model. If this is a requirement, there are different ways to
achieve it.

12) Failover and use less likely candidates when chaining. The X.518
procedures keep a list of candidate references while resolving the name.
One benefit of this is that when a DSA is unavailable to progress an
operation, a less likely candidate can be tried. Allowing this behavior
brings also with it the need to pass operationProgress in order to
properly perform loop detection. I don't see the benefit outweighing the
overhead of the added processes.

13) Loss of association between DSAs. I believe direction must be
provided for handling the case where the connection between DSAs is lost
while chaining.

14) Administrative limits. I think this is basically the same as #6
except the policies are set on the server rather than passed with the
operation. So I vote to follow #6 on this.

15) DSABind. I was planning to allow for two things: A) a chained
simple bind (the DN is found to be on a remote DSA, so the bind is
chained). B) other. A DSA may simply bind to another DSA using whatever
method it can/wants, and use whatever proxy auth it wants while
chaining. Meaning, I was planning on punting and allowing a future, more
robust spec talk about this as it has uses outside chaining (such as
DISP, DOP, etc).

I can't think of any other requirements/goals right now. If there are
others, let me know. If you think it would be better for me to place
these requirements/goals into an I-D, let me know that too.

Whatever ends up being left out, I hope can be specified later.
Meaning, I hope to write the spec in a way that future considerations
don't require the chained operation spec to be updated.

Thanks for helping,
Jim

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