Hi, Éric, Thanks a lot for the review, the authors have prepared a PR to address some of your comments below: https://github.com/netmod-wg/immutable-flag/pull/35/changes. Please also see my reply below inline with [Qiufang]...
-----Original Message----- From: Éric Vyncke via Datatracker [mailto:[email protected]] Sent: Tuesday, June 30, 2026 2:32 PM To: The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: Éric Vyncke's No Objection on draft-ietf-netmod-immutable-flag-13: (with COMMENT) Éric Vyncke has entered the following ballot position for draft-ietf-netmod-immutable-flag-13: No Objection ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the work done in this document. Please find below some non-blocking COMMENTs, responses to these COMMENTs will be greatly appreciated, albeit not required. Please also note that my COMMENTs about section 1 were nearly DISCUSS level. Regards -éric ### Abstract Should NETCONF and RESTCONF be called out ? [Qiufang] Accepted, please review the PR for the updated Abstract. ### Definition of immutable in section 1 ` that cannot be modified by clients (that is, it is immutable)` is not really correct. Immutable means that it never changes, 'cannot be modified by clients' allows the server to change its read-only value, e.g., "CPU temperature" is read-only (cannot be modified) but not immutable (as it can change). [Qiufang] The current text is fine, because the document does allow the server to change immutable value in some cases like software upgrade and license change. The draft states that immutable nodes can only be system-defined. And the update of system configuration is documented in draft-ietf-netmod-system-config which is now in RFC queue (see https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-20#section-6.1). Section 7 (https://datatracker.ietf.org/doc/html/draft-ietf-netmod-immutable-flag-13#section-7) also says " Immutable configuration can only be created, updated and deleted by the server ". When you say "CPU temperature", I think this is the operational statistic or metric that should be defined as read-only (i.e., config-false). This is completely out of scope, because what the document is discussing here is all about the configuration data (i.e., config-true). Within the context of configuration, "immutable" means the node cannot be altered through client-driven configuration operations. Hopefully this clarifies. ### Which servers/clients in section 1 The text uses "server" and "client" without being specific about the protocol... as the I-D updates the NETCONF/RESTCONF RFC, the reader can *guess* that it is about "RESTCONF or NETCONF server"... Please avoid ambiguities in a proposed standard... [Qiufang] The proposed PR has stated that the terms "client" and "server" are used in accordance with NMDA definitions in RFC8342, thereby eliminating any ambiguity regarding the protocol context. ### Section 11 My understanding based on the previous sections is that this flag is for read-only stores, so, I wonder how could a sensible client send an edit request to a read-only store ? `Clients can leverage this information to avoid sending edit requests that would otherwise fail due to immutable nodes.` ? [Qiufang] This is a key subtle point. You are right that immutable flag is only for read-only datastores. But it indicates the immutability of configuration, i.e., system configuration datastore is read-only, but system nodes could be modifiable or non-modifiable, and such modification is implemented by clients sending an operation request towards read-write datastore such as <running>/<candidate> to write different values. By exposing the immutability of some system configuration, clients would understand that some nodes are non-modifiable, even config-true, and thus could avoid sending such an <edit-config> request. Make sense? Best regards, Qiufang //co-author _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
