Hi, Mahesh, Thanks for your follow-up. I have posted -11, which adds the RESTCONF example to Appendix B.6.
The diff is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-netmod-immutable-flag-11. Best Regards, Qiufang From: Mahesh Jethanandani [mailto:[email protected]] Sent: Tuesday, May 26, 2026 1:57 AM To: maqiufang (A) <[email protected]> Cc: [email protected]; NETMOD WG <[email protected]> Subject: Re: [netmod] AD review of draft-ietf-netmod-immutable-flag-09 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]<mailto:[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]<mailto:[email protected]>
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
