Hi, Mahesh, Thanks for the response, please see below inline... [trimming down the parts we’ve agreed upon]
From: Mahesh Jethanandani [mailto:[email protected]] Sent: Wednesday, December 10, 2025 8:32 AM To: maqiufang (A) <[email protected]> Cc: [email protected]; NetMod WG <[email protected]> Subject: Re: AD review of draft-ietf-netmod-system-config-12 Hi Qiufang, Please see responses inline with [mj. Section 6.3, paragraph 0 > In some cases, a server may allow some parts of system configuration > (e.g., a leaf's value) to be modified. Modification of system > configuration is achieved by the client writing configuration data in > <running> that overrides the values of matched configuration nodes at > the corresponding level in <system>. Configurations defined in > <running> take precedence over system configuration nodes in <system> > if the server allows the nodes to be modified (some implementations > may have immutable system configuration as per > [I-D.ietf-netmod-immutable-flag]). What happens if <running> config is updated to remove the node that the matched configuration node in the corresponding level in <system>? Does the <system> value instantly show up? Are you referring to some copied system nodes being removed from <running> will be added back automatically in <running>? No, if nodes copied from <system> into <running> are removed afterwards from <running>, it disappears from <running>; but the client can add it back manually, of course. The definition of <running> ds indicates that <running> is controlled by the client, not the server. However, those nodes would still be in <system> unless license or system resources change (i.e., card removed). [mj] No, I was referring to the case where the client has previously configured a node in <running> but then decides to remove it. A corresponding node in <system> does exist. The document says that <running> overrides the matched config node in <system>. But it is not clear what happens when the <running> node is removed/unconfigured. [Qiufang] If the node is removed from <running>, then the value in <system> is present in <intended> and <operational> if applied successfully. This is determined according to the merging logic, as there is no node in <running> that matches with the one in <system>, i.e., system-defined nodes not being overridden. Also, if the server implements an immutable flag, should the nodes under <system> that are not overridable be annotated "immutable", enabling clients to pre-validate edits? Yes, immutable flag is visible in <system>, but we prefer to leave details to I-D. ietf-netmod-immutable-flag, and keep it as informational here and just allows the existence of modifiable and non-modifiable system configuration. [mj] Ok. But one of the documents needs to make it clear. [Qiufang] Yes, maybe see https://datatracker.ietf.org/doc/html/draft-ietf-netmod-immutable-flag-06#section-3 (the second paragraph), and also the definition of “immutable flag” in https://datatracker.ietf.org/doc/html/draft-ietf-netmod-immutable-flag-06#section-2. Section 6.4, paragraph 0 > A server may also allow a client to add nodes to a list entry in > <system> by writing those additional nodes in <running>. Those > additional data nodes may not exist in <system> (i.e., an addition > rather than an override). What happens if the list entry is removed because a license gets revoked or a line card gets pulled? Then the list entry is removed from <system> but only be present in <running>, and thus is in <intended> (which is a merge result of <running> and <system>). Since license or physical resource is not there, the entry does not appear in <operational>, this is clarified in 8342 (see https://datatracker.ietf.org/doc/html/rfc8342#appendix-C.3.1), and this draft doesn’t change that behavior. [mj] If the entries continue to be present in <running>, will that not create a problem if the client tries to modify the config for those nodes? [Qiufang] NMDA arch does allow the client to modify the config, which will present in <intended>, but those nodes would not be applied successfully and thus disappear from <operational>. Section 1.3, paragraph 2 > This document also updates the definition of "intended" origin > metadata annotation identity defined in Section 5.3.4 of [RFC8342]. > The "intended" identity of origin value defined in [RFC8342] > represents the origin of configuration provided by <intended>, this > document updates its definition as the origin source of configuration > explicitly provided by clients, and allows a subset of configuration > in <intended> that flows from <system> yet is not configured or > overridden explicitly in <running> to use "system" as its origin > value. As per Section 5.3.4 of [RFC8342], all configuration with > origin value being reported as "intended" MUST originate from > <running>, which includes any configuration in <system> that has been > copied into <running>. Configuration that is in <system> and not > also present in <running> MUST be reported as origin "system" in > <operational>. It was my understanding that configuration in <system> is NOT copied into <running> but that it is merged with <running> before being written into <intended>. Is my understanding wrong? Figure 1 also does not indicate any copying of <system> into <running>. I think your understanding is correct. System configuration is not present in <running> by default, but merged into <intended> which is the configuration that the device tries to apply. The client may explicitly copy some nodes from <system> into <running>, e.g., if the node needs to be overridden/referenced. [mj] In that case, what would be the origin of those nodes? [Qiufang] The WG had a lot of discussion on this, e.g., https://mailarchive.ietf.org/arch/msg/netmod/dskOvY0jHnriK75VRUM4sxLQMrI/. The agreement is to use “intended” as the origin value. See https://datatracker.ietf.org/doc/minutes-interim-2024-netmod-01-202401231400/ for interim minutes on issue #1: “The consensus in the room was that <system> nodes copied into <running> should have origin "intended". The system-config draft may "update" RFC 8342 (NMDA) to state this.” Also see sec.1.3 (https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-14#section-1.3) “As per Section 5.3.4 of [RFC8342], all configuration with origin value being reported as "intended" MUST originate from <running>, which includes any configuration in <system> that has been copied into <running>.” Section 4, paragraph 7 > Configuration in <system> is undeletable to clients (e.g., a system- > defined list entry can never be removed), even though a node defined > in <system> may be overridden in <running>. If it is desired to > enable a client to delete system configuration, it can be > approximated using <factory-default> ([RFC8808]). If system > initializes a value for a particular leaf which is overridden by the > client with a different value in <running> (Section 6.3), the node in > <running> may be removed later, in which case system-initialized > value defined in <system> may still be in use and appear in > <operational>. There is a seeming contradiction here, or the behavior is not very well explained. Earlier in the section, the document states: "To ensure the validity of <intended>, configuration in <running> is merged with <system> to become <intended>, in which process, configuration appearing in <running> takes precedence over the same node in <system>.” However, in this paragraph, it says that values in <running> may be removed later, in which case system-defined values may be in use. What gives? Are there special conditions under which the opposite is true? Both sentences are true to me, I guess the seeming contradiction is because they are different merge results that appear in <intended> but do not think it wise to say too much about the merge logic (i.e., how two different data trees are merged) in this draft. If the desired value is in <running>, it wins out over the predefined value in <system>; otherwise (e.g., never be added or be added but removed afterwards) there is no conflicts when merging, system predefined value is just the final configuration that is in use. Any suggestion to reword it to make it more clear? [mj] This goes back to my earlier question of what happens when the client removes a node in the <running> config whose value is different from the value in <system>. My thought is that once the node is removed in <running> that the <system> configured value will show up in <intended>/<operational> datastore. If that is correct, then the above sentence could be reworded to say just that: OLD: If system initializes a value for a particular leaf which is overridden by the client with a different value in <running> (Section 6.3), the node in <running> may be removed later, in which case system-initialized value defined in <system> may still be in use and appear in <operational>. NEW: If system initializes a value for a particular leaf and that leaf was previously overridden by the client with a different value in <running> (Section 6.3), and if the node in <running> is now removed, the system-initialized value defined in <system> comes into use and appears in <operational>. [Qiufang] Okay, but maybe soften the sentence, because it is not definitely that all <system> would be in use and appears in <operational>, e.g., we had the concept of “inactive-until-referenced” system configuration in previous versions (e.g., https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-05#section-2.3), which may not appear in <operational> until being referenced in <running>. OLD: If system initializes a value for a particular leaf which is overridden by the client with a different value in <running> (Section 6.3), the node in <running> may be removed later, in which case system-initialized value defined in <system> may still be in use and appear in <operational>. NEW: If system initializes a value for a particular leaf which is overridden by the client with a different value in <running> (Section 6.3), and if the node in <running> is removed at a later time, the system-initialized value defined in <system> appears in <intended> and may come into use eventually if applied successfully. Would this be okay? <interfaces xmlns="urn:example:interface"> <interface> <name>lo0</name> <mtu>9216</mtu> </interface> </interfaces> which would make the config post merge as follows: <interfaces xmlns="urn:example:interface"> <interface> <name>lo0</name> <mtu>9216</mtu> <description>loopback</description> </interface> </interfaces> Agree, this echoes what shows in <operational>. "B.1.", paragraph 5 > <interfaces xmlns="urn:example:interfacemgmt" > xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin" > or:origin="or:system"> > <interface> > <name>lo0</name> > <type>loopback</type> > <enabled or:origin="or:default">true</enabled> > <ip-address>127.0.0.1</ip-address> > <ip-address>::1</ip-address> > <description>system-defined interface</description> > </interface> > </interfaces> Should the origin of the <ip-addresses> not show where that config is coming from, as in the above examples? Or is that left out on purpose? If so, please state that for brevity or clarity of the example, not all origins are indicated. The origin of <ip-address> is inherited from its parent node “interfaces”, which is ‘system’. RFC 8342 defines that if it is not specified, it has the same value as the origin value of its parent node. That way, I don’t think it needed for this document to clarify the inheritance rules suppose the reader is rather familiar with 8342, right? [mj] Yes, that is true, but there is no harm in being explicit. Thanks. [Qiufang] As the inheritance of “origin” annotation is not specific to this single example, how about adding the following sentence in Appendix A, the first paragraph: Note that if the "origin" metadata annotation for configuration is unspecified in snippets, it is inherited from its parent node. Work for you? Best Regards, Qiufang //co-author
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
