Hi, Ines,
Thanks a lot for the careful review, the authors try to update the draft to incorporate your comments below, and the diff is available at: https://author-tools.ietf.org/diff?url_1=https://raw.githubusercontent.com/netmod-wg/system-config/refs/heads/Qiufang-1/draft-ietf-netmod-system-config-17.txt. Please also see my response below inline with [Qiufang]... -----Original Message----- From: Ines Robles via Datatracker [mailto:[email protected]] Sent: Wednesday, January 7, 2026 9:32 AM To: [email protected] Cc: [email protected]; [email protected]; [email protected] Subject: draft-ietf-netmod-system-config-16 ietf last call Genart review Document: draft-ietf-netmod-system-config Title: System-defined Configuration Reviewer: Ines Robles Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-netmod-system-config-16 Reviewer: Ines Robles Review Date: 2026-01-06 IETF LC End Date: 2026-01-06 IESG Telechat date: Not scheduled for a telechat Summary: This document introduces the concept of a system configuration datastore holding configuration controlled by the system on which a server is running. The system configuration can be referenced by configuration explicitly created by clients. The document is complete and well written. I have a few questions and comments that would be helpful to address before publication. Comments/Questions: 1.- Section 1.1: Given that <system> is read-only to clients, how does the definition of “conventional configuration datastore” apply to <system>, particularly with respect to statements about copying data between datastores? Is “conventional” intended to refer primarily to shared schema structure rather than to support for operational behavior such as copying? [Qiufang] You are raising a good point. The current definition inherits the statement from 8342, which also defines <intended> (read-only datastore) as a conventional configuration datastore as well. This might be slightly misleading. But also note that a client can indeed read from <system> and copy that data into other conventional datastores (e.g., <candidate> or <running>), while any protocol operation that attempts to copy data into <system> MUST fail. I am trying to add some clarification in the draft on this point, such as : Note while protocol operations allow copying data between conventional datastores, the read-only nature of datastores such as <system> and <intended> restricts copying data into them. Thoughts? 2.- It would be nice to update the terminology to include the new definition of <intended>, in addition to its description in Section 1.3. [Qiufang] This draft does not update the definition of <intended> (i.e., "intended configuration datastore" term in https://datatracker.ietf.org/doc/html/rfc8342#section-3), it updates the meaning of "intended" origin metadata annotation defined in https://datatracker.ietf.org/doc/html/rfc8342#section-5.3.4. I am unsure if this can be a standalone term, as it is more about a specific value (identity) of the origin annotation. Note the "origin" itself is formally defined in the terminology section of 8342 ("intended" is one of its value). 3.- The document describes <system> as a configuration datastore, but the way <system> behaves closely resembles default system behavior. The values in <system> are created by the system, can be overridden by the user, and reappear when the user removes the override. It is therefore unclear whether <system> is intended to represent what the user intends to configure, or whether it represents system-provided default values that apply when the user has not configured anything. In other words, is <system> intended to express configuration intent, or system-provided defaults, capabilities, or behavior that fill in missing intent (i.e., that apply when the user has not configured anything)? A brief clarification in the document would help avoid this ambiguity. [Qiufang] <system> serves as a read-only source system defined configuration, the configuration in <system> comes and goes, which is beyond the control of clients. While clients can interact with system configuration (by editing <running>), nothing affects the contents of <system>. Note <running> holds the configuration provided by clients, <intended> holds the configuration intended to be applied by the device, <operational> holds the configuration successfully applied by the device. Given all these definition in this draft and 8342 , and what is clarified in https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-16#section-4, is there anything else that you think needs to be clarified in the draft? 4.- For clarity, how are override semantics expected to behave across a reboot? What happens to <running> when the device reboots? [Qiufang] Typically <running> contents will not be lost across reboots, but <system> contents will be reloaded (e.g., a hardware may be absent now that was present before), so <intended> will also be updated immediately when <system> changes (<intended> reflects the merging results of <system> and <running>). The draft says: "Whenever configuration in <system> changes, the server MUST also immediately update and validate <intended>." You may also see https://datatracker.ietf.org/doc/html/rfc8342#section-5.1 for detailed definition of <running> and <intended>. 5.- If <system> is read-only to clients but can change due to upgrades or hardware events, could it be clarified whether clients should expect <system> to remain stable for the duration of an operation, or whether it may change at any time? [Qiufang] Given system may change if there are system events or resource changes, I don’t think client should expect <system> to remain stable, but the draft also states notification can be leveraged to learn what has been updated. Anything else that needs to be clarified then given what is in https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-16#section-6.1? 6.- RFC 8342 defines configuration transformations as occurring between <running> and <intended>. Section 4 of this draft states that, if <system> or <running> includes configuration that requires further transformation, such transformations MUST be performed before merging. Given this, could it be clarified: 6.1.- whether transformations are applied independently to <running> and <system>, [Qiufang] Have added that "..., configuration transformations MUST be performed independently to each datastore before <running> is merged with <system>." 6.2.- whether <system> is already fully transformed before it is exposed, and [Qiufang] The document already says that <system>/<running> may include configuration that requires further transformation (e.g., template expansion, inactive configuration removal), this implies that <system>/<running> is not transformed when exposed. Fig.1 also implies that it is <intended> that contains the configuration after transformation. Does this make sense? 6.3.- whether transformations are persistent or recomputed each time <system> and <running> are processed? [Qiufang] This might depends on whether the template/inactive configuration has changed. For example, if there are new templates defined in <system>, transformations must be done to update <intended>, otherwise, I feel that this is implementation-specific details to decide whether to re-transform each time to update <intended>. Regardless of the method/approach, the content of <intended> remains unaffected, and interoperability is not impacted. 7.- Section 6.3 allows overriding system-provided settings only when the server permits it. Thus: 7.1.- How can a client determine which nodes can be overridden? [Qiufang] The document has a reference to draft-ietf-netmod-immutable-flag, which defines an immutable flag to allow the client to discover the immutability of system configuration. 7.2.- Is the set of overridable nodes fixed, or can it change at runtime? [Qiufang] This is also documented in the immutable-flag draft that (https://datatracker.ietf.org/doc/html/draft-ietf-netmod-immutable-flag-06#section-3) : " The immutability of any configuration data, and the value of any immutable configured data node, MUST only change via software upgrade, hardware resources change, or license change." 7.2.- If a node is marked as configurable in the YANG schema but the server may still forbid overriding it, how should clients interpret and rely on that information? [Qiufang] Clients should interpret the YANG schema's config true declaration as indicating that a node is conceptually configurable, but they must rely on the runtime "immutable" annotation to determine actual immutability. Immutable-flag has some use cases for this, e.g., some system defined list entries are immutable, but clients may define their own list entries, and those are mutable. Thus the list should be "config true". This is not to say that servers must have system configuration that cannot be overridden, but to document an existing behavior implemented by servers today. Nits 8.- Section 8.2- datatstore --> datastore ? [Qiufang] Fixed. 9.- Section 1. some implementations defines --> some implementations define [Qiufang] Fixed. 10.- the descendant nodes of system-defined configuration --> the descendant nodes of system-defined configurations [Qiufang] This is the one that I tend to keep it in the singular, as we want to treat "system-defined configuration" as an uncountable, collective concept, instead of enumerate distinct configurations. 11.- Section 2.1: irrespective of physical resource present or not, a special functionality enabled or not --> irrespective of whether physical resources are present or whether a special functionality is enabled? [Qiufang] Fixed. 12.- Section 3: manage operations --> management operations ? [Qiufang] Fixed. Thanks for spotting this. Thanks for this document, Ines. Best Regards, Qiufang //co-author
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
