Subject: vendorACI attribute in draft-ietf-ldapext-acl-model-04.txt

From: "David Ward" <[email-masked]>
Date: Thu, 14 Oct 1999 09:53:59 -0600

What value does the vendorACI attribute add?  It appears to be a placeholder vendors can use for proprietary aci information. However, the model already allows vendors to define their own access control mechanisms ( section 5.1 ).  In my opionion, having vendors define specific access control mechanisms, is better than stuffing everything into a vendorACI printable string attribute.  I think the attribute should be dropped.

David

---

From: Ellen Stokes <[email-masked]>
Date: Thu, 14 Oct 1999 19:38:05 -0500

David,
The intent of vendorACI is to provide a way in which to allow non-LDAP
defined ACI to appear in LDIF, so if you dump the directory into LDIF
and then reload into another vendor's server and back again into your
server, you don't lose any data.  Vendors will continue to use their
own access control mechanisms in cases, so it is expected that in some
parts of the tree that may not be ldap accessible that you'll see the
use of aCIMechanism, and hence vendorACI for preservation of that
information at dump/restore time.
The vendorACI attribute will remain in the model.
Ellen

At 09:53 AM 10/14/1999 -0600, David Ward wrote:
>What value does the vendorACI attribute add?  It appears to be a
placeholder vendors can use for proprietary aci information. However, the
model already allows vendors to define their own access control mechanisms
( section 5.1 ).  In my opionion, having vendors define specific access
control mechanisms, is better than stuffing everything into a vendorACI
printable string attribute.  I think the attribute should be dropped.

---

From: Mark Smith <[email-masked]>
Date: Fri, 15 Oct 1999 09:09:57 -0400

> The vendorACI attribute will remain in the model.

I don't quite follow you on this Ellen.  Shouldn't a specific,
alternative aCIMechanism indicate what attribute is used to store the
alternative ACI mechanism (even if only for export and import)?

-- 
Mark Smith
iPlanet Directory Architect / Sun-Netscape Alliance
My words are my own, not my employer's.   Got LDAP?

---

From: Ellen Stokes <[email-masked]>
Date: Tue, 19 Oct 1999 04:25:17 -0500

Mark,
Currently, aCIMechanism is just a list of OIDs of access control mechanisms
supported in a given naming context. Are you proposing that we extend this
format to say a structured LDAPstring to indicate not only the mechanism but
the attibutes associated with that mechanism?
Ellen

---

From: Mark Smith <[email-masked]>
Date: Tue, 19 Oct 1999 09:42:12 -0400

No, I don't think we should specify the attribute type for access
control information at all (except for the LDAPv3 scheme).  In other
words, the aCIMechanism should just specify the OID for a scheme and
clients and servers that have knowledge of a particular scheme will just
need to know what attribute type is used for storing the access control
information.  I just don't think we can mandate use of a particular type
like vendorACI.  Some schemes may use more than one attribute type.  And
so on.

---

From: Ellen Stokes <[email-masked]>
Date: Tue, 19 Oct 1999 23:51:22 -0500

Mark,
Great.  I'm happy to remove vendorACI and keep aCIMechanism as defined
in the document.  (I just wanted to explore the alternatives given your
previous suggestion).
Ellen