Hi, Luis,
Thanks a lot for the review, a new version is submitted to address your comments below, the diff is available at : https://author-tools.ietf.org/iddiff?url2=draft-ietf-netmod-system-config-18. Please also see my reply below inline with [Qiufang]... -----Original Message----- From: Luis Contreras via Datatracker [mailto:[email protected]] Sent: Saturday, January 10, 2026 12:30 AM To: [email protected] Cc: [email protected]; [email protected]; [email protected] Subject: draft-ietf-netmod-system-config-16 ietf last call Opsdir review Document: draft-ietf-netmod-system-config Title: System-defined Configuration Reviewer: Luis Contreras Review result: Has Issues Hi, I have been selected as the Operational Directorate (opsdir) reviewer for this Internet-Draft. The Operational Directorate reviews all operational and management-related Internet-Drafts to ensure alignment with operational best practices and that adequate operational considerations are covered. A complete set of _"Guidelines for Considering Operations and Management in IETF Specifications"_ can be found at https://datatracker.ietf.org/doc/draft-opsarea-rfc5706bis/. While these comments are primarily for the Operations and Management Area Directors (Ops ADs), the authors should consider them alongside other feedback received. - Document: draft-ietf-netmod-system-config-16 - Title: System-defined Configuration - Reviewer: Luis M. Contreras - Review Date: 2026-01-09 - Intended Status: Standards Track --- ## Summary - Has Issues: I have some minor concerns about this document that I think should be resolved before publication. ## General Operational Comments Alignment with RFC 5706bis The draft defines a new system configuration datastore as an extension of the Network Management Datastore Architecture (NMDA) from RFC 8342; this datastore holds configuration that is provided and controlled by the system itself rather than by management clients. It introduces the concept of a read-only conventional configuration datastore called “system,” standardizing how system-defined configuration is exposed to clients, how it may be referenced (e.g., via leafref) or overridden by client-provided configuration, and how it integrates into the overall NMDA merge model. The work requires compliant NMDA servers to implement the ietf-system-datastore YANG module and updates RFC 8342’s definition of conventional datastores to include the system configuration datastore, enabling consistent access and usage of system-provided configuration across NETCONF/RESTCONF management operations The Operational Considerations section is missing and should be included, according to draft-ietf-opsawg-rfc5706bis. In particular, it would be good to add a description on implications in terms of backwards compatibility, and/or implications when porting configuration from legacy devices to new ones supporting this system-defined configuration (migration paths, etc). [Qiufang] Have added a new section to discuss operational considerations. ## Major Issues - Section 4. It is stated: “If it is desired to enable a client to delete system configuration, it can be approximated using <factory-default> ([RFC8808]).” It is not clear to me the difference between system-defined configuration and factory-default configuration. Specially because it is mentioned at the end of section 3 that “The system configuration datastore doesn't persist across reboots.”. Does this imply that system configuration is loaded after reboot? If so, in which part of the process the system-defined configuration is created? How far can be the system-defined configuration from the factory-default? How this relates with the always-present configuration generated in <system> when the device is powered on, as described in section 2.1? What is the relationship with the <startup< datastore depicted in Figure 1? [Qiufang] The concept of system configuration exists already since NMDA, while this draft proposes system datastore to hold system configuration. The different between <system> and <factory-default> is that, <factory-default> is the configuration that is used to initialize <running> when the device is first-time powered on or reset; while system provided configuration will not appear in <running> by default but will always be loaded and intended to be applied. We try to state less about <factory-default> because this is referring to the scope of <factory-default>. I also removed this sentence as it might bring confusion, as per your comments below. So when we discuss system configuration, it is non-deletable, if system provides some configuration that can be deleted, perhaps it should not be called system configuration, perhaps it should just be called factory-default configuration, or something else, which is out of scope of this draft. - On the same sentence: it is a bit weird the expression of that “it can be approximated”. This is not clear in terms of operational effects. [Qiufang] As my comment below, this sentence is removed now. - Section 5.1 on Read-only to Clients. How consistent is this wrt the previous comment (i.e., the possibility of the client to delete the system configuration)? [Qiufang] Hopefully my clarification above helps avoid the terminology confusion. - On the dynamic behaviors as per section 6.1 “May Change via Software Upgrades or Resource Changes”. If the contents of <system> may change by licenses, etc, is it foreseen or expected any kind of warning or advice in this respect? [Qiufang] The document already says: “The updates of system configuration may be obtained through YANG notifications (e.g., on- change notification) [RFC8639][RFC8641].” Is there anything else that you think needs to be added? - Section 6.3 describes the possibility of modifying (overriding) system configuration. What happens if an overwritten value changes from the system perspective as consequence e.g. of a license as described in section 6.1? Is it kept the overwritten value or it is considered the new system value? [Qiufang] The merging logic as described in Sec.4 applies here. If the value is mutable, configuration provided by the client takes precedence and <intended> still contains the overridden value. ## Minor Issues - It seems along the text that device and server are used interchangeably. It would be good to clarify, or as alternative, to use one single terminology for consistency. [Qiufang] Thanks for spotting this, the following sentence has been added: "The terms "device" and "server" are used interchangeably in this document." - Section 6.1. I wonder if SHOULD in the sentence “If system configuration changes, <running> SHOULD remain a valid configuration data tree” should be MUST. [Qiufang] this is based on some previous discussion in WG. There are some cases like when device upgrade, <system> may change and <running> becomes invalid, and there might need some handling to ensure <intended> (and <running>) remains valid. Some previous versions have examples of how a server/client may behave to ensure validity of <running>. But the WG then decides to just allow <running> to become invalid in such cases, and how to ensure the validity of <running> is out of scope. ## Nits - Section 2.2: “Another example is when a special functionality is enabled, e.g., when a license or feature is enabled, specific configuration may be created by the system.” Maybe change the second “enabled” by “activated” or similar for avoiding repetition. [Qiufang] Have fixed this sentence as follows: “Another example is when a special functionality (e.g., a license or feature) is enabled, specific configuration may be created by the system.” - Annex B2: should not be "lo0" loopback interface instead of "lo" ? [Qiufang]Fixed, thanks. --- Best Regards. Qiufang
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
