access control mechanisms

[Andy Bierman <ietf@andybierman.com>]

Hi,

I am very concerned about the <maxAccess> and <minAccess>
constructs in the Notifications draft.  This document
needs to be clean (in both design and references) in
order for the publication process to go smoothly.

In my previous comments I said that <maxAccess> would
be OK iff we could agree on the enumerated values.

Now I realize that we will be backing into an ad-hoc
undefined access control model if this is done.

The only real requirement that can be derived from
the NETCONF documents is the ability to distinguish
configuration data from other data.  The requirement
for a machine-friendly mechanism (in addition to the
DESCRIPTION clause) is nice-to-have, but not critical.

Therefore, I suggest we either create no <appInfo>
extension for this purpose, or create something other
than <maxAccess>.

For example:

 appInfo Extension: <config-data> (type boolean)

 Values:

   true:  The data construct is classified as configuration data.

   false: The data construct is not classified as configuration data.

IMO, we do not need to say any more than this before the data modeling
work is officially started. A <maxAccess> extension can then be added
later as part of a coherent and fully documented access control model.


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