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]>; [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. 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? 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. 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. 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. 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
