Subject: ACL model comments

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 14 Feb 2000 21:57:08 -0800

Though I haven't had time to do a full review, I can offer
a few comments:

Section 6.3

The 'aci' attribute is defined as a user, not operational,
attribute type.  Besides being appropriate in terms of usage,
this would allow this attribute type in any and all
object classes.  If usage is left as user, you'd likely
have to define an auxiliary objectclass to allow mix in
or replace 'top' or something.

The EQUALITY matching rule should be specific to the ACI
Syntax and able to determine that that two strings, not
equal by caseExactMatch, yet same per the ACI syntax.

For example:
    aci: 1.2.3.4#subtree#grant;r;cn#group#cn=Dept XYZ
    aci: 1.2.3.5#subtree#grant;r;2.5.4.3#group#cn=Dept XYZ

(cn == 2.5.4.3)

Section 6.3.1  LDAP Operations (Modify/delete)
    Deleting the last ACI value from an entry is not the same as
    deleting the ACI from the entry.

This seems to imply behavior inconsistent with RFC 2251, 4.6.
    It is possible for an entry to contain an ACI with no values.

An attribute type, if instatiated, must have values.  Though
you state not storage means, I believe it important to follow
the basic LDAP information model to ensure the information
is representatable by the protocol and interchange formats.

Section 6.4.2
         Replace works similarly to all other attributes.

This implies that other modifications do not work similiarly to
all other attributes.  I believe that all modifications should be
consistent with the defined semantics of Modify operation.

6.5 VendorACI

Like 'aci', it should be operational.  Also, it should have a
matching rule defined which understands how to match strings
of vendor ACI syntax.  Defining this seems problematic, but
could be be defined, I guess, in generic terms.  Howeer, if
the directory contains vendorACIs from multiple vendors, you
have a problem.  But these problems exist even as presently
defined.  I suggest not defining this and just stating that
vendors can define their own attribute types to contain
Access Control Information.  They'll like do this anyways.

---

From: [email-masked] (Mark C Smith)
Date: Thu, 17 Feb 2000 14:06:34 -0500

> or replace 'top' or something.

I agree that the attribute type used to store access control information
should be operational.  X.500's various access control attribute types
are defined with "USAGE directoryOperation" which seems right to me.

I would also like to see us choose a different name for the attribute
type.  An attribute called 'aci' has been used in the Netscape/iPlanet
Directory Server for several years now to hold proprietary access
control information.  See:

http://home.netscape.com/eng/server/directory/schema/attribu4.htm#1717762

I admit that 'aci' was not a good name for Netscape to use, but I
suggest we use a name like 'ldapACI' for the new standard scheme to
avoid confusion (unless someone else is already using that name too!).

-- 
Mark Smith
Directory Product Development / iPlanet E-Commerce Solutions
My words are my own, not my employer's.            Got LDAP?

---

From: Mark Wahl <[email-masked]>
Date: Tue, 22 Feb 2000 15:03:28 -0600

> are defined with "USAGE directoryOperation" which seems right to me.

I'd agree with that.  This usually indicates that it is used by the directory
service itself, is replicated with user attributes (not server specific), 
and may be modifiable oer protocol.

> avoid confusion (unless someone else is already using that name too!).

I've seen aci, acl, subtreeacl, searchacl, but haven't seen ldapACL yet.

Mark Wahl, Directory Product Architect
Innosoft International, Inc.