RE: max-access: access control model discussion

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

hi

Oh, and I should note that in SNMP MIB consulting I strongly advised
against people using accessible-for-notify parameters. These cause a lot
of problems when used, most notably trying to transition to a case where
you realize that actually you do want to be able to poll this
information.

I'd prefer we not reproduce this 'feature' in Netconf.

Sharon

-----Original Message-----
From: Chisholm, Sharon [CAR:ZZ00:EXCH] 
Sent: Monday, May 29, 2006 10:04 AM
To: 'Netconf Data Model Discussion'; 'Netconf (E-mail)'
Subject: RE: max-access: access control model discussion


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:ietf@andybierman.com] 
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 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/>