Subject: RE: FW: I-D ACTION:draft-armijo-ldap-treedelete-02.txt

From: Bruce Greenblatt <[email-masked]>
Date: Sun, 21 Nov 1999 21:03:34 -0800

Here are some requirements that I have in my experience building real world
LDAP applications that try to operate on an entire subtree.

- Provide user feedback as to the progress of the long lived operation.  In
many scenarios,
  a subtree delete operation may take a long period of time (many hours for
large subtrees).
  It is essential to have a progress bar move across the screen as the
entries are deleted.

- As the delete subtree crosses containers into other LDAP servers,
additional 
  authentication credentials may be required to be retrieved from the LDAP
client, in
  order to allow the operation to proceed.

- If the authenticated user has access to only a portion of the subtree to
be deleted, I
  think that it should be possible for the part of the subtree that is
possible to delete,
  to in fact be deleted.

- The list of entries that has been deleted by the operation should be
returned to the
  client.  An incremental list of deleted entries could be returned with
the progress
  indication above.

- It should be possible to "cancel" the delete subtree operation, just as
the long lived
  Search operation can be "abandoned".

- It should be possible to delete only certain types of entries from the
subtree.  For 
  example, delete all printer objects from the subtree.

I believe all of these requirements to be reasonable, but not met be the
draft as it stands.  I'm certainly willing to investigate an attempt to
support these requirements (i have a few more as well, but they are along
these lines) as a control, along the lines suggested by this draft.

Bruce

At 10:58 PM 11/18/99 -0800, Paul Leach (Exchange) wrote:
>
>
>> -----Original Message-----
>> From: Bruce Greenblatt [mailto:[email-masked]]
>> Sent: Thursday, November 18, 1999 7:49 PM
>
>> The question is, do you 
>> really think
>> that implementing a delete subtree is best implemented as a 
>> control?  It
>> seems so obvious to me that it isn't the best implementation.
>
>When you said it was just a matter of style, I took that to mean that you
>yourself thought that there wasn't much to choose between the two
>approaches.
>
>I agree that it could be done either way.
>
>We obviously thought that the control was the best/cleanest/most convenient
>implementation, because that's how we implemented it. It seemed to provide
>the maximum amount of code sharing between regular delete and tree delete.
> 
>> If you were
>> to have to change the definition from a yet to be 
>> standardized control to a
>> yet to be standardized extended operation, what do you 
>> believe the impact
>> would be on your product?
>
>We would have to throw away the existing implementation, for what appears to
>be mainly aesthetic improvements.
>
>Paul
>
>
>
==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com

---

From: Helmut Volpers <[email-masked]>
Date: Mon, 22 Nov 1999 08:37:42 +0100

Hi Bruce,

> LDAP applications that try to operate on an entire subtree.

I think you mean when you have a client operation delete_subtree which
make a big
search and then delete one entry after the other.
>   It is essential to have a progress bar move across the screen as the

A delete_subtree can be implemented by a server like a move (for
example)modifyDN with new superior.
You only need an additional access right for delete_subtree and it
should be
in one naming context in one server. So if you have the right to
delete_subtree
you can 
>   order to allow the operation to proceed.

I don't think so if you have the right to delete_subtree the server will
delete the
tree completely or it fails and the tree still exists.
>   think that it should be possible for the part of the subtree that is

I think all this is the client point of view what can happen if I search
the tree
and send a lot of delete operations.
>   client.  An incremental list of deleted entries could be returned with

That means if I delete a subtree of 100.000 I have to give back the
100.000 entries
to the user? A lot of applications will have problems with result-sizes
like that.
>   Search operation can be "abandoned".

And the server will have a consistent state. I don't like the idea of an
abondon to 
update operations. When I make a modifyDN with new superior (move) the
server
also say success (then the complete tree is moved) or noSuccess then
everything
should be as before of the operation.
>   example, delete all printer objects from the subtree.

Then put them in a special subtree.
Or what I prefer implement a client delete_subtree and you have all the
control
in the administrative client and you don't need to implement a
delete_subtree
in the server, because there are many cases where it is not easy to
check referential
integrity and other problems you can get with a operation like this. I
think making a 
modifyDn with new superior to a trash folder and then deleting the
subtree with
an administrative client should be possible with most server
implementations
and makes it easy.

Bye Helmut

---

From: Bruce Greenblatt <[email-masked]>
Date: Thu, 25 Nov 1999 23:08:43 -0800

>search and then delete one entry after the other.

I don't think that's what I mean...  Of course, with the standardized
operations at our disposal, that is the only way to delete a subtree right
now.

>in one naming context in one server. So if you have the right to

It is much easier to say that all you need to have is the additional access
right to "delete_subtree" than to get it implemented.  Currently, it is
possible to have different access control information attached to each
entry in the subtree being deleted.  I think that the modifyDN operation is
much different, as it leaves all of the entries in the subtree intact, and
only makes a change at the root of the subtree, since there is not really a
DN attribute for each entry.

>tree completely or it fails and the tree still exists.

This is certainly one perspective.  I tend to disagree.  I should be able
to have a delete subtree operation that has the same impact as if I had
performed a subtree search, and individually deleted all of the entries
that were returned.    It seems to me that to restrict the delete subtree
operation to only work when all of the entries are contained on a single
LDAP server, in which all of the entries are accessible to the one identity
severely limits its usefulness.  All that will result is to have an
operation that in general will rarely be able to work.

>and send a lot of delete operations.

So.  Is the client point of view, i.e. the designer of LDAP applications
not valid?

>to the user? A lot of applications will have problems with result-sizes

That's exactly the case.  This is the same problem that we have today in
the search operation.  We can apply the exact same logic and intelligence
in dealing with a delete subtree, as we do in dealing with a search subtree.

>should be as before of the operation.

As I said before, I don't think that the delete subtree and the ModifyDN
are analogous.  This is (should be) no big deal to do a rollback.
Databases have been doing this since the 70s.  The server should be able to
have a consistent state.

>an administrative client should be possible with most server

This is completely bogus.  I put entries in the tree in such a way that
they are easy for the administer to manage.  They are not placed in the
tree in such a way that they are easy for the LDAP server to delete.  For
example, if a printer is the one that is used by the technical writers, I
might put it in the tree in such a way that it is convenient to give rights
to the technical writers.  Each decision on DIT design is very dependent on
the environment, and the common operations and applications that make use
of the directory.  We shouldn't force LDAP designs into a particular
pattern so that a delete subtree is easy.  There's nothing wrong with
wanting to delete all of the entries in a subtree that meet certain
criteria.  I don't see how implementing such a problem would have an impact
on "referential integrity". 

>Attachment Converted: "C:\eudora\Attach\Helmut.Volpers9.vcf"
>