Hi, Balázs, Thanks for the comments, please see my reply inline. P.S. I notice that some of the issues is related to auto-populate operation from <system> into <running>(e.g., will not delete system configurations which has already been populated into <running>, allow a delete operation and reload automatically). Since there are some concerns about auto-populate because it may violate the definition of <running>, I think it would be good to further discuss these issues only after the WG reaches a consensus on auto-populate.
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Balázs Lengyel Sent: Sunday, August 1, 2021 12:01 AM To: 'netmod@ietf.org' <netmod@ietf.org> Subject: [netmod] Comments on draft-ma-netconf-with-system-02 Hello, MAJOR: The purpose of the draft (the purpose of creating a new datastore) should be clearly stated. In my view: "There is a need to validate configuration data against data created by the system." [Qiufang Ma] The purpose of introducing a new datastore to hold all the system configuration is that, there is a need to validate configuration data against data created by the system. That is to say, we need a datastore to hold the pure system configuration. The system configurations present in <operational> are those in use. There exists some system configurations which will not take effect by default until being referenced. They are not present in <operational> with a high probability, thus no way to retrieve. And also because if a system configuration data item is referenced or modified explicitly by the operators, it will be present in <operational> with its origin value set to be intended rather that system, and there is no way to retrieve original system configuration before modification. What is the purpose of system-configuration Use-case A) The system sets some values because it knows what they shall be. In this case the client must not be allowed to modify these values. We want to check configuration data against these values. E.g., AcmeHomeRouter has 5 interfaces called eth0, eth1, eth,2, eth3 and WAN. The client should not try to add or remove interfaces to this set. Use-case B) The system provides initial values for something that can be configured in many ways. In this case the client is free to modify the system-defined values. E.g., an initial set of NACM rules is provided. In this case any constraints based on the system data are very weak, as the user can change the system-data itself. Use-case a) is very interesting and we actually implemented non-standard support for it. I would welcome it in an RFC. I, myself tried to address this in https://github.com/netmod-wg/yang-next/issues/41 Use-case b) IMHO does not require any special support. I will just load the initial configuration as a last step of a reset, upgrade etc. [Qiufang Ma] The motivation of this work is that the referenced system configurations must be retrieved from <operational> and then copied into <running> to make sure a successful validation, which is inconvenient. This applies to both use cases. I understand the issue you raised in use case A, but I am not sure if we should resolve it in this draft. I think it's something we need to investigate. Can a client remove or change a system-configuration data-node that is automatically or manually copied to running/intended? In use-case A) NO. In use case B) yes. Allowing some modifications, but not others is IMHO misleading and not acceptable. Assuming that additions are OK while delete is not could be incorrect if, the absence of some data node is important for the network node. [Qiufang Ma] So are you suggesting that we should not allow system configuration modifications even those in the use-case B? Allowing some modifications but not others seems no harm if the server could convey modifiable information to the operators so that the operators can distinguish these two use-cases. Ch.2.2) "<system> should also immediately reset to its factory default state." What is this state? It is undefined. I would rather say: <system> should be reloaded or recreated. Factory-reset may or may not remove results of an upgrade. [Qiufang Ma] I will make some editorial changes about this, thanks. Ch.3) "Update <running> with the system configuration change" The auto-update should either be allowed to modify running or not, but this idea of allowing create but not allowing delete is wrong. You may easily have a "must" or "when" statement that checks that something does not exist, in which case the current proposed behavior can lead to invalid configuration. Also, the current behavior does not state whether a "case" in a choice statement can be added? If you add one "case" the other is deleted. So, can I add a "case"? [Qiufang Ma] I think the reason for "allowing create but not allowing delete" is as you mentioned above, additions are OK while delete is not could be incorrect if, the absence of some data node is important for the network node. The system should be very careful to delete configurations in <running> since these configurations are likely to have already been modified or referenced. So we choose to remain the deleted system configurations in <running>, some of which may need to be further coped with by the operators. Regarding the choice statement you mentioned, since only one case should be valid and the creation of a node from one case will implicitly delete all nodes from all other cases, if someone adds one case then the system should delete all other existing nodes defined in other cases, no matter if these nodes are generated by the system or not. Is this what you had in mind? Ch 3.1 ) "If there exists any conflict, the configuration in the <running> should succeed." It is hard to define what is a conflict. E.g. If the user deletes a data node, but it comes back when loading system, how do we know if this is a conflict because the user deleted it or if this is a new node that we can be freely loaded into running/intended./intended. IMHO one more reason why system-data must not be modified in running/intended; then we don't have this conflict. [Qiufang Ma] Here by conflict, I mean when both <intended> and <system> are merged into <operational>, the same system configuration data item may have different values(e.g., if the operators modified that system configuration in <running>). Then the configurations in the <running>(and further present in <intended>) should be treated as first priority. CH.3.2) Allowing a delete and then automatically reloading it is a very bad idea. It is misleading for the user that a data node is in place after a successful delete. Also, after delete, it is reloaded; so, between a successful delete and the reloading there is a short interval where the data node is not present? Dangerous. [Qiufang Ma] I think allowing a delete and then automatically reloading should be treated as a way to wipe the client configurations which is imposed on the system configurations. Why don't we have a auto-reload after merge? Either allow Netconf/CLI/Restconf to modify such system data or not. A mixed approach is not acceptable. [Qiufang Ma] I think it could be an alternative to have an auto-reload after merge. But not allowing NETCONF/CLI/RESTCONF to modify such system configurations in <running> seems unreasonable. Ch 5.3.2) So if I have a model Container aaa { Presence aaa; Leaf bbb {} } Where bbb is system data, but aaa is not then the following 2 operations might lead to different results ? IMHO that is not acceptable: - Delete bbb - Replace aaa with an empty aaa container [Qiufang Ma] In auto-populate handling mode, delete operation for a system configuration(bbb) which is loaded from <system> into <running> should succeed. But the deleted data item should be reloaded into <running> immediately if it is still present in the <system>; The logic is that if the system detects that some system configuration data item is not present in <running> it should perform the auto-copy operation. So I think replace aaa with an empty aaa container should also lead to the same result. Best Regards, Qiufang Ma Regards Balazs P.S. I am partly new to the topic, so sorry if I repeat some questions. -- Balazs Lengyel Senior Specialist Ericsson Hungary Ltd. Mobile: +36-70-330-7909 email: balazs.leng...@ericsson.com<mailto:balazs.leng...@ericsson.com>
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
