Hi Qiufang Ma, Please see inline. Jason From: maqiufang (A) <[email protected]> Sent: Thursday, December 9, 2021 7:57 AM To: Sterne, Jason (Nokia - CA/Ottawa) <[email protected]> Cc: [email protected] Subject: RE: [netmod] "immutable" flag
Hi, Jason, Thanks for your comments, please see my reply inline. From: Sterne, Jason (Nokia - CA/Ottawa) [mailto:[email protected]] Sent: Thursday, December 9, 2021 6:42 AM To: maqiufang (A) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: RE: [netmod] "immutable" flag Hi Qiufang, I think there are use-cases for "immutable" even outside of system config so we may not want to restrict it to system config. [Qiufang Ma] Agree that we can just define such an "immutable" flag without restricting it to decorating system configuration. In that way, maybe we can discuss whether we should define this annotation in an independent I-D.[>>JTS: ] Yes perhaps. Although I'm not sure this is an urgent item for the WG. Interested to hear what others think as well. Regarding this "immutable" flag there may be a question to answer: what if legacy clients receive some annotations they do not understand? Should they just ignore it silently? [>>JTS: ] Yes - that is what clients would have to do. Not ideal but maybe not critical. Servers have various reasons they may reject a configuration, even if that configuration looks valid against the YANG model. I'm not sure it would be as simple as erroring when a write is attempted to that value. Are you talking about an error at edit time, or at commit/validation time ? [Qiufang Ma] My assumption is an error at edit time, static checks are sufficient for the server to detect the problem. But I think it's also okay to report an error at commit/validation time. [>>JTS: ] I think in order to allow the behavior I mention at the end, we'd need to make this a commit time behavior. IMO the candidate should be allowed to contain a new/changed value for an immutable leaf. The when the commit occurs, the system can attempt to achieve what the candidate is asking for. If it can't achieve it, then it can reject. What if the value configured is the same as the current value ? [Qiufang Ma] I have the same question. Some implementations do allow the client to configure a same value(e.g., for the purpose of offline validation of <running>). But I feel that it may depend on the discussion of another thread "should the origin='system' be required for system configurations copied/pasted into <running>'" which I posted to the WG. If the origin="intended" , it actually means overwrite. [>>JTS: ] The "immutable" tag would be in the YANG model, which means it is against that schema node whether there is an equivalent data node in <system> or <candidate> or both. I think it becomes a warning to the client that the value can't be *changed* in a datastore. It can only be *created* initially (if it didn't already exist). For a leaf that is at the top level or only has non-presence containers as ancestors, it means that leaf can only be set once in any particular datastore (or maybe changing it requires a reboot ?). For leafs that are descendants of presence containers or lists, then the nearest p-container or list entry ancestor would have to be effectively deleted and re-created under the hood to get to the config that the user declared they want. It is probably best if this is a validation/commit time check. If the immutable leaf is inside a list entry, then it should probably be acceptable for the server to allow a change to the leaf by destroying and re-creating the list entry under the hood. i.e. allow a change to the immutable item (which is in line with configurations being "declarative" - just get me there if possible). [Qiufang Ma] Are you suggesting a server should allow a client to delete/create the "immutable" data item in <running>? Wouldn't that be a little strange if a client can delete a particular data item but has no right to change its value? Theoretically, the deletable is modifiable. [>>JTS: ] I don't think delete is allowed unless a parent is deleted (i.e. the nearest presence container or list entry). But we do need to allow parents of immutable leafs to be deleted IMO. Best Regards, Qiufang Ma Jason From: netmod <[email protected]<mailto:[email protected]>> On Behalf Of maqiufang (A) Sent: Monday, November 22, 2021 7:12 AM To: [email protected]<mailto:[email protected]> Subject: [netmod] "immutable" flag Hi, all There are some system configuration which may not be modifiable for clients(e.g., interface "name" and "type"). Should we define an "immutable" flag to indicate to the clients which system configuration is read-only or which is not? The server will return an error if the clients attempt to configure a value for a system defined data node with an "immutable" flag. My assumption is that this annotation should be carried only when the clients retrieve <running> with "with-system" parameter to get a merged view. Suggestions, comments and concerns about this issue? Best Regards, Qiufang Ma
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
