ldap acl draft(06): browse permission needed ?

[rbyrne@odin.France.Sun.COM (Rob Byrne - Sun Microsystems)]

In the current acl draft (06) there is a browse permssion proposed and in the discussion at Pittsburgh
people seemed to like it. 
To recap, this permssion is revelvant to the search operation only and the idea is to be able to define a policy whereby you are
only returned entries that you explicitly name.  So, to give a specific example, in a tree with a flat name space, where the entries 
did not have this permission then you could do base searches at individual entries but if you went up a level and
did a subtree search, you would see nothing.  So you can see this permssion as a way to still allow limited access but to kind of put a break on the 
search operation.

I have some proposals for working this into the current draft but it is trickier than just having a simple
"read" permssion on all entries.  In fact I think that when you start to use a browse permssion you also need another to protect the
base of the search too.

It's all doable but don't forget the search already has to deal with filter permssions, attribute level permssion,
returnDN (for aliases) and the infamous discloseOnError permission.  You've probably guessed my inclination is to just define one "read" 
permssion at the entry level--the reasons are ease of definition and ease of administration.  My question is do people still feel the
extra granularity of the browse permssion is needed and if so, please provide a compelling deployment scenario.

If people don't come back and say "We really need this" then my plan is to drop it for the 07 draft...if they do then I'll work
in a proposal, using your scenario as a motivating example (so you will be on the hook too!)

Rob.