[netmod] Re: Éric Vyncke's No Objection on draft-ietf-netmod-immutable-flag-13: (with COMMENT)

["maqiufang (A)" <[e-mail]>]

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:[e-mail]] 
Sent: Tuesday, June 30, 2026 2:32 PM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
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