[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: max-access: access control model discussion

Sharon Chisholm wrote:

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.





What is in the draft is rather under-specified.

Forget my "extended MAX-ACCESS".  That was a mistake.
Think of the MAX-ACCESS clause exactly as defined in SMIv2 instead.

The real issue is whether the application of SMIv2 MIB modules
for use in the NETCONF protocol is of any interest whatsoever.
If so, then a mapping of the MAX-ACCESS clause to
the NETCONF protocol operations is required.
The operations 'notify' and 'read' are easy.
The other operations (merge, replace, create, delete)
are not as easy.  There are plenty of interesting
corner-cases where 'merge' and 'replace' do not behave
the same wrt/ access control (or function).

IMO, it would be better to use 1 MAX-ACCESS string
per clause, and use the enumerated values from SMIv2 MAX-ACCESS.
Normative text describing the mapping to the NETCONF protocol
is also needed. This small amount of reuse would be a step in the
right direction.




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



Operational experience with SNMP has shown that sometimes
there is a need to define data that is sent in a notification
but not stored in the agent as retrievable data.
That's why 'notify-only' was added to SMIv2.


Sharon


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