Kent, Thanks for going through my comments. Find my responses below as [janl].
On Aug 15, 2024, at 9:25 AM, Jan Lindblad (jlindbla) <[email protected]> wrote: Quifang, WG, I have read the latest (-08) version of the draft carefully. I think it is well written, but I do have a few comments/questions. #1) Removal of system config list entries Section 5.1 states: To ensure the validity of <intended>, configuration in <running> is merged with <system> to become <intended>, in which process, configuration appearing in <running> takes precedence over the same node in <system>. This is very good of course. If the client wishes for a different leaf value than one in the system datastore, just write it in running (assuming the server allows it). But what if the client wishes that some part (e.g. list entry) of the system config is left out from running? Do you mean the last word above to be “intended”? [janl] Yes, that is what I should have written. With the approach described above, it does not seem obvious that anything from system would be left out from intended, even if it is not mentioned in running. My reading is that nothing in <system> is left out when <intended> is created, sans: - any “inactive” nodes - any unreferenced "shared objects” - any templates that are expanded (if templates supported in <system>) - other things like this. Back to the point, clients do not get to delete <system> configure. [janl] Good that our understandings are in agreement. That the client has no way of preventing unwanted system config from showing up in intended is perhaps a tad inflexible. Reading further in section 5.2: When declaring a node having descendants, clients MUST also declare all descendant nodes, including any leafs, leaf-lists, lists, presence containers, non-presence containers that have any child nodes. Does this imply the client could indeed prevent selected parts of the system datastore configuration to not appear in intended by simply not including them in running? I don’t think deletion is intended. Rather the goal is to ensure a full-copy is in <running>, hence the “MUST”. IIRC, this approach is a direct response to a previous comment of yours... [janl] While I did not come up with the wording used in the draft, I agree that my previous comments is a probable root cause. After us all now having investigated this line of reasoning, my conclusion is that we have to choose one of two approaches: + either the system datastore exists as a source of inspiration for clients to copy from, but it’s up to clients to explicitly or implicitly (i.e. use “resolve-system”) curate the contents of running. System datastore contents does not magically flow into intended. A bit heavy handed, perhaps, but this is probably doable without new protocol versions. + or we define the system datastore such that all of its content flows into intended, perhaps with some sort of override mechanism in running. I guess this is closer to the original vision of the system datastore. The downside is that it severely breaks the contract with current clients out there, and would require some new protocol versions, imho. I also have a feeling there are several unresolved issues left along this path, so we’re maybe not as close to done as we might think (considering that we are in 2nd WGLC) if we take this direction. I wrote some more about these thoughts in the response to Jürgen’s mail a few minutes ago. In this case, wouldn’t it be fair to say clients cannot reference nodes in system, but only nodes that have been copied to running one way or another? Wouldn’t the topic of this draft then be more about mechanisms for copying data from system to running than about how system is merged into intended? It is sad how the short-term “running alone must be valid” position is causing such issues. The original goal was (is still?) to let vendors define some system-config, some of which makes sense for clients to reference (for convenience). We then added overrides and descendants, and seemingly lost sight of the goal. I question if the current approach is best. Maybe a “take it as it is defined in <system> or define your own in <running> approach” would be better? [janl] Yes, when I started that sub-discussion, I did not see this situation coming. But I’m glad we discovered the result now rather than later. I’d certainly be interested to hear more about the “take it as it is defined in <system> or define your own in <running> approach”. Could you elaborate? #2) System + Running datastore merge process Section 5.1 also states: If <running> includes configuration that requires further transformation (e.g., template expansion, removal of inactive configuration defined in [RFC8342]) before it can be applied, configuration transformations MUST be performed before <running> is merged with <system>. This seems to imply that the system datastore cannot contain any kind of templating mechanism, e.g. some sort of interface template in systems with lots of interfaces. I don’t have any particular opinion, just raising the question if this is what we want. My reading is that the text doesn’t imply that, so much as, if <system> uses a templating mechanism, that its templates must also be expanded before the merge can occur. We (presumably) define how to merge configuration, but how to merge templates is not defined (templates aren’t defined yet but, if they were, merging them might not be defined). If we agree, it would be good for the document to be clear about it. [janl] Fair enough. I agree we need more clarity here, and then we can evaluate what’s best. #4) Will validation make changes? Section 7.2 states that The client may use the "resolve-system" parameter in one of the following situations: … * The client issues a <validate> operation. If a client issues a validate with the resolve-system flag set, will that modify the target datastore? If so, let’s say a client removes a reference to a system datastore object and runs validate with resolve-system again. Would the system datastore objects copied earlier be removed this time? Regardless of which way it is, it appears rather complicated to me to implement the logic in section 7.2 as worded right now. Maybe only allowing resolve-system on edits and not on validate and commit would reduce the complications? I do not think validation should be allowed to make changes. Stated differently, the <validate> RPC (in NETCONF) should be (is already defined to be?) idempotent. If “resolve-system” expansion in <running> is needed (and I’m unsure if it ever is, on a server), then I envision that expansion to be in an internal/ephemeral "running” that is discarded immediately after the validation completes. [janl] Agree completely that validate should not update the datastores. But either way, I find this complex to implement and resource heavy to manage in runtime. If we keep resolve-system, couldn’t that work directly on the edit-configs etc.? Thank you Qiufang and Kent for your relentless work on this. Best Regards, /jan
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
