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

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

Hi, Jan,

Thanks a lot for taking the time to review the update! Apologies for being late on this response. The authors have submitted a new version (https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-07) to resolve your comments, please also find my reply below.

From: Jan Lindblad (jlindbla) [mailto:jlindbla=[e-mail]]
Sent: Wednesday, June 5, 2024 12:14 AM
To: maqiufang (A) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [netmod] Re: I-D Action: draft-ietf-netmod-system-config-06.txt

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?
I think this sentence mentioned clients could reference system configuration (i.e., configure some nodes referring to system provided instance), but doesn’t specify how that could be achieved to make <running> valid (i.e., explicit declaration vs. using “resolve-system” parameter).
But to avoid any misunderstanding, how about the following update in sec.5.1?
Clients MAY reference nodes defined in <system>, override system-provided values, and configure descendant nodes of system-defined configuration in <running>, as detailed in Section 5.2, Section 5.3, and Section 5.4.
Please let me know if you have better suggestions.

#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?
Just want to make sure that I fully understand this comment, when you say the problem/limitation, are you referring to the fact that system-defined list entry is non-deletable to clients?
Because when it comes to updating the list key, RFC7950 already doesn’t allow key value to be changed (if I understand it correctly), we can only create or remove the entire list instance.
I agree that the client can define a new entry in <running> called lo0, but loopback0 would always be present.
Please see if the following update works for you:
OLD: Configuration in <system> is non-deletable to clients, even though a client may delete a copied system node from <running>.
NEW: Configuration in <system> is non-deletable to clients (e.g., a system-defined list entry can never be removed), even though a client may override or delete a copied system node from <running>.
Or please feel free to propose any text;-)
#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.
Please review the update of section 5.2<https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-07#section-5.2> and section 5.3<https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-07#section-5.3>, and let us know if you still think it unclear, or even better, feel free to propose any text.
Note that the contents of copy in both sections have been expanded to copy the entire node (e.g., the entire list entry) in -07, in order to not to confuse some clients that if some config wasn’t copied because it wasn’t set vs. it’s not being necessary in order to pass validation. To copy the entire is also easier for the implementation of the “resolve-system” parameter without asking the server to calculate the minimum.

#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>.
Updated as suggested.

#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>
Fixed. Thanks a lot.

#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:
All fixed, thanks for pointing this out.
#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?
Okay, section 7.1 adds the following:
Deletable system configuration must not be defined in <system>.
Good for you?
#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?
Sorry for being unclear, I agree that section 8.2 doesn’t really exemplify the data retrieval from <system>, the example has been updated to additionally provide a NETCONF <get-data> RPC operation towards <system>. Would this be better for you?
#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?
The updated examples both in sec.5.5 and appendix A have incorporated some cases like defaults, mandatory, when statement and presence containers, please let us know if something else is needed. Thanks a lot.
Best Regards,
/jan

Thanks again for your valuable comments.

Best Regards,
Qiufang

From: maqiufang (A) <maqiufang1=[e-mail]<mailto:maqiufang1=[e-mail]>>
Date: Friday, 31 May 2024 at 10:54
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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]> [mailto:[e-mail]]
Sent: Friday, May 31, 2024 3:06 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[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]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
_______________________________________________
netmod mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>