RE: max-access: access control model discussion

["Sharon Chisholm" <schishol@nortel.com>]

hi

This seems much more complicated then what is in the draft. I prefer the
approach of defining a list of values rather then enumerating all the
combinations and permutations of the items in the list as unique values.


The draft considers notification another form of reading. I believe all
the other values are covered.

Sharon

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Andy Bierman
Sent: Friday, May 19, 2006 2:49 PM
To: Netconf (E-mail); Netconf Data Model Discussion
Subject: max-access: access control model discussion


Hi,

This discussion is somewhat out of charter scope, but since access
control for notifications and data models keeps coming up, I think we
should discuss the basics.

IMO, the max-access mechanism in the draft is too complicated, and it
doesn't account for all operation attribute and SMI MAX-ACCESS
enumerations.  I also don't understand the preference for making the XML
as complicated as possible. I prefer simple as possible, and reusing as
much SMI as possible (without breaking netconf ;-)

Here is a snippet from the draft as an example:

 <xs:appinfo>
   <nm:minAccess><read/></nm:minAccess>
   <nm:maxAccess><read/> <write/> <create/> <delete/></nm:maxAccess>
</xs:appinfo>

========================================================================
=======
Here is something to throw darts at:

I have created a hierarchical max-access enumeration,
similar to the one in SMIv2, except it adds a few
enumerations for well-known 'mid-states' which can only
be defined in DESCRIPTION clauses.


The hierarchy is:

notify-only: object can appear in a /notification/data element 
       (SMI: notify-only)

read-only: notify + object can be retrieved in any type of
       read operation  (SMI: read-only)

write-only: object can be written only if it already exists.
       No read access at all -- agent created objects for passwords,
etc.
       (SMI: write-only)

create-only: object can be created and deleted, but not edited or read.
        For passwords, etc. in dynamic objects.
        (SMI: read-create + DESCRIPTION says no read or edit if 
rowStatus=active)

read-write: notify + read + object can be edited if it already exists
        (SMI: read-write)

read-create: notify + read + object can be created and deleted, but not 
edited.
        (SMI: read-create + DESCRIPTION says no edit if
rowStatus=active)
        (I know this name is confusing...)

read-create-edit: notify + read + create/delete + edit
        (SMI: read-create) (alias 'all' also accepted)
  

Mapping to the Operation Attribute
----------------------------------

Key:  name : allowed max-access values (to permit the operation)


none : any value

merge: if object currently exists:
         write-only, read-write, all
       otherwise:
         create-only, read-create, all

replace: create-only, read-create, all

create:  create-only, read-create, all

delete: same as create


I've implemented this, and the code really is as easy
as the little table above suggests. This algorithm
treats a replace as a delete+create, so it doesn't
work for static (write-only or read-write) objects.
This keeps the code simpler, but is more restrictive.
Maybe too restrictive, I don't know yet.



Andy


--
to unsubscribe send a message to netconf-request@ops.ietf.org with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>