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? 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. 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. 4.- For clarity, how are override semantics expected to behave across a reboot? What happens to <running> when the device reboots? 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? 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>, 6.2.- whether <system> is already fully transformed before it is exposed, and 6.3.- whether transformations are persistent or recomputed each time <system> and <running> are processed? 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? 7.2.- Is the set of overridable nodes fixed, or can it change at runtime? 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? Nits 8.- Section 8.2- datatstore --> datastore ? 9.- Section 1. some implementations defines --> some implementations define 10.- the descendant nodes of system-defined configuration --> the descendant nodes of system-defined 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? 12.- Section 3: manage operations --> management operations ? Thanks for this document, Ines. _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
