Hi Qiufang, > 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?
Possibly, but let’s not focus on this now. > 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>. It is true that it would be impossible to prevent a client from copying entire <system> nodes into <running> so, in any case, the interplay still needs to be defined. > 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? True, but you see how it blew up? That’s why I wanted to go back to the requirements. For #1, I continue to conclude that it is not required (from a long-view perspective) to copy system-nodes into running. > 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. Thank you for providing this concrete example. I agree that it is a valid example. However, I don’t feel that it represents a case where system-nodes are *copied* into running. It seems more like the client is just setting regular configuration, for which the system has default values that are used when not set by <running>. It is possible that my perspective for this case equally applies to all such #2 cases. What we have done recently to complicate the #2 case is to say that the entire system-node MUST be copied into <running>, which is truly more than the client just setting some configuration. However, the desire to copy the entire-node is directly tied to the “running-alone must be valid” position. If we assume that clients MUST use updated protocol versions (NC/1.2, RC/1.1), then this “problem" goes away, and it seems that we could conclude that <system> nodes are NOT being copied into <running>. Makes sense? > 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. You are right. This is a valid example...and one that I often use myself in the context of LNEs. My comment to #2 equally applies here. FWIW, a client could put any interface name, and either it overlays with a system-define node or not, and the rules from NMDA’s “missing resources” section will cull-out any mismatches. > I feel that #2 and #3 are not really the “copy” things, they are about > editing some parts of system configuration. Exactly. :) I think the only difference between where we were before and now is a matter of perspective. It isn’t a copy, if the full-node isn’t required, which is only possible if we assume the clients MUST use an updated protocol version that requires clients to know that running alone may not be valid, for servers that support any of the following: inactive, template, system, etc. > 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 > inhttps://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? No objection. Quite the opposite, I think it is a good idea, for all the reasons you stated, and the additional reason that it suggests/conveys that the “copy” is occurring, which I think is a position that we should try to move away from. Kent // as a contributor
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
