Hi Med, +1 to Quifang's comments. Effectively, I think that this was a limitation in the original NMDA architecture that is being corrected.
Kind regards, Rob From: maqiufang (A) <[email protected]> Date: Tuesday, 20 January 2026 at 04:00 To: [email protected] <[email protected]>, [email protected] <[email protected]> Cc: [email protected] <[email protected]>, Kent Watsen <[email protected]>, [email protected] <[email protected]>, NETMOD WG <[email protected]> Subject: [netmod] Re: Mohamed Boucadair's Discuss on draft-ietf-netmod-system-config-18: (with DISCUSS and COMMENT) Hi, Med, Thanks a lot for the review. While the authors are preparing a new version to address your comments below, please find some of my response below inline with [Qiufang]... -----Original Message----- From: Mohamed Boucadair via Datatracker [mailto:[email protected]] Sent: Monday, January 19, 2026 6:11 PM To: The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: Mohamed Boucadair's Discuss on draft-ietf-netmod-system-config-18: (with DISCUSS and COMMENT) ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hi Qiufang, Qin, and Chong, Thank you for the effort put into this specification. Also, thanks to Luis Contreras Murillo for the OPSDIR review and the authors for engaging and implementing changes in -18. I see Luis has some follow-up few suggestions, though. [Qiufang] Yes, I do see the follow-up from Luis, sorry for the delay. I am preparing a new version to incorporate the follow-up suggestions, as well as your comments below. Please find below some few points for DISCUSSion: # Design approach RFC 8342 has the following: dynamic | +-------- learned configuration configuration | +-------- system configuration datastores -----+ | +-------- default configuration | | | v v v +---------------+ | <operational> | <-- system state | (ct + cf, ro) | +---------------+ A design approach that would not impact other datastores is to expand the “system configuration” branch above and replace it with <system>. That would be also consistent with the hierarchy of origin identity defined in RFC 8342: The values are YANG identities. The following identities are defined: o origin: abstract base identity from which the other origin identities are derived. o intended: represents configuration provided by <intended>. ... o system: represents configuration provided by the system itself. Examples of system configuration include applied configuration for an always-existing loopback interface, or interface configuration that is auto-created due to the hardware currently present in the device. ## Is there any reason why that approach is not followed compared to grafting <system> to <intended> as in the current version of the draft? [Qiufang] Having system configuration only present in <operational> does not really make sense , as the configuration provided by the client needs to interact with system configuration (i.e., reference/override/configure descendant nodes of system configuration). For example, there is some system configuration which is predefined for the convenience of clients, e.g., built-in rules, policies. A client should be able to reference a system-defined policy without copying it into <running>, and to allow <system> feeds into <intended>, the merging result in <intended> does pass the validation. The current architecture also allows the existence of system-defined templates and inactive system configuration, which are similar concepts defined in NMDA, except that they are provided by the server. Hopefully this clarifies. ## Note that with the current design, there are parts of RFC 8342 that needs “tweaking” An example is provided below (there are other similar occurrences): RFC 8342: The system will only provide configuration for this interface if there is no data for it in <intended>. When no configuration for "lo0" appears in <intended>, <operational> will show the system-provided data: <interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin" or:origin="or:intended"> <interface or:origin="or:system"> <name>lo0</name> <ip-address>127.0.0.1</ip-address> <ip-address>::1</ip-address> </interface> </interfaces> [Qiufang] This is a good point. I am not convinced that the presence of system configuration should depend on the configuration in <running>. It is also unclear in C.3.2 of 8342, as the first sentence says " Imagine that the system provides a loopback interface (named "lo0") with a default IPv4 address of "127.0.0.1" and a default IPv6 address of "::1". ", and then contradictorily followed by your sentence above. Would it be okay for appendix B in draft-ietf-netmod-system-config to update https://datatracker.ietf.org/doc/html/rfc8342#appendix-C.3.2? # Origin metadata annotation is normative CURRENT: * Origin: This document does not define any new origin identity. The "system" identity of origin metadata annotation [RFC7952] is used to indicate the origin of a data item provided by the system. This is needed to tag system ds. [Qiufang] How about the following update: OLD: * Origin: This document does not define any new origin identity. The "system" identity of origin metadata annotation [RFC7952] is used to indicate the origin of a data item provided by the system. NEW: * Origin: This document does not define any new origin identity. The "system" identity of origin metadata annotation [RFC7952] is used to indicate the origin of a data item in <system>. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Desire CURRENT: However, there is a desire to enable a server to better expose the system configuration, regardless of whether it is in use. Desire of whom? [Qiufang] How about the following? OLD: However, there is a desire to enable a server to better expose the system configuration, regardless of whether it is in use. NEW: However, there is a desire from operators to enable a server to better expose the system configuration, regardless of whether it is in use. # Root CURRENT: * YANG nodes: all "config true" data nodes up to the root of the tree, generated by the system. This seems to assume one single data tree. Is that intended? [Qiufang] Yes, note 8342 states something similar, e.g., <running>/<intended> MUST always be a valid configuration data tree. If not, I think that it is accurate to use the following: NEW: * YANG nodes: all "config true" data nodes up to the root of a data tree, generated by the system. # It is weird to reason about modification for read-only ds [Qiufang] I think there should be distinction between system configuration and <system>. Note that the draft already states: The system datastore is read-only (i.e., edits towards <system> directly MUST be denied), though the client may be allowed to provide configuration that overrides the value of a system-initialized node (see Section 6.3). Best Regards, Qiufang OLD: 6.3. Modifying (Overriding) System Configuration NEW: 6.3. Overriding System Configuration # IANA template for registration OLD: This document registers one YANG module in the 'YANG Module Names' registry, defined in [RFC6020]. NEW: IANA is requested to register the following YANG module in the "YANG Module Names" registry [RFC6020] within the "YANG Parameters" registry group. # Examples are not normative CURRENT: The updates of system configuration may be obtained through YANG notifications (e.g., on- change notification) [RFC8639][RFC8641]. [RFC8639] and [RFC8641] are listed as normative, while these should not. Please fix that. # Nits ## Split long sentences + proper RFC citation CURRENT: This document updates RFC 8342 to define a configuration datastore called "system" to hold system configuration (Section 3), it also redefines the term "conventional configuration datastore" from [RFC8342] to add "system" to the list of conventional configuration datastores. or CURRENT: 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. Cheers, Med _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
