Subject: [netmod] Comments on draft-ma-netconf-with-system-02

From: Balázs Lengyel <[email-masked]>
Date: Sat, 31 Jul 2021 16:01:08 +0000

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 don’t 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 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. 
 
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: [email-masked]