Hello Kent, Andy,
I see more problems with an access control based immutable solution.
- user-dependency as Kent mentioned
- it is always possible to insert a new rule(set) at the beginning of the NACM
list that overrides other rules. We would need to ensure that these rules stay
the first
- there is a need to protect the access control rules protecting immutable data
nodes; then rules to protect the rules that protect the rules that protect ...
- access control can be switched off
- access control does not work for emergency sessions
- access control rules that reference different part of the systems are MUCH
more difficult to understand than a yang-extension statement immutable.
Especially if you have an access control list with many (hundreds of) rules
Regards Balazs
From: netmod <netmod-boun...@ietf.org> On Behalf Of Kent Watsen
Sent: Wednesday, 23 March, 2022 23:07
To: Andy Bierman <a...@yumaworks.com>
Cc: netmod@ietf.org
Subject: Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00
Hi Andy,
The draft allows individual data instance nodes (e.g., in a list) to be flagged
as immutable:
The following terms are defined in this document:
immutable: A metadata annotation indicating the immutability of a
data node. An immutable data node is read-only to clients. Note
that "immutable" is used to annotate instances of YANG data nodes
rather than schema nodes. For instance, a "list" data node may
exist in multiple instances in the data tree, "immutable" can
annotate some of the instances as read-only, while others are not.
If it were not for that, then an access-control refinement seems appropriate,
because then it would have to be user-specific, whereas this draft enables
user-independant immutability.
As for *why* this draft enables individual data instance nodes to be flagged as
immutable (a question asked in other recent review comments), please note that
this work came out of the "with-system" work after a number of folks (myself
included) noted that the concept was independent of a <system> datastore. For
instance, I defined a similar mechanism in a past life to handle objects
published from a host-system to logical-systems (LNEs).
The most common example for such a need is with interfaces, e.g., the
host-system publishes "eth-3.1.2" to a logical-system, where it is unable to
delete it (whereas it is deletable in the host-system's config). That said
(playing devil's advocate), I wonder if, in this example, the interfaces, when
published to a logical-system, should be published to the <system> datastore
(because they're effectively a system-defined resource then, from the LNE's
POV) and hence pickup their immutability that way.
Kent // contributor
On Mar 23, 2022, at 4:09 PM, Andy Bierman
<a...@yumaworks.com<mailto:a...@yumaworks.com>> wrote:
Hi,
IMO the problem should be viewed as a refinement to the
access control policy of the device. A standard mechanism
such as a YANG extension would be better than a growing
mix of proprietary solutions.
We have such a YANG extension called "user-write" that is widely deployed.
A simple boolean is not fine enough granularity, so a bits type is
needed instead to allow control of create, update, and delete access operations.
https://www.yumaworks.com/pub/latest/yangauto/yumapro-yangauto-guide.html#ncx-user-write<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-876c03f0bc610d95&q=1&e=6f7b65a8-ff22-4196-88eb-2eef36f59178&u=https%3A%2F%2Fwww.yumaworks.com%2Fpub%2Flatest%2Fyangauto%2Fyumapro-yangauto-guide.html%23ncx-user-write>
Andy
_______________________________________________
netmod mailing list
netmod@ietf.org<mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
