[netmod] Re: 2nd WGLC on system-config-08

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

Hi, Kent, Jan, all,

Sorry for being late in replying, thanks Jan and Jürgen for the review, I will see how to address the comments once we reach agreement on this “copy or merge” issue… please find more reply inline…

From: Kent Watsen [mailto:[e-mail]]
Sent: Wednesday, August 21, 2024 1:06 AM
To: Jan Lindblad (jlindbla) <jlindbla=[e-mail]>
Cc: [e-mail]
Subject: [netmod] Re: 2nd WGLC on system-config-08

Hi Jan,


After us all now having investigated this line of reasoning, my conclusion is that we have to choose one of two approaches:

The primary open-question is if it is *needed* for a client to copy <system> nodes into <running>.  IMO, to understand the requirements, this question must be answered first.

The draft highlights three reasons:
  1. so running-alone can be valid (e.g., 5.5.1 and 5.5.2)
  2. so system-defined values can be changed (e.g., section 5.5.3)
  3. so descendents can be added to system-defined nodes (e.g., 5.5.4)

Each are discussed below.

Regarding #1, I’m sympathetic to not flipping an established client-contract without warning.  My proposal is to version the protocols (i.e. NETCONF 1.2 and RESTCONF 1.1) to indicate this change in behavior.  That is, a server implementing the <system> datastore would have to implement the updated protocol versions.  So, for this item, it seems that it is not *needed* for a client to copy nodes into <running>, if the protocols are versioned.
If we move towards this way, does this mean the draft needs to be pending until new versions of protocols are published?
But even if <running> alone doesn’t have to be valid, no one would stop a client keep copying referenced system nodes into <running>, e.g., if no template used in <running> and the client wants to do offline validation of <running>. The current draft simply allows the client to do that, it no longer states the client MUST copy any referenced system nodes into <running>.

I kind of feel like we are back where we started, after around 4 years’ discussion. I think the agreement at the interim in January was to effectively say nothing in the draft and fully rely on existing statements in RFCs. I think this approach gives flexibility and allows the server to behave the way they do today. And then when we comes to the discussion of NC/RC-next, we may decide whether there are benefits to relax the rule and make further clarifications. Any issue we see now with this handling?
Regarding #2, I am firstly unclear how this is needed, when we’re only just now, for the first time, exposing system-defined configuration.  Up to now, system-defined configuration only appeared in <operational>, with no ability to tweak it, right?  Secondly, the example is not compelling, e.g., why would a client care what the MTU is on the loopback interface?  But, if this is important, how do vendors enable it to be changed today?
In our implementation, there are non-modifiable/immutable and modifiable system configuration. the server allows the client to directly write the desired value into <running> which overrides the value provided by the system, such examples could be, e.g., to modify some log levels generated by the running systems, or system-provided threshold values.
Regarding #3, same as #2: how is this needed?  The example is not compelling.  If this is important, how do vendors enable such extensions today?
But isn’t the following example common?
System configures a physical interface instance with only name and type leaf specified, and the client can further configures other descendant nodes, e.g., ip-address.

I feel that #2 and #3 are not really the “copy” things, they are about editing some parts of system configuration.
But speaking about copy, the authors are considering removing the “resolve-system” parameter, for the following reasons:

·         It is complex and expensive to implement properly (see the last paragraph in https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-05#section-5.3)

·         It is optional to implement, and there is workaround (i.e., explicit copy)
Given reasons above, I doubt if it will be implemented in real world;-) Any objections to removing this “resolve-system” parameter?


Kent // as a contributor
Best Regards,
Qiufang