[netmod] Re: draft-ietf-netmod-system-config-16 ietf last call Opsdir review

["maqiufang (A)" <[e-mail]>]

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:[e-mail]]
Sent: Saturday, January 10, 2026 12:30 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
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