Re: Fwd: I-D ACTION:draft-rharrison-bulkldif-00.txt

[dboreham@netscape.com (David Boreham)]

Roger Harrison wrote:
> 
> Jim Sermersheim and I have published a draft describing an LDAP v3 extension to efficiently deliver and import LDIF data into an LDAP server.
> 
> Our goal in writing this draft was to define a mechanism that allows large numbers of LDAP operations to be specified by a remote client without the overhead of responses for each operation.  To do this, we've combined the LDIF data format with a wire protocol that allows a client to initiate and send LDIF data to the server and get periodic updates on the server's progress in processing the data.
> 
> We'd like to get input and feedback from the LDAP community both from a design standpoint and to see if this is something that should be added to the charter of the ldap-ext working group.

I'm surprised that the motivation was to avoid 
"the overhead of responses for each operation".
Is this really a large overhead ? 
Surely TCP ACK segments need to be sent back
to the client in response to each received data segment. 
Any LDAP response PDU
would surely piggyback on those packets wouldn't it ?
Considering that ldif is a less efficient
storage format than the equivalent BER, 
is the network traffic really lower ?

Some other thoughts:

1. Sending LDIF on the wire seems messy. Why do this rather
than send the entries in the same wire format they'd have
in an LDAP add operation ?

2. If the intent is to send a file from one 
machine to another, why can't an existing protocol
be used for that purpose (e.g. ftp, http) ?

3. How does this relate to the LDUP work ?
It seems to me that the task of initializing
a replica server over-the-wire is quite close
to the intended purpose of this proposal.
I believe that LDUP defines, or will define,
a protocol for replication update propagation.
There may be some overlap between this 
proposal and that protocol.

4. Does this proposal have roots in existing
NDS functionality ? If so, I'd be interested to hear
how deployment experience with NDS affected
the decision to specify this protocol rather
than to use one of the alternatives discussed
above. Netscape products currently use the
network file system or manual ftp here,
which has proven workable in the field,
if somewhat less than ideal.

Put another way: I've had many discussions
with engineers working on the server's
implementation where we talked about 
new and better ways to send imported
ldif data to a server, but I've never 
ever heard a customer or a marketing
person ask us to change the way this feature
currently works.