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 <[email protected]> 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://www.yumaworks.com/pub/latest/yangauto/yumapro-yangauto-guide.html#ncx-user-write>
>
>
> Andy
>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod