Re: max-access: access control model discussion

["Tom Petch" <nwnetworks@dial.pipex.com>]

<inline>

Tom Petch

----- Original Message -----
From: "Andy Bierman" <ietf@andybierman.com>
To: "Netconf Data Model Discussion" <netconfmodel@lists.nortel.com>
Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>; "Netconf Data Model Discussion"
<netconfmodel@lists.nortel.com>
Sent: Tuesday, May 23, 2006 10:00 PM
Subject: Re: max-access: access control model discussion


> Sharon Chisholm wrote:
> >
> > 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.
>
Agree strongly.  Of course we can come up with something more sophisticated,
perhaps we can produce something noticeably better, but there is much to be said
in engineering for the reuse of familiar building bricks that have stood the
test of time, and have not, AFAIK, been the subject of significant criticism.
It is not, for me, a question of wanting to reuse MIB modules written in SMIv2,
but having a good concept that is worth perpetuating.

This logic equally says if there is a better model elsewhere, perhaps in the
libraries of ITU-T, then I would support the use of that but, AFAIK, there is
not.

Tom Petch

<snip>


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