I have a doubt about how default values work when they are defined for data
nodes added in a module revision
Let's consider for example adding the following YANG data node in a module
revision:
leaf foo {
type boolean;
default false;
}
Implementations of the previous revision of the module may have already
supported vendor-specific mechanisms to set the applied configuration for foo
to true
After the implementation is upgraded to support the new module revision, the
following situation can appear:
* No value of foo is present in the running DS
* The value of foo in the operational DS shall be true to reflect the
applied configuration
Would this implementation be a valid/compliant?
>From previous discussion it seems not since it is not properly supporting the
>default statement for the leaf foo:
https://mailarchive.ietf.org/arch/msg/netmod/y6rrP5avzNBh2-TkXkOTdENcmi4/
However, section 5.3.4 of RFC8342 says:
o system: represents configuration provided by the system itself.
Examples of system configuration include applied configuration for
an always-existing loopback interface, or interface configuration
that is auto-created due to the hardware currently present in the
device.
Can we consider in this case that the configuration of the foo leaf is provided
by the system?
If that's not possible, the alternative options could be:
1. Implementations of the previous revision should declare, via a deviation
statement, that the default value of the leaf foo is removed when they are
upgraded to implement the revised module
2. No default value should be defined for the leaf foo in the revised module
Italo
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]
