[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Objections to draft-ietf-ldapext-psearch-01.txt

Alan Lloyd wrote:
protocol feature or not , just never occured to me. I suppose because it
polutes the Users DIT.
Can't have it both ways. The DIT's there for storing stuff inand getting at it. Mine, yours, theirs.
Do you have access control regimes for these entries as well?
Yes. (and an access control regime for the regime :)
Do you include these entries in  LDAP replication processes? what about
Not at present.
the scope of transaction resource locking and timing out. Does the
We don't expose transactions over the protocol.In our implementation this part of the DIT is stored
in a different place, using different storage technology
than the rest of the DIT. This is more of an implementation
convenience than anything else though.
"features" entries fit under country, org, OU, OP, OR or anywhere?
It goes under the root in our implementation.Once replication comes into play, I expect
it would be useful to put it somewhere else in
the DIT. That's for future work.
I suppose that if the LDAP protocol extensions need to be controlled by
proprietary DIT structures and user access control mechanisms -  does
that mean that the LDAP extensions are by definition "proprietary"..
No. <Insert standard story on access control here>
Will support standard when it's defined, the thing
we have now is openly documented, blah, blah.

To get more serious for an instant: the neat
thing about representing the ability to use a
particular feature, in terms of the ability to access
a particular corresponding DIT entry, is that
it's independent of the access control mechanism,
and to a great extent the access control model
employed. You only need answer the question
"can this entity access that entry".