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

From: Bruce Greenblatt <[email-masked]>
Date: Thu, 18 Nov 1999 09:53:04 -0800

At 09:01 AM 11/18/99 -0800, Michael Armijo (Exchange) wrote:
>I do not understand the reasoning for not using a control to extend the
>delete operation for handling a tree delete.  LDAPEXT has traditionally used
>controls to extend or enhance existing operations (Search, VLV).  A control
>here seems obvious and beneficial to the general LDAPv3 community.
>

Whether it's a control or an extended operation doesn't seem to have any
impact on whether it is beneficial to the general LDAPv3 community.  

What LDAPEXT has traditionally done is to use both controls and extended
operations as they see fit, with relatively little guidance from the base
RFCs.  My reasoning for preferring an extended operation over a control is
that I believe that applying the delete operation to the subtree is a
substantial implementation change to the underlying operation.  In the case
of the paged results or sort controls, the implementation of the search
operation is not materially affected. Conceptually, these controls just
change the way in which the results are returned to the LDAP client.  

In the case of the Start and Stop TLS operations, these are implemented as
extended operations.  There is no real protocol specific reason why they
could not have been implemented as controls that affect all existing
operations.  It is really jsut a matter of style.  Back to the Delete
subtree operation.  In the case of a vanilla Delete operation, it affects
only one object, only one access control decision must be made, and only
one result needs to be returned.

Not only may this control affect numerous objects, spread across who knows
how many DSAs, depending on the implementation, numerous access control
decisions must be made at various points in the subtree, not all of which
may be known at the root of the subtree.  Furthermore, as this is a long
lived operation, which may take many hours to complete, it is likely that
substantially greater feedback and interaction will be required than is
possible with the Delete operation.  I could go on with more, but suffice
it to say that I think that the implementation of subtree operations can be
very complex.  Just saying that a DSA can deny the operation isn't likely
to be the answer.  

Bruce

>Bruce said:
>"It seems to me that the handling of a
>subtree delete that may span across multiple DSAs (aka LDAP servers) must
>be substantially different than the handling of a delete for a single
>object which normally can be implemented by a single DSA."
>
>Agreed.  The tree delete draft takes this into account and allows the server
>to deny the operation if it is not authoritative for any object(s) in the
>scope of the delete.
>
>I do not believe we should tie this functionality to other subtree
>operations.  This would limit the adoption of the base functionality of
>allowing a client to submit a delete request of a subtree.
>
>
>-----Original Message-----
>From: Bruce Greenblatt [mailto:[email-masked]]
>Sent: Thursday, November 18, 1999 8:36 AM
>To: Michael Armijo (Exchange)
>Cc: [email-masked]
>Subject: Re: FW: I-D ACTION:draft-armijo-ldap-treedelete-02.txt
>
>
>Michael,
>
>There was an exchange seeral months back about this.  I still think that
>these type of operations are better implemented as extended operations than
>as controls to existing operations.  It seems to me that the handling of a
>subtree delete that may span across multiple DSAs (aka LDAP servers) must
>be substantially different than the handling of a delete for a single
>object which normally can be implemented by a single DSA.  My thinking is
>that if a control might substantially change how an operation is
>implemented by a DSA, it should be implemented as a control.  So, I believe
>that the extended operations that I proposed in:
>http://search.ietf.org/internet-drafts/draft-greenblatt-ldapext-sos-00.txt
>are beneficial for server and client implementations of LDAP and should be
>progressed on the standards track.  
>
>What do people think?  Should this be a control or an extended operation?
>Are the other two operations that I proposed useful as well (subtree copy
>and subtree modify).
>
>Bruce
>
>At 10:46 AM 11/17/99 -0800, you wrote:
>>Please review the attached draft on a Tree Delete control for LDAPv3.  
>>
>>I believe this control is beneficial for server and client implementations
>>of LDAP and should be progressed on the standards-track.  Please send
>>comments on this draft to the LDAPEXT discussion list.
>>
>>WG Chairs:  It was previously decided that this list is the best place to
>>discuss this draft.  If consensus can be reached on this draft, I would
>like
>>to see it progressed through this WG.
>>
>>thanks,
>>Michael
>
>
>
==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com

---

From: [email-masked] (David Boreham)
Date: Thu, 18 Nov 1999 10:13:25 -0800

> impact on whether it is beneficial to the general LDAPv3 community.

etc.

FWIW it didn't much matter to me whether this is a control on
a regular delete operation or a new operation. Both cost me
about the same to implement.

However, reading Bruce's most recent argument for the
extended operation, I'm inclined to agree. This isn't so
much a subtle modifier to the delete operation than
a completely new variety of operation.

But, I don't feel so strongly about this that, for example,
I'd want to make the standard specify an extended operation
when one major vendor had already shipped a product which
implemented the control. That would, I expect, cost that
vendor much to change their code, and bring everyone else little
practical benefit.

I would like to hear more about how this operation
is to be replicated.