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

From: Andy Bierman <[email-masked]>
Date: Wed, 23 Mar 2022 13:09:49 -0700

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

Andy

---

From: Balázs Lengyel <[email-masked]>
Date: Wed, 23 Mar 2022 21:15:58 +0000

Hello Andy,
I also propose an extension. (see my mail Review of draft-ma-netmod-immutable-flag-00)
In Ericsson we saw no need for exceptions, but do see the need for applying it to descendant nodes. Typically we need to protect a full subtree.

Why do you need the exceptions? Could you provide some use-case examples ?
Regards Balazs

From: netmod <[email-masked]> On Behalf Of Andy Bierman
Sent: Wednesday, 23 March, 2022 21:10
To: NetMod WG <[email-masked]>
Subject: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

Hi,

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=c875257e-41f5-45d6-a9e9-871e5ebb4243&u=https%3A%2F%2Fwww.yumaworks.com%2Fpub%2Flatest%2Fyangauto%2Fyumapro-yangauto-guide.html%23ncx-user-write>

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 23 Mar 2022 14:32:21 -0700

On Wed, Mar 23, 2022 at 2:16 PM Balázs Lengyel <[email-masked]>
wrote:

> In Ericsson we saw no need for exceptions, but do see the need for
> applying it to descendant nodes. Typically we need to protect a full
> subtree.
>
>
>

I think create/delete-only and modify-only access modes are used the most,
after no-access.
Applying to descendant nodes may be better, or may require more work to
undo the extension used in an ancestor node. This impacts the extension
usage within a grouping.

Regards Balazs

Andy

>
>
> *From:* netmod <[email-masked]> *On Behalf Of *Andy Bierman
> *Sent:* Wednesday, 23 March, 2022 21:10
> *To:* NetMod WG <[email-masked]>
> *Subject:* [netmod] Alternative approach to
> draft-ma-netmod-immutable-flag-00
>
>
>
> Hi,
>
>
>
> <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-876c03f0bc610d95&q=1&e=c875257e-41f5-45d6-a9e9-871e5ebb4243&u=https%3A%2F%2Fwww.yumaworks.com%2Fpub%2Flatest%2Fyangauto%2Fyumapro-yangauto-guide.html%23ncx-user-write>
>
>
>
>
>
> Andy
>
>
>

---

From: Balázs Lengyel <[email-masked]>
Date: Wed, 23 Mar 2022 22:05:58 +0000

From: Andy Bierman <[email-masked]>
Sent: Wednesday, 23 March, 2022 22:32
To: Balázs Lengyel <[email-masked]>
Cc: NetMod WG <[email-masked]>
Subject: Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

On Wed, Mar 23, 2022 at 2:16 PM Balázs Lengyel <[email-masked]<mailto:[email-masked]>> wrote:
Hello Andy,
I also propose an extension. (see my mail Review of draft-ma-netmod-immutable-flag-00)
In Ericsson we saw no need for exceptions, but do see the need for applying it to descendant nodes. Typically we need to protect a full subtree.

I think create/delete-only and modify-only access modes are used the most, after no-access.
BALAZS: How is a modify-only data-node different from a mandatory data-node? It must be there but can be changed. It get’s an initial value somehow.
BALAZS: Any examples when would a create/delete only data node be used?

Applying to descendant nodes may be better, or may require more work to
undo the extension used in an ancestor node. This impacts the extension usage within a grouping.

BALAZS2: I did not include it in my mail, but we actually have one more rule:
“Top level statements in augment or groupings do NOT inherit
       the static-data value from containing nodes, they default to
       static-data false.”

Regards Balazs

Andy

From: netmod <[email-masked]<mailto:[email-masked]>> On Behalf Of Andy Bierman
Sent: Wednesday, 23 March, 2022 21:10
To: NetMod WG <[email-masked]<mailto:[email-masked]>>
Subject: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

Hi,

Andy

---

From: Kent Watsen <[email-masked]>
Date: Wed, 23 Mar 2022 22:07:13 +0000

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-masked]> wrote:
> 
> Hi,
> 
> 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-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Balázs Lengyel <[email-masked]>
Date: Wed, 23 Mar 2022 22:22:13 +0000

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 <[email-masked]> On Behalf Of Kent Watsen
Sent: Wednesday, 23 March, 2022 23:07
To: Andy Bierman <[email-masked]>
Cc: [email-masked]
Subject: Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

Hi Andy,

Kent // contributor

On Mar 23, 2022, at 4:09 PM, Andy Bierman <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Wed, 23 Mar 2022 16:13:31 -0700

On Wed, Mar 23, 2022 at 3:06 PM Balázs Lengyel <[email-masked]>
wrote:

>
>
>
>
> *From:* Andy Bierman <[email-masked]>
> *Sent:* Wednesday, 23 March, 2022 22:32
> *To:* Balázs Lengyel <[email-masked]>
> *Cc:* NetMod WG <[email-masked]>
> *Subject:* Re: [netmod] Alternative approach to
> On Wed, Mar 23, 2022 at 2:16 PM Balázs Lengyel <
> [email-masked]> wrote:
>
> Hello Andy,
>
> BALAZS: How is a modify-only data-node different from a mandatory
> data-node? It must be there but can be changed. It get’s an initial value
> somehow.
>

Mandatory=true requires the system to provide a value.
Modify-only allows the system to decide when an instance is created.

> BALAZS: Any examples when would a create/delete only data node be used?

Sometimes developers do not want to write complex instrumentation that
supports
modification of resources.  Instead a user has to delete the old entry and
create a new
one with (potentially) different parameters.

>        the static-data value from containing nodes, they default to

This seems complicated to users and developers to track how the final
schema tree was derived.

The 'static-data' extension seems fine to me.
We have to support 'user-write' anyways, so it is better if it is not too
close to this extension.
Things that seem the same, but are NOT the same cause the most support
tickets.

Andy

---

From: "maqiufang (A)" <[email-masked]>
Date: Thu, 24 Mar 2022 14:22:42 +0000

Hi, Andy, Balazs,

I can see your points in some of the use cases.
But as Kent mentioned, the motivation of this work is that we have some system-defined instance which are read-only to clients.
And there may be some cases where a list/leaf-list data node may exist in multiple instances with different control rules.

To be specific, An instance-level annotation could be useful in following use cases:

a)       The system generates some QoS templates when QoS functionality is enabled, and some of the generated templates are read-only, while others are free to be updated by the clients.

b)       The system predefines some list/leaf-list instances which are read-only for clients(the clients cannot update or delete them, like predefined NACM rules), but the clients is free to add/update/delete their own defined instances.

While YANG-extension can be useful for a schema-level immutability.
I am thinking that, maybe we need both to complete the solution?

Best Regards,
Qiufang

From: netmod [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Thursday, March 24, 2022 7:14 AM
To: Balázs Lengyel <[email-masked]>
Cc: NetMod WG <[email-masked]>
Subject: Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

On Wed, Mar 23, 2022 at 3:06 PM Balázs Lengyel <[email-masked]<mailto:[email-masked]>> wrote:

From: Andy Bierman <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, 23 March, 2022 22:32
To: Balázs Lengyel <[email-masked]<mailto:[email-masked]>>
Cc: NetMod WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

Sometimes developers do not want to write complex instrumentation that supports
modification of resources.  Instead a user has to delete the old entry and create a new
one with (potentially) different parameters.

This seems complicated to users and developers to track how the final schema tree was derived.

The 'static-data' extension seems fine to me.
We have to support 'user-write' anyways, so it is better if it is not too close to this extension.
Things that seem the same, but are NOT the same cause the most support tickets.

Regards Balazs

Andy

Andy

Hi,

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 24 Mar 2022 08:13:12 -0700

On Thu, Mar 24, 2022 at 7:22 AM maqiufang (A) <[email-masked]> wrote:

> But as Kent mentioned, the motivation of this work is that we have some
> system-defined instance which are read-only to clients.
>
> And there may be some cases where a list/leaf-list data node may exist in
> multiple instances with different control rules.
>
>
>
> a)       The system generates some QoS templates when QoS functionality
> is enabled, and some of the generated templates are read-only, while others
> are free to be updated by the clients.
>
> b)       The system predefines some list/leaf-list instances which are
> read-only for clients(the clients cannot update or delete them, like
> predefined NACM rules), but the clients is free to add/update/delete their
> own defined instances.
>
>
>

IMO the instance-level is not interesting and should not be standardized.
The only common usage seems to be a simple boolean flag.
It looks like access control to me because it is access control.
If an operator created NACM rules allowing client access to a static node,
then the NACM config would be ignored and the operator would be confused.
This problem exists no matter what external (AND PURELY OPTIONAL) statement
is used.

Andy

>
>
> *From:* netmod [mailto:[email-masked]] *On Behalf Of *Andy
> Bierman
> *Sent:* Thursday, March 24, 2022 7:14 AM
> On Wed, Mar 23, 2022 at 3:06 PM Balázs Lengyel <

---

From: Balázs Lengyel <[email-masked]>
Date: Thu, 24 Mar 2022 17:14:38 +0000

Hello,
So it seems we agree, that a schema level immutable property based on yang extensions is needed. (I am not commenting on the other parts just now.)
Regards Balazs

From: Andy Bierman <[email-masked]>
Sent: Thursday, 24 March, 2022 16:13
To: maqiufang (A) <[email-masked]>
Cc: Balázs Lengyel <[email-masked]>; Kent Watsen <[email-masked]>; NETMOD Group <[email-masked]>
Subject: Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

On Thu, Mar 24, 2022 at 7:22 AM maqiufang (A) <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Andy, Balazs,

This problem exists no matter what external (AND PURELY OPTIONAL) statement is used.

Best Regards,
Qiufang

Andy

From: netmod [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Andy Bierman

Regards Balazs

Andy

Andy

Hi,

Andy

---

From: Balázs Lengyel <[email-masked]>
Date: Thu, 24 Mar 2022 17:14:39 +0000

As mentioned earlier immutable is not enough for predefined NACM rules
because the client may always
insert a rule(-list) before the immutable rule(s) that will make the immutable
rules ineffective. The problem is that the rule(-sets) are a user ordered list
where the order matters. It is not enough to protect the individual rule(sets)
the order would also need protection.
Balazs

From: maqiufang (A) <maqiufang1=[email-masked]>
Sent: Thursday, 24 March, 2022 15:23
To: Andy Bierman <[email-masked]>
Cc: Balázs Lengyel <[email-masked]>; Kent Watsen <[email-masked]>; NETMOD Group <[email-masked]>
Subject: RE: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

Hi, Andy, Balazs,

Best Regards,
Qiufang

Regards Balazs

Andy

Andy

Hi,

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 24 Mar 2022 10:48:26 -0700

> the order would also need protection.

The NMDA solution would be to simply list the effective rule-lists in
<operational>.
The server rule-list will always be first in <operational> and not even
exist in <intended>.

I think a standard solution has a higher bar than our proprietary
extensions.
The interactions with NACM need to be properly handled.

IMO a proper solution would be an update to NACM itself.
The reason nacm:default-deny-write and nacm:default-deny-all work,
even though they are optional extensions, is because they are mandatory
extensions
if NACM is supported.

A nacm:static-data extension would be similar to the other 2 extensions.
They are short-hand automatic NACM rules.
NACM itself explains how they are handled so there is no conflict with
user-provided rule-lists.

Andy

>
>
> *From:* maqiufang (A) <maqiufang1=[email-masked]>
> *Sent:* Thursday, 24 March, 2022 15:23
> *To:* Andy Bierman <[email-masked]>
> *Cc:* Balázs Lengyel <[email-masked]>; Kent Watsen <
> [email-masked]>; NETMOD Group <[email-masked]>
> *Subject:* RE: [netmod] Alternative approach to
> a)      The system generates some QoS templates when QoS functionality is
> enabled, and some of the generated templates are read-only, while others
> *From:* netmod [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Andy Bierman

---

From: Balázs Lengyel <[email-masked]>
Date: Thu, 24 Mar 2022 20:23:36 +0000

See as BALAZS3, below!

From: Andy Bierman <[email-masked]>
Sent: Thursday, 24 March, 2022 18:48
To: Balázs Lengyel <[email-masked]>
Cc: maqiufang (A) <maqiufang1=[email-masked]>; Kent Watsen <[email-masked]>; NETMOD Group <[email-masked]>
Subject: Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

On Thu, Mar 24, 2022 at 10:14 AM Balázs Lengyel <[email-masked]<mailto:[email-masked]>> wrote:

The NMDA solution would be to simply list the effective rule-lists in <operational>.
The server rule-list will always be first in <operational> and not even exist in <intended>.

I think a standard solution has a higher bar than our proprietary extensions.
The interactions with NACM need to be properly handled.

IMO a proper solution would be an update to NACM itself.
The reason nacm:default-deny-write and nacm:default-deny-all work,
even though they are optional extensions, is because they are mandatory extensions
if NACM is supported.

A nacm:static-data extension would be similar to the other 2 extensions.
They are short-hand automatic NACM rules.
NACM itself explains how they are handled so there is no conflict with user-provided rule-lists.

BALAZS3: For me it is not really important whether we define the static-data or immutable extension in a new draft/RFC or whether we put it into a new version or NACM. Whichever is easier to get standardized.

From: maqiufang (A) <maqiufang1=[email-masked]<mailto:[email-masked]>>
Sent: Thursday, 24 March, 2022 15:23
To: Andy Bierman <[email-masked]<mailto:[email-masked]>>
Cc: Balázs Lengyel <[email-masked]<mailto:[email-masked]>>; Kent Watsen <[email-masked]<mailto:[email-masked]>>; NETMOD Group <[email-masked]<mailto:[email-masked]>>
Subject: RE: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

Hi, Andy, Balazs,

Best Regards,
Qiufang

Regards Balazs

Andy

Andy

Hi,

Andy