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:[email protected]] Sent: Wednesday, August 21, 2024 1:06 AM To: Jan Lindblad (jlindbla) <[email protected]> Cc: [email protected] 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
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
