Thanks for your responses.
There were two questions:
1. why can't we have generic filters to define the scope of subentries
?
2. what is so great about subentries anyway ?
For the first question, we have the following comments.
[Ron]
I can so no purpose either for a general filter in a subentry of for scopes in entry ACI. The problem with the former is that, if the filter relates to telephoneNumber, for example, and the user deletes this attribute from his entry, the ACI may now behave unpredictably.
Ron, in our LDAP server
we provide this as a way to define entries to which acis apply and this
feature is used. The effect is not unpredictable--the behaviour of
filters is well defined. Though I agree that if the admin does not
define his policy well, the effect may be unexpected. I think that
the use of this feature provides flexibilty but demands good management
by the admin--I guess it's a trade off.
[Albert]
LDAP standards must not unnecessarily limit implementation choices. Filter specifications on object classes work with either model, since every entry knows its object classes and can easily calculate an arbitrary filter on them quickly when determining visibility during searches.
Albert, doesn't an entry know the other attributes that it contains
as well and so could evaluate an arbitrary filter ?
General filters really only work with a traversal based implementation and are basically just an attempt to substitute regexp evaluation on path names familiar to centralized web administrators for a serious admin model that can actually be delegated. The apparant additional flexibility is illusory since it
Don't catch this--a general filter refers to values of attributes
within the entry, not the dn of the entry. As I pointed out above,
users of our directory make use of this "illusion" all the time.
For the second question, "what is so great about using subentries for acis?", I think Alan's response was clearest. For my own benefit I've tried to distill (quite a lot!) the main points to the points listed below. I don't dispute them, but I would say that the "aci attribute" approach also allows seperation (it's an operational attribute) and delegation (you've got rights to that attribute or not)...though not to the same extent as the subentry approach.
. the principal of seperating security information from that which it
protects
is a good one and in particular, an aci in a subentry is "more seperate" than
an aci in a user entry.
. for delegation, the admin point/subentry approach offers more "levels of delegation" because there are more components to it (admin points, subentries and subEntryACI to protect subentries versus a single attribute).
. for distribution, if acis are clearly identified in subentries, then
it is
easier to propagate this aci information to subordinate systems (if
required) than if it is distributed among the user entries.
Rob.