Open lllyfeng opened 1 year ago
Actually, more dynamic feature are needed when modeling device specification:
Not sure about the YANG feature request.
It looks like script variables x and y are used in the type-stmt "range $x .. $y". This is not related to the feature-stmt or if-feature-stmt.
This would be a powerful feature but it introduces a pre-processor. Other use-cases exist like "pattern $p". It could help reduce errors and cut-and-paste. It could also increase complexity and reduce readability.
Further Discuss: complexity: high, bc: high, importance: medium
YANG provide the capability to define data model statically. But it can not meet the requirements of some scenarios: Some nodes are associated with licenses. Different licenses may indicate different features and specifications. If customer buy a new license, it will cause the features and specifications are changed after the license is activated. But YANG files are not changed, so the YANG modules can not match the current situation of server. The definition of models are earlier than implementation. For example ,in POC test, the actually implementations are different with YANG modules, it’s not necessary to add deviations because the POC version is not the official version. The specifications of the same node may be different between multiple products, if the differences are express by deviations, it will add many deviations. We need find a way to solve this issue. Feature/if-feature can do something, but it’s not enough. Solution 1:express the latest specification by YANG library (for example the latest range of leaf node) and generate a notification for changed specifications。 Solution 2:introduce variable, define the specifications of node by variables. And generate a notification for changed variables. Support to query variables. variable x; variable y; type uint32 { range $x..$y; } Solution3:generate deviation modules automatically for every specification changes. Notify client the schema are changed。(not recommended)