Yes – I definitely see this as a validate/commit time check (not a check during editing of a candidate).
From: maqiufang (A) <maqiufa...@huawei.com> Sent: Wednesday, May 7, 2025 3:24 AM To: Rob Wilton (rwilton) <rwil...@cisco.com>; Kent Watsen <kent+i...@watsen.net>; Jason Sterne (Nokia) <jason.ste...@nokia.com> Cc: netmod@ietf.org Subject: RE: [netmod] Re: 2nd WGLC on immutable-flag Hi, Rob, 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). I mostly agree with this, except, I think that you can configure an immutable node with a different value in candidate, it is just that the validate operation would fail, and attempts to commit the configuration should fail. Hence maybe leave candidate out of the example? Yes, makes sense to me. It is possible for a rejection to update an immutable node in <candidate> to be delayed until a <commit> or <validate> operation takes place. Agree to leave <candidate> out of the example. Kind regards, Rob Best Regards, Qiufang
_______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
