Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

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-bounces@ietf.org> On Behalf Of Kent Watsen
Sent: Wednesday, 23 March, 2022 23:07
To: Andy Bierman <andy@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 <andy@yumaworks.com<mailto:andy@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