Hi, Kent, Thanks for the comments, please see inline…
From: Kent Watsen [mailto:[email protected]] Sent: Wednesday, April 30, 2025 11:17 PM To: maqiufang (A) <[email protected]> Cc: Jason Sterne (Nokia) <[email protected]>; [email protected] Subject: Re: [netmod] 2nd WGLC on immutable-flag Hi Qiufang, OLD: When a leaf node instance is immutable, it cannot be configured with a different value in read-write configuration datastores (e.g. <candidate>, <running>). It can be deleted in read-write configuration datastores (see section 7). NEW: When a leaf node instance is immutable, it cannot be configured with a different value in read-write configuration datastores (e.g. <candidate>, <running>). Though it can be created/deleted in read-write configuration datastores. (see section 7). This is better. Thanks. Regarding "cannot be configured". Does the draft actually state that trying to configure a different value is expected to fail? I see in the Abstract and the YANG module's "description" the following text: Clients may use "immutable" annotations provided by the server, to know beforehand why certain otherwise valid configuration requests will cause the server to return an error. This certainly hints at the expected server behavior, but doesn't seem to require it. Should it be stated somewhere that servers MUST return an error if a client attempts the violate immutability for a node the server has stated/annotated to be immutable? I recall some earlier versions has the similar statement to your suggestion, but I forget the exact reason why it was removed. Perhaps because the immutable flag focuses on documenting the existing behavior of the server, rather than regulating the behavior of it. That said, I am okay if we add this statement back somewhere in the draft if there is no objections. Kent // contributor Best Regards, Qiufang
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
