[netmod] Re: Mohamed Boucadair's Discuss on draft-ietf-netmod-system-config-18: (with DISCUSS and COMMENT)

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Med,

+1 to Quifang's comments.  Effectively, I think that this was a limitation in the original NMDA architecture that is being corrected.

Kind regards,
Rob


From: maqiufang (A) <maqiufang1=[e-mail]>
Date: Tuesday, 20 January 2026 at 04:00
To: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, Kent Watsen <[e-mail]>, [e-mail] <[e-mail]>, NETMOD WG <[e-mail]>
Subject: [netmod] Re: Mohamed Boucadair's Discuss on draft-ietf-netmod-system-config-18: (with DISCUSS and COMMENT)

Hi, Med,

Thanks a lot for the review. While the authors are preparing a new version to address your comments below, please find some of my response below inline with [Qiufang]...

-----Original Message-----
From: Mohamed Boucadair via Datatracker [mailto:[e-mail]]
Sent: Monday, January 19, 2026 6:11 PM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Mohamed Boucadair's Discuss on draft-ietf-netmod-system-config-18: (with DISCUSS and COMMENT)

----------------------------------------------------------------------
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.
[Qiufang] Yes, I do see the follow-up from Luis, sorry for the delay. I am preparing a new version to incorporate the follow-up suggestions, as well as your comments below.

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?
[Qiufang] Having system configuration only present in <operational> does not really make sense , as the configuration provided by the client needs to interact with system configuration (i.e., reference/override/configure descendant nodes of system configuration).  For example, there is some system configuration which is predefined for the convenience of clients, e.g., built-in rules, policies. A client should be able to reference a system-defined policy without copying it into <running>, and to allow <system> feeds into <intended>, the merging result in <intended> does pass the validation.
The current architecture also allows the existence of system-defined templates and inactive system configuration, which are similar concepts defined in NMDA, except that they are provided by the server.
Hopefully this clarifies.


## 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>
[Qiufang] This is a good point. I am not convinced that the presence of system configuration should depend on the configuration in <running>. It is also unclear in C.3.2 of 8342, as the first sentence says " Imagine that the system provides a loopback interface (named "lo0") with a default IPv4 address of "127.0.0.1" and a default IPv6 address of "::1". ", and then contradictorily followed by your sentence above. Would it be okay for appendix B in draft-ietf-netmod-system-config to update https://datatracker.ietf.org/doc/html/rfc8342#appendix-C.3.2?


# 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.
[Qiufang] How about the following update:
OLD:
   *  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.
NEW:
   *  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 in <system>.


----------------------------------------------------------------------
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?
[Qiufang] How about the following?
OLD:
   However, there is a desire to enable a server to better expose the
   system configuration, regardless of whether it is in use.
NEW:
   However, there is a desire from operators to enable a server to better expose the
   system configuration, regardless of whether it is in use.

# 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?
[Qiufang] Yes, note 8342 states something similar, e.g.,  <running>/<intended> MUST always be a valid configuration data tree.

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
[Qiufang] I think there should be distinction between system configuration and <system>.  Note that the draft already states:
The system datastore is read-only (i.e., edits towards <system>
   directly MUST be denied), though the client may be allowed to provide
   configuration that overrides the value of a system-initialized node
   (see Section 6.3).

Best Regards,
Qiufang

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



_______________________________________________
netmod mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]