Hi Qiufang, Thanks for addressing all my MAJOR and COMMENTs on the draft. I will move the draft forward.
There is one minor comment, which would be nice to address should you touch the draft again for other reasons. Appendix B.6 shows only a NETCONF error example for overriding immutable configuration — there's no RESTCONF parallel example. Since the normative text is now protocol-agnostic, this isn't a blocking issue, but it's a gap if you want symmetry with Appendix B.2. Cheers. > On May 14, 2026, at 12:24 AM, maqiufang (A) <[email protected]> wrote: > > Hi, Mahesh, > > Thanks a lot for the review! The authors have submitted -10 to address your > comments, feel free to review the diff at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-netmod-immutable-flag-10. > Please also see my reply below inline… > > From: Mahesh Jethanandani [mailto:[email protected]] > Sent: Thursday, May 7, 2026 6:25 AM > To: [email protected] > <mailto:[email protected]> > Cc: NETMOD WG <[email protected] <mailto:[email protected]>> > Subject: [netmod] AD review of draft-ietf-netmod-immutable-flag-09 > > Hi Authors, > > The document addresses a genuine gap: servers have long silently rejected > modification of system-provided configuration without any machine-readable > way to communicate immutability to clients ahead of time. The metadata > annotation approach is appropriate, and the examples are helpful. The > shepherd (thanks Kent Watsen) has done a thorough job, and the YANG Doctors > (thanks Per) issues from the -06 early review appear to have been resolved in > subsequent versions. > > That said, I have two MAJOR and several MINOR comments that need to be > addressed before I can approve publication. > > MAJOR: > > Section 3, paragraph 0 > > While the immutable flag applies to all configuration nodes, its > > value true can only be used for system configuration. > > The phrase "can only be used for" sounds normative, but has no > RFC 2119 language. This should use MUST NOT. For example, > "its value true MUST NOT be set to true for configuration > data that is not system configuration." Without normative > language, this is just advice that implementations may ignore. > Thanks for the comment. We have updated the sentence with normative RFC 2119 > MUST NOT wording as suggested. > Section 3, paragraph 0 > > The immutable flag is only visible in read-only datastores (i.e., > > <system> [I-D.ietf-netmod-system-config], <intended>, and > > <operational>) when a "with-immutability" parameter is carried > > (Section 4.2), however this only serves as descriptive information > > about the instance node itself, but has no effect on the handling of > > the read-only datastore. If the immutable flag is requested to be > > returned for an invalid datastore, then the server MUST return an > > <rpc-error> element with an <error-tag> value of "invalid-value". > > The last sentence is NETCONF-specific (<rpc-error>). For RESTCONF, > Section 4.2.2 separately says the server returns "400 Bad Request" > when the parameter has an unexpected value, but that addresses a > different case (malformed parameter value, not wrong datastore). > There is no explicit statement about the RESTCONF error response > when with-immutability is used against a read-write datastore. > > Furthermore, there is a tension between this normative text and > the YANG module itself: the with-immutability leaf has a when > condition restricting it to <system>, <intended>, or <operational>. > When the when condition is false, the leaf conceptually does not > exist in the schema for that context. Servers might return > "unknown-element" rather than "invalid-value." The normative > requirement in Section 3 conflicts with what the YANG when > semantics imply. Please reconcile these two mechanisms and > provide consistent error behavior specification for both NETCONF > and RESTCONF. > Yes, both points are good catch. Have tried to rephrase this sentence to be > protocol-agnostic, and also update the error-tag to “unknown-element”: > OLD: > If the immutable flag is requested to be > returned for an invalid datastore, then the server MUST return an > <rpc-error> element with an <error-tag> value of "invalid-value". > NEW: > If the immutable flag is requested to be > returned for an invalid datastore, then the server MUST return an > error response with the error-tag value "unknown-element". > > Does this work for you? > MINOR: > > Section 1, paragraph 5 > > This document defines a way to formally document the existing > > behavior, implemented by servers in production, on the immutability > > of some system-provided nodes, using a YANG metadata annotation > > [RFC7952] called "immutable" to flag which nodes are immutable. This > > document does not regulate server behaviors. That said, it is > > expected that a server will return an error with an error-tag > > containing "invalid-value" when immutability is attempted to be > > violated. > > The passive construction "attempted to be violated" is awkward. > Suggest: "when a client attempts to modify an immutable node." > Fixed, thanks. > Section 4.1, paragraph 1 > > A node that is annotated as immutable cannot be changed via > > configuring a different value in read-write configuration datastores > > (e.g., <running>), nor is there any way to delete the node from the > > combined configuration in the intended datastore (as described in > > Section 4 of [I-D.ietf-netmod-system-config]). The node MAY be > > explicitly configured by a client in <running> with the same value > > and that configuration in <running> may subsequently be removed, but > > neither of these edits will change the configuration in <intended> > > (if implemented) on the device. > > The statement "the combined configuration in the intended datastore" > without defining what "combined" means. A reader unfamiliar with the > system-config draft won't know this refers to the merge of <running> > and <system> into <intended>. Add a brief explanation or a cross-reference > to the system-config draft definition. > Fixed as follows: > OLD: …, nor is there any way to delete the node from the > combined configuration in the intended datastore (as described in > Section 4 of [I-D.ietf-netmod-system-config]). > NEW: > …, nor is there any way to delete the node from the intended datastore, > which is the merged result of <running> and <system> as defined in Section 4 > of [I-D.ietf-netmod-system-config]. > Section 6, paragraph 0 > > Immutability is a conceptual operational state value that is > > recursively applied to descendants, which may reset the immutability > > state as needed, thereby affecting their descendants. There is no > > limit to the number of times the immutability state may change in a > > data tree. > > This section describes immutability as "a conceptual operational state > value." > This phrasing conflates metadata about configuration with operational > state data, which are distinct concepts in NMDA. Suggest: "Immutability > is a property of a configuration data node instance, conveyed as metadata." > Yes, agree. Good catch. Have reworded this sentence as suggested. Thanks. > Section 8, paragraph 0 > > The server rejects an operation request due to immutability when it > > tries to perform the operation on the request data. It happens after > > any access control processing, if the Network Configuration Access > > Control Model (NACM) [RFC8341] is implemented on a server. For > > example, if an operation requests to override an immutable > > configuration data, but the server checks the user is not authorized > > to perform the requested access operation on the request data, the > > request is rejected with an "access-denied" error. > > This section says the server rejects due to immutability "after any > access control processing." This ordering has security implications > (it avoids leaking immutability information to unauthorized users). > However, the text is descriptive. If this ordering is intentional > as a security property, it should be SHOULD or MUST. If it's > implementation-defined, say so. > Have added a MUST statement as a normative requirement. > Section 9, paragraph 9 > > description > > "If this parameter is present, the server returns the > > 'immutable' annotation for configuration that it > > internally thinks immutable."; > > "internally thinks immutable" is informal. Suggest "for > configuration that the server considers immutable." > Sure, fixed. > "B.1.", paragraph 3 > > <rpc-reply message-id="101" > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > <data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"> > > <user-groups xmlns="urn:example:user-group" > > xmlns:imma="urn:ietf:params:xml:ns:yang:ietf-immutable-\ > > annotation" > > imma:immutable="false"> > > <group imma:immutable="true"> > > <name>administrator</name> > > <description imma:immutable="false">administrator group</\ > > description> > > <access-level>admin</access-level> > > <user> > > <name>ex-username-1</name> > > <password>$5$rounds=10000$mysalt123456789$l4BjA1p/8q.qCYJ.\ > > 2pLqjR5mCJf2bP7cLpYWmnC7Hq8</password> > > </user> > > <user imma:immutable="false"> > > <name>ex-username-2</name> > > <password>$1$/h1234q$abcdef1234567890abcdef</password> > > </user> > > <tag>system</tag> > > <tag>non-editable</tag> > > </group> > > <group imma:immutable="false"> > > <name>power-users</name> > > <description>Power user group</description> > > <access-level>power</access-level> > > <user> > > <name>ex-username-3</name> > > <password>$1$/h4567q$abcdef2345678901abcdef</password> > > </user> > > <tag>system</tag> > > <tag>editable</tag> > > </group> > > </user-groups> > > </data> > > </rpc-reply> > > The document allows servers to return immutable="false" explicitly > (the example above does so for several nodes). Section 6 says servers > "may suppress the annotation if it is inherited from its parent node > or uses the default value." However, returning explicit false for > a top-level node whose default is already false adds noise with > no information value. This and other examples in this Appendix do this > Consider either removing these from examples or adding explanatory text > about why a server might choose to be explicit even when the value > matches the default. > The document does not restrict the server from returning annotations that > could have been omitted. Note sec.6 already says “Servers may suppress the > annotation if it is inherited from its > parent node or uses the default value as the top-level node, but are > not precluded from returning the annotation on every single element. > ” The NC and RC examples shows some default annotations explicitly to aid > readability and avoid requiring readers to infer the default/inheritance > rules. We’ve added a brief explanatory note clarifying that this is for > illustrative clarity. Thanks. > Thanks > > Mahesh Jethanandani > [email protected] <mailto:[email protected]> > > Best Regards, > Qiufang Mahesh Jethanandani [email protected]
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
