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). ## 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? - 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. - 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)? - 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? - 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? ## 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. - 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. ## 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. - Annex B2: should not be "lo0" loopback interface instead of "lo" ? --- _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
