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 <a...@yumaworks.com> Sent: Thursday, 24 March, 2022 16:13 To: maqiufang (A) <maqiufa...@huawei.com> Cc: Balázs Lengyel <balazs.leng...@ericsson.com>; Kent Watsen <kent+i...@watsen.net>; NETMOD Group <netmod@ietf.org> Subject: Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00 On Thu, Mar 24, 2022 at 7:22 AM maqiufang (A) <maqiufa...@huawei.com<mailto:maqiufa...@huawei.com>> wrote: 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? 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. Best Regards, Qiufang Andy From: netmod [mailto:netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org>] On Behalf Of Andy Bierman Sent: Thursday, March 24, 2022 7:14 AM To: Balázs Lengyel <balazs.leng...@ericsson.com<mailto:balazs.leng...@ericsson.com>> Cc: NetMod WG <netmod@ietf.org<mailto:netmod@ietf.org>> Subject: Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00 On Wed, Mar 23, 2022 at 3:06 PM Balázs Lengyel <balazs.leng...@ericsson.com<mailto:balazs.leng...@ericsson.com>> wrote: From: Andy Bierman <a...@yumaworks.com<mailto:a...@yumaworks.com>> Sent: Wednesday, 23 March, 2022 22:32 To: Balázs Lengyel <balazs.leng...@ericsson.com<mailto:balazs.leng...@ericsson.com>> Cc: NetMod WG <netmod@ietf.org<mailto:netmod@ietf.org>> Subject: Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00 On Wed, Mar 23, 2022 at 2:16 PM Balázs Lengyel <balazs.leng...@ericsson.com<mailto:balazs.leng...@ericsson.com>> 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. Why do you need the exceptions? Could you provide some use-case examples ? 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. 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. 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.” 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 From: netmod <netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org>> On Behalf Of Andy Bierman Sent: Wednesday, 23 March, 2022 21:10 To: NetMod WG <netmod@ietf.org<mailto:netmod@ietf.org>> Subject: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00 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=c875257e-41f5-45d6-a9e9-871e5ebb4243&u=https%3A%2F%2Fwww.yumaworks.com%2Fpub%2Flatest%2Fyangauto%2Fyumapro-yangauto-guide.html%23ncx-user-write> Andy
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
