Re: [ldapext] Comments to <draft-sermersheim-ldap-chaining>

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

Ugh, now we're going to get into gritty implementation details of VLV
and SSS -- I shoulda used a different example.

Our (and I imagine other) implementations will service VLV and SSS
controls using an index if possible. In this case, entries may be
immediately returned as they are matched (as opposed to gathered,
sorted, then returned). In this scenario, (unless your proposed change
to SSS happens) a client may need to wade through many results *before*
it can even decide whether to begin presenting returned entries to a
user interface for exmple. This is because the server is free to return
referrals at any point (2.1 of rfc2891 does not excuse this).

In my example, the client did want data as you say, but only under
certain circumstances. When a number of DSAs hold copies of portions of
the tree, the client may need to contact a series of altServers in order
to locate one that can service the request in the manner that the client
wishes. Only after exhausting all DSAs might the client wish to fail
over to performing the distributed search and merge sort the results. 

I still don't see there being harm in, as you say, preventing useful
information from reaching the client. The client is aware of what it's
asking for, and has chosen to ask for a certain behavior. If the client
wishes for a different behavior, it should ask for different behavior.
There's a kind of unrelated analogy to the criticality of controls here.
 A client may wish to make a control critical to prevent the server from
performing the requested task (even though performing it might result in
useful information being returned) if it cannot service the request in
the exact way the client wants.

The final point is that there are implementations (two that I know of)
which allow all four of these behaviors to be set on a server-wide
basis, and the control can be used to override the server's behavior.
One implementation currently has its installation default as
chainingPreferred, the other has it as chainingRequired. The
implementation which defaults to chainingPreferred has been available
and widely used (most deployments are left in chainingPreferred mode)
for over ten years, so in my mind, there are a lot of people who assume
that in the absence of any control, their request is going to be
chained. Assumptions aside, it's the DSA's choice, and this control
allows as much flexibility as I could imagine is needed for today's and
tomorrow's need to override the server's default behavior.

Jim

>>> Howard Chu <hyc@highlandsun.com> 2/24/05 11:10:06 PM >>>
Jim Sermersheim wrote:
> I have to admit that I disliked the names and limited usefulnes of
the
> controls as they are defined in X.511, and that may have influenced
me
> to simply define them in a symmetrical and (to me) more clear way
for
> LDAP.

Fair enough, I can appreciate symmetry...

> I see usefulness in chainingRequired. For example, assume a client
> wishes to perform a SSS or VLV search operation and knows that the
data
> in the result set may be distributed (and perhaps further assume
some
> DSAs support chaining these operations). If the client can specify
> chainingRequired, it would know that the results it gets back are
> already sorted and no extra work needs to be done. If the server
cannot,
> or will not chain, then the operation fails, and the client learns
this
> up front. In the absence of chainingRequired, the client may get
back
> many search results -- assuming they're sorted, only to find out in
the
> end that one or more search result references need to be followed to
> complete the operation.

I believe you're seeing a false economy here. The point is, why did the

client ask the question it asked - presumably, because it wanted some 
data. If your client sends a request with e.g. SSS, the server will 
proceed to gather results up, find that it can't obey the Chaining 
control, and return an error to the client. But as far as I can see,
the 
client still wanted that data, else why did it ask in the first place.

The client can just give up and say "sorry, I can't get what you want
in 
my preferred fashion" but the more useful thing for it to do is to
retry 
the request and make do with whatever results it gets. In that case, 
you've just doubled the amount of work the server has to do, because
the 
client will re-issue the same request, with relaxed controls. Nothing 
changes the fact that extra work needs to be done by the client, (or it

must just fail); the presence of the control doesn't help matters in
any 
way.

Also, this SSS example isn't quite right - obviously a server needs to

gather up the complete result set before it can begin returning sorted

results to the client. As such, it will already know if references are

present before sending any results to the client. It would be wrong for

the server to begin sending entries back knowing that the result set 
contains unresolved references, so that search should automatically
fail 
in the absence of chaining. Indeed, RFC2891 pretty much dictates that 
the request will fail, in section 2.1. In this regard, I would prefer 
that that spec be changed to require servers to send unresolved 
references first, ahead of regular entries, and let the client decide 
whether it wants to slog through or give up. Cutting off the
information 
at the server prevents the DUA user from making an informed decision 
about what to do next. Giving the information to the client allows the

possibility of a graceful recovery.

> I believe that chainingRequired may also be
> useful for other multi-object operations which are served best (or
can
> only be completed) by the act of DSA chaining. Off the top of my
head, I
> can't think of a strong case for chainingRequired during name
resolution
> (otehr than the case I make below for referralsPreferred), but I see
no
> harm in allowing it's specification.

I believe the harm is in preventing useful information from reaching
the 
client, thus making error recovery messier and more expensive than it 
needs to be.

> I also see usefulness in referralsPreferred. It allows one to
possibly
> override whatever the server's behavior is. We have deployments
where
> the server's setting is chainingPreferred or chainingRequired.
Clients
> may prefer to receive referrals, yet want the operation to be
chained
> when policy prevents a referral from being returned.

To me, the absence of any chaining control already implies 
"referralsPreferred" but I'll have to think about it some more. It 
becomes useful if you assume that the client knows more about the 
referred server than the original DSA knows. Personally I believe this

assumption is seldom true, but I guess I can't say "never" so I'll
leave 
this alone for now.

-- 
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc 
Symas: Premier OpenSource Development and Support

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