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. 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. 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. 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. 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? 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 dont have this conflict. 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. Why dont 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. 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 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
