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

Re: please publish (draft-ietf-ldapext-acl-model-05.txt)

At 12:51 AM 3/16/00 -0000, David Chadwick wrote:
>Date forwarded: 	Wed, 15 Mar 2000 08:16:23 -0800 (PST)
>Date sent:      	Wed, 15 Mar 2000 10:15:28 -0600
>To:             	d.w.chadwick@salford.ac.uk, ietf-ldapext@netscape.com
>From:           	Ellen Stokes <stokes@austin.ibm.com>
>Subject:        	Re: please publish (draft-ietf-ldapext-acl-model-05.txt)
>Copies to:      	djbyrne@us.ibm.com, blakley@dascom.com
>Forwarded by:   	ietf-ldapext@netscape.com
>
>> Responses embedded below and prefaced by (EJS)
>> Ellen
>>
>> >Comments on ACL model 05
>> >
>> >i) I think it is extra clutter to have familyOID as the first
>> >component of the ldapACI attribute type, and does not buy us
>> >anything. If you want to define another set of permissions, then
>> >simply give them a new attribute type (e.g. ldapACIv2) which is
>> >itself an OID. It serves no good purpose to have one OID for the
>> >ldapACI attribute then another OID for the family. You might as well
>> >have just one OID that means precisely one set of permissions and
>> >access control information.
>> 
>> (EJS) We could do as you suggest, but I'd rather not.  I believe that
>> it is better to have a single attribute known for ldap access control
>> rather than proliferate more attributes for this purpose and let the
>> family OID control  the remaining information.  This provides an
>> application with one way of accessing access control information,
>> although it may still have to parse out the information. If we start
>> propagating different attributes for ldap access control, then it is
>> difficult, if not impossible, for the application to know which ldap
>> access control attribute it needs to invoke.
>
>Sorry, I dont buy this, since the application will have to know all the 
>family OIDs if it is to be able to understand the meaning and content 
>of the aci. There is thus no difference between having to know the 
>OIDs of families or the OIDs of the attribute types. You have not 
>saved anything by nesting families in a single attribute type (other 
>than forcing them to all have the same syntax). Different code will be 
>needed for each family OID, just as different code will be needed if 
>it were different attribute types. Therefore I still believe the family 
>OID is just extra clutter that actually buys you nothing.

I concur with David.  In particular, I do not think the ACI families
we conjure up tomorrow should be limited to today's attribute type
definition.  Tomorrow's ACI families may require unthought of
syntaxes and matching rules.

>> >v) In my comments to version 4, I mentioned that delete permission
>> >for attribute values could be needed, as with Modify Entry you both
>> >add values and delete values and replace values (I took your write
>> >values permission to mean add). With separate permissions you can
>> >allow some people to add, some to delete, and some to do both. You
>> >said you would look into it, but I don't remember your reply to this.
>> >I would suggest changing "write" to "add", and adding "delete".
>> 
>> (EJS) The write (w) permission is for the ldap_modify operation where
>> that single operation allows add, delete, and replace.  We can
>> certainly change this so that write permission is broken into two
>> permissions (add and delete) where replace requires both add and
>> delete.  Proposed permissions for this change are 'w' for write/add
>> and 'o' for write/delete (obliterate) where write/replace operation
>> requires both w and o to be set.  The question in doing this is do
>> people/applications really make this fine of a distinction in write
>> permissions, for example where someone may write/add but not
>> write/delete (and vice-versa)? Comments?  What's the consensus here?
>
>Ellen I think this is the best way forward, to see what people actually 
>want. I was raising the topic for precisely that reason.

Personally, I'd prefer attribute modify operation be control by a
single permission.  However, if the consensus is to have finer grained
control, I suggest breaking into three permissions which relate directly
to modify/add, modify/replace, and modify/delete operations.

>> >vi) Why can an acl entry only confer multiple rights on a single
>> >attribute name. I would have expected <attr> to allow multiple
>> >attribute names within it. (Version 4 allowed this.) Your later
>> >example shows the ldapACI being repeated in order to give SysAdmins
>> >access to attr2 and attr3. Why was the restriction introduced?
>> 
>> (EJS)  Several people complained that the syntax was too complicated
>> and hence the restriction.  We can certainly remove the restriction so
>> attribute: can have one or more attributes.  So you can then specify a
>> grouping of attributes by collection: <collectionname> or by
>> attribute: <attr>*. Comments?  What's the consensus here?
>
>Again this seems to be the best way forward, lets get some opinions. 
>I would argue for allowing multiple attribute types, rather than 
>inventing a new collectionname that is only locally known and has to 
>be broadcase to applications for them to understand it.

I think a list of attributes should be allowed and that collections
concept dropped.