[netmod] Re: I-D Action: draft-ietf-netmod-system-config-06.txt

["Jan Lindblad (jlindbla)" <[e-mail]>]

Qiufang, WG,

Thank you for the effort you put into working out all the wrinkles of system config. I read the updated version, and I think it is a significant improvement. As usual, I have some comments, questions and suggestions. 😊 In order of appearance.

#1 Somewhat unclear conceptual model

Section 5.1 has a nice drawing of how the datastores relate to each other, and an introductory text that explains the interactions. The following sections explain how data can be copied from system to running, or can be filled in automatically using the resolve-system parameter. But the first sentence of section 5.1 is

Clients MAY reference nodes defined in <system>, override system-provided values, and configure descendant nodes of system-defined configuration in <running>.

In my mind, this is only true when the client uses the resolve-system parameter. Otherwise, a client cannot reference <system> directly, but needs to copy from <system> to <running>. So maybe the introductory sentences could be reworded?

#2 No way to squelch system config from intended

The software on a device decides what config from <system> that show up in <intended> (i.e. is considered “referenced”). If the client would like something not to flow through to <intended>, there is no mechanism for that.

Let’s say some device always creates a loopback0 interface in <system>. The client can change the loopback0 mtu by configuring it in running, but there is no way to entirely remove loopback0. Maybe a stupid example, but let’s say the client wants the loopback0 to be called lo0 instead. The same situation would arise for anything else in <system>, e.g. some system TPM security credential, system traffic classification rule or whatever else people may throw into <system>.

Is this a problem? Is this something that should be mentioned so that people leveraging <system> are aware of this limitation?

#3 Still unclear what needs to be copied

In section 5.2 it is explained how a client can copy data from system to running. The introduction in section 1 has some bullets about conditions that require copying to happen. Section 6 was added with some language about leafs with default values that need to be copied. The same need probably also applies to presence containers (which are not mentioned anywhere in -06).

All in all, I think the design work around the rules for what needs to be copied is hard to grasp in the current version, and is probably incomplete.

Similarly, section 5.3, which deals with what is being copied by resolve-system parameter should probably also refer to the same rules, once established.

#4 Resolve-system without <system>

At the end of section 5.3, there is a sentence about what a system should do if it supports resolve-system but not <system>.

If a server implements <system>, referenced system configuration is copied from <system> into the target datastore when the "resolve-system" parameter is used; otherwise it is an implementation decision where to copy referenced system configuration.

This sentence was a bit confusing to me. After reading it many times, I think an alternative text with similar meaning would be

If a server implements <system>, referenced system configuration is copied from <system> into the target datastore when the "resolve-system" parameter is used.

If a system does not implement <system>, it’s up to the implementation to determine how the resolve-system mechanism fills in the missing configuration items in the target datastore, e.g. <running>.

#5 Example missing ns qualifier

Section 5.5.1 has a nice example of how resolve-system works. But the example rpc that is using it is missing the namespace qualifier, I think. Isn’t this what it should look like?

<rpc message-id="101"
     xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
     xmlns:ncrs="urn:ietf:params:xml:ns:yang:ietf-netconf-resolve-system">
  <edit-config>
    <target>
      <running/>
    </target>
    <config>
      <acl xmlns="urn:example:acl">
        <acl-rule>
          <name>allow-access-to-ftp-tftp</name>
          <matches>
            <ipv4>
              <src-address>198.51.100.0/24</src-address>
              <dst-address>192.0.2.0/24</dst-address>
            </ipv4>
            <application>ftp</application>
            <application>tftp</application>
            <application>my-app-1</application>
          </matches>
          <packet-action>forward</packet-action>
        </acl-rule>
      </acl>
    </config>
    <ncrs:resolve-system/>
  </edit-config>
</rpc>

#6 Old value in example

The example in 5.5.3 and 5.5.4 used to change an mtu from 65536 to 65535. Since it’s somewhat hard to spot the difference between those values, you replaced 65535 with 9216. This is great. But I think the old 65535 value is still lurking there twice and should be replaced by 9216.

Section 5.5.4 starts with the following sentence.

In the above example, image the client further configures the description node of a "lo0" interface in <running> as follows:

Perhaps “image” should be “imagine”? And maybe it should be mentioned that the client is doing a merge, not a replace? How about this?

In the above example, imagine the client further configuring the description node of the "lo0" interface in <running> using a merge operation as follows:

#7 Implied semantics

Section 7.1 describes how the factory-default datastore is meant to be used. It is implied that the system datastore is not meant to be used in this situation, but it is never mentioned. Perhaps it would be worth mentioning that system is not to be used in this way?

#8 Confusing ietf-system-datastore example

The entire section 8 is devoted to describing  the tiny ietf-system-datastore module. There is an example there, but I have to admit I don’t understand what it is trying to show. And there must be something wrong with the last config snippet that shows the contents of <system> after the messages? Or maybe there is more going on here, that I never understood?

#9 Expand appendix A

Appendix A with its example showing many steps is very nice. But there it doesn’t show any of the more complex situations, e.g. when there are defaults, mandatory leafs, when statements or presence containers involved. Maybe the example could be extended?

Best Regards,
/jan




From: maqiufang (A) <maqiufang1=[e-mail]>
Date: Friday, 31 May 2024 at 10:54
To: [e-mail] <[e-mail]>
Subject: [netmod] Re: I-D Action: draft-ietf-netmod-system-config-06.txt
Hi, all

-06 tries to address comments received during WGLC, thanks a lot to Jan, Rob and Jason for your valuable inputs.
Major updates are following:
1. remove the definition of  inactive-until-referenced system config, -06 only defines two kinds of system config now: immediately-present vs. conditionally-present;
2. add a new section (see sec.6) to clarify the interplay between system config and defaults;
3. add a new section (see sec.7) to clarify relation to other datastores, which includes <factory-default> and <candidate>/<private-candidate>;
4. leave the merge behavior of <system> and <running> unspecified, as we think this is not specific to this document;
5. update figure 1 (architectural model of datastores) to make the arrows of <system> and <running> merge at a common point  flowing into <intended>;
6. augment <validate> and <commit> PRC operation to also support "resolve-system" parameter;
7. remove the implementation specifics related to "resolve-system" parameter;
8. other editorial fix as suggested by Jan and Rob;

There is one issue highlighted during WGLC, which will be posted in a separate thread for further discussion. The authors would like to request the WG to review the update and provide your feedback, any comments and suggestions would be much appreciated. Thanks!

Best Regards,
Qiufang //co-author

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Friday, May 31, 2024 3:06 PM
To: [e-mail]
Cc: [e-mail]
Subject: [netmod] I-D Action: draft-ietf-netmod-system-config-06.txt

Internet-Draft draft-ietf-netmod-system-config-06.txt is now available. It is a work item of the Network Modeling (NETMOD) WG of the IETF.

   Title:   System-defined Configuration
   Authors: Qiufang Ma
            Qin Wu
            Chong Feng
   Name:    draft-ietf-netmod-system-config-06.txt
   Pages:   39
   Dates:   2024-05-31

Abstract:

   This document defines how a management client and server handle YANG-
   modeled configuration data that is instantiated by the server itself.
   The system-defined configuration can be referenced (e.g., leafref) by
   configuration explicitly created by a client.

   The Network Management Datastore Architecture (NMDA) defined in RFC
   8342 is updated with a read-only conventional configuration datastore
   called "system" to expose system-defined configuration.

   This document updates RFC 8342, RFC 6241, RFC 8526 and RFC 8040.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-06

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-netmod-system-config-06

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


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