[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: CLDAP comments
At 10:49 AM 2/27/01 +0100, Leif Johansson wrote:
>The example stated in the draft, i.e that of a cip proxy service, is a
>valid one. Operational experience from the GIDS project shows that tcp
>overhead is a problem in the case of one request and multiple responses
>(in this case references are received from the index). A similar situation
>is when a directory server is used as a replacement of a NIS server
>(i.e rfc2307).
I concur that there are applications of connection-less LDAP (I
believe they are limited). My concern (which I didn't state very
clearly in my past post) was that the I-D put too much focus on
overcoming operating system limitations and not enough on
the primary rational, reducing transport overhead expense.
>Furthermore the work in rfc 1798 contains two essentially independent
>parts, one beeing the udp-transport and the other beeing the combination
>of several results into one pdu.
I think these are quite dependent parts in that the combining
responses into one result PDU was specifically introduce to
effectively deal with the transport characteristics of UDP
without introducing other significant client/server/network
overheads.
By point is that CLDAP (RFC1798) is very simple and
this is good thing. I agree that the approach has
limitations (such as the significant result size limitations),
but that these limitations only impact a faction of the set
of target applications. Your index application might be in
that faction.
>In the spirit of LDAPv3 it would seem
>like a better idea (imho) to create an extension which regardless of
>transport ships multiple results in a single pdu.
I see updating CLDAP (RFC1798) to support LDAPv3 features as
a completely different task than providing a UDP mapping to
LDAPv3. It's my view that the while CLDAP might not met
all applications needs in regards to low-transport over
access to the directory, that CLDAP is a viable solution
for many of these applications.
>There are several
>possible solutions to the problem of determining when results have been
>received, how many etc etc. In fact many of the comments you made are
>already noted in the draft but I believe that it is better to solve them
>within the framework of LDAPv3 extensions than to stay with an fundamentally
>different PDU format.
I agree that there are numerous methods for adding reliability
features to protocols running over UDP. Providing means for
a client to:
a) detect whether it has the complete result
b) remove duplicates from the result
c) reorder the responses into server generated order
is rather straight forward. Yes, one could use a control
mechanism to provide such.
If we assume such a control was added to your I-D, I am not
sure your retry semantics are sound. In particular, your suggestion
to reuse message ids (in the face of late arriving PDU from prior
uses) might be problematic. Without details of your mechanism to
detect whether a retry is needed, it's hard for me to comment. What
concerns me is that the "complexity" of message id reuse upon
detecting a, b, c on subsequent uses. It is also not clear how
the retry mechanism would avoid repeated retries due to seemly
repeatable failures.
>I would also suggest that whatever happens to this draft rfc 1798 be moved
>to historic. It might be interesting to get an ADs input on the last
>comment: given the fact that rfc1798 and this draft is not compatible (even
>though it is easy for a server to tell them apart) can they, and if so under
>what circumstances, share the same assigned port?
Well, if LDAPext is defining "LDAPv3 over UDP" as opposed to
"CLDAPv3", then I would think we should:
a) reflect this in the charter (by dropping the sentence
"The group will expand on the work developed for
LDAPv2 in RFC 1798").
b) progress an I-D stating that CLDAP is historic, and
c) push forward on "LDAPv3 over UDP".
However, if LDAPext actually does end up defining CLDAPv3, then
CLDAPv3 should just obsolete RFC 1798. So, for now, I don't
see an over