Re: increasing complexity - draft-ietf-ldapext-acl-model-08.txt

[Ryan Moats <rmoats@lemurnetworks.net>]

Finally having my arm twisted to read the latest ACI
draft and seeing these comments shortly after, here
are my thoughts:

> - instead of defining permissions which parallel LDAP
>   operations, define permissions based upon the type
>   of access being made.  That is, "write" permission
>   would be needed by subject to update a particular
>   target irregardless of what operation was used to
>   to request the update.

I don't have a problem with this as I'm beginning to
be concerned that and administrator will be confused
with the ACI.

> - return to one ACI attribute and handle entry/subtree
>   semantics via target scope in the value.  This scope
>   would be more easily extended to support non-entry
>   and non-subtree scopes (such as one-level, children,
>   etc.).

I'll have to think about this some more.

> - eliminate one of the syntax variants.  I suggest using
>   just a ASN.1 described syntax to be ";binary" transferred.
>   (a string representation of this could be separately defined
>   for presentation to users, if desired).

My reading of the document is that only string is MUST and
ASN.1 is MAY.  I disagree that string should only be separately
defined as administrators will have much greater difficulty
understanding the ASN.1 rather than the string representation.

> - remove all mention of ldapACIsubentry from the I-D and
>   generalize the out-of-scope statement to "prescriptive
>   ACIs and scoping via subenties is beyond the scope of
>   this document".

Again I have to think about this some more.

> - remove ipAddress and DNS subjects as they require special
>   semantics (as well as for the security considerations
>   separately noted).

While I'd like to, I believe that there are implementations
that are *already* using them.  This makes such a removal
difficult.

> - remove authnLevel.  Don't add integrity/confidentiality
>   factors.

Having read the draft, either the authnLevel should be
removed or just auth mechanisms listed.  The current proposed
bucketization of authnLevel is a receipe for interoperability
nightmares.

> - don't require recursive expansion of roles and groups
>   (implementation complexity).

No.  do require them as not expanding leads to administrative
complexity.  There will be a *lot* more administrators using
this than developers writing code and I'd rather add the
complexity in the branch that will be less utilized (here
implementation rather than administration)

Ryan