Subject: RE: max-access: access control model discussion

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 29 May 2006 10:03:34 -0400

hi

I don't think there is any requirement to support a mapping of the SMIv2
max-access clause in Netconf. What there is a requirement to be able to
specify which operations make operational for a particular data element.
We should define this to be only what we need for Netconf.

Sharon

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Tuesday, May 23, 2006 4:01 PM
To: Netconf Data Model Discussion
Cc: Netconf (E-mail); Netconf Data Model Discussion
Subject: 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 29 May 2006 07:17:50 -0700

> We should define this to be only what we need for Netconf.

No requirement.
As I said, it is only important if one ever plans to reuse
any SMIv2 data models in NETCONF.  If you are planning on
ignoring almost two decades of IETF data modeling work,
this is not important.

Andy