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" ?

---