Hi Qiufang, Please see comment at bottom.
Kent // contributor > On May 7, 2025, at 3:18 AM, maqiufang (A) > <[email protected]> wrote: > > 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] <mailto:[email protected]>> > Cc: Jason Sterne (Nokia) <[email protected] > <mailto:[email protected]>>; [email protected] <mailto:[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. Good point, we certainly don't want this document to regulate behavior. But maybe some wishy-washy text could be added? Something like: This document does not regulate server behavior. That said, it is expected that a server will return an error when immutability is violated. Such rpc-errors may use: error-type: application error-tag: value of FOO and ; error-severity: error error-path: path to the node etc. Thoughts? Maybe it's obvious and so better not said at all... Kent // contributor
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
