Subject: [netmod] Mohamed Boucadair's Discuss on draft-ietf-netmod-system-config-18: (with DISCUSS and COMMENT)
From: Mohamed Boucadair via Datatracker <[email-masked]>
To: "The IESG" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Date: Mon, 19 Jan 2026 02:11:10 -0800
List-Id: NETMOD WG list <netmod.ietf.org>

Mohamed Boucadair has entered the following ballot position for
draft-ietf-netmod-system-config-18: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hi Qiufang, Qin, and Chong,

Thank you for the effort put into this specification.

Also, thanks to Luis Contreras Murillo for the OPSDIR review and the authors
for engaging and implementing changes in -18. I see Luis has some follow-up few
suggestions, though.

Please find below some few points for DISCUSSion:

# Design approach

RFC 8342 has the following:

       dynamic              |   +-------- learned configuration
       configuration        |   +-------- system configuration
       datastores -----+    |   +-------- default configuration
                       |    |   |
                       v    v   v
                    +---------------+
                    | <operational> | <-- system state
                    | (ct + cf, ro) |
                    +---------------+

A design approach that would not impact other datastores is to expand the
“system configuration” branch above and replace it with <system>. That would be
also consistent with the hierarchy of origin identity defined in RFC 8342:

   The values are YANG identities.  The following identities
   are defined:

   o  origin: abstract base identity from which the other origin
      identities are derived.

   o  intended: represents configuration provided by <intended>.

   ...

   o  system: represents configuration provided by the system itself.
      Examples of system configuration include applied configuration for
      an always-existing loopback interface, or interface configuration
      that is auto-created due to the hardware currently present in the
      device.

## Is there any reason why that approach is not followed compared to grafting
<system> to <intended> as in the current version of the draft?

## Note that with the current design, there are parts of RFC 8342 that needs
“tweaking”

An example is provided below (there are other similar occurrences):

RFC 8342:
   The system will only provide configuration for this
   interface if there is no data for it in <intended>.

   When no configuration for "lo0" appears in <intended>, <operational>
   will show the system-provided data:

     <interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
                 or:origin="or:intended">
       <interface or:origin="or:system">
         <name>lo0</name>
         <ip-address>127.0.0.1</ip-address>
         <ip-address>::1</ip-address>
       </interface>
     </interfaces>

# Origin metadata annotation is normative

CURRENT:
   *  Origin: This document does not define any new origin identity.
      The "system" identity of origin metadata annotation [RFC7952] is
      used to indicate the origin of a data item provided by the system.

This is needed to tag system ds.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# Desire

CURRENT:
   However, there is a desire to enable a server to better expose the
   system configuration, regardless of whether it is in use.

Desire of whom?

# Root

CURRENT:
   *  YANG nodes: all "config true" data nodes up to the root of the
      tree, generated by the system.

This seems to assume one single data tree. Is that intended?

If not, I think that it is accurate to use the following:

NEW:
   *  YANG nodes: all "config true" data nodes up to the root of a data
      tree, generated by the system.

# It is weird to reason about modification for read-only ds

OLD:
  6.3.  Modifying (Overriding) System Configuration

NEW:
  6.3.  Overriding System Configuration

# IANA template for registration

OLD:
   This document registers one YANG module in the 'YANG Module Names'
   registry, defined in [RFC6020].

NEW:
    IANA is requested to register the following YANG module in the "YANG
    Module Names" registry [RFC6020] within the "YANG Parameters"
    registry group.

# Examples are not normative

CURRENT:
   The updates of system
   configuration may be obtained through YANG notifications (e.g., on-
   change notification) [RFC8639][RFC8641].

[RFC8639] and [RFC8641] are listed as normative, while these should not. Please fix that.

# Nits

## Split long sentences + proper RFC citation

CURRENT:
   This document updates RFC 8342 to define a configuration datastore
   called "system" to hold system configuration (Section 3), it also
   redefines the term "conventional configuration datastore" from
   [RFC8342] to add "system" to the list of conventional configuration
   datastores.

or

CURRENT:
   The "intended" identity of origin value defined in [RFC8342]
   represents the origin of configuration provided by <intended>, this
   document updates its definition as the origin source of configuration
   explicitly provided by clients, and allows a subset of configuration
   in <intended> that flows from <system> yet is not configured or
   overridden explicitly in <running> to use "system" as its origin
   value.

Cheers,
Med