IETF Last Call Review of draft-ietf-netmod-system-config-16
review-ietf-netmod-system-config-16-opsdir-lc-contreras-2026-01-09-00

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

---