Hi Qiufang, Please see comment at bottom.
Kent // contributor > On May 7, 2025, at 3:18 AM, maqiufang (A) > <maqiufang1=40huawei....@dmarc.ietf.org> wrote: > > Hi, Kent, > > Thanks for the comments, please see inline… > > From: Kent Watsen [mailto:kent+i...@watsen.net] > Sent: Wednesday, April 30, 2025 11:17 PM > To: maqiufang (A) <maqiufa...@huawei.com <mailto:maqiufa...@huawei.com>> > Cc: Jason Sterne (Nokia) <jason.ste...@nokia.com > <mailto:jason.ste...@nokia.com>>; netmod@ietf.org <mailto:netmod@ietf.org> > 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 -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
