max-access: access control model discussion

[Andy Bierman <ietf@andybierman.com>]

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/>