Hi Qiufang, Thank you very much for addressing my comments and for the clarifications. They are OK for me.
Best regards, Ines On Thu, Jan 8, 2026 at 9:39 AM maqiufang (A) <[email protected]> wrote: > 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]
