Hi Qiufang, See inline with [mj1]
> On Dec 15, 2025, at 12:17 AM, maqiufang (A) <[email protected]> wrote: > > 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] <mailto:[email protected]>> > Cc: [email protected] > <mailto:[email protected]>; NetMod WG > <[email protected] <mailto:[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. [mj1] I agree with the resolution below for this point. > > > 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. > [mj1] Ok. > > 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>. ]mj1] On re-reading your explanation above on what happens when a list entry is removed, I think I understand. But that text is not in the draft, so some explanation of what happens would help, even if it is a reference to 8342. Something to the effect of: “If a list entry is removed, e.g., a line card is removed, then the list entry is removed from <system> but is present only in <running>, and thus in <intended>. Since the node is no longer present, the entry does not appear in <operational>. This is further clarified in [RFC8342], Appendix C.3.1. > > > 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>.” [mj1] Ok. > > 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? [mj1] Ok. > > > <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? [mj1] Ok. I will await an update before progressing the draft. Thanks. > > Best Regards, > Qiufang //co-author > > > Mahesh Jethanandani [email protected]
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
