If you design your models using identityref and define the identities in
separate modules e.g. compression-zip.yang, compression-gzip.yang, etc.
you can just chose not to load the particular YANG models containing the
identities not supported when your device starts.
If you absolutely can not define your identities in separate YANG files
(better modularity is indeed the edge YANG has over other modeling
languages and it should be used) you can use feature with some
limitations e.g. instead of leaf of type enumeration you will have a
choice with each case containing if-feature and presence container for
example.
If you can not change the model to be modular and your implementation
does not support it 100% then you are not supporting the model and you
are free to be creative with the workaround but then YANG is not the
problem.
I also see alternative discussion value in the subject line. Lets say
one would like to specify in a standard way a list of values supported
by a device as valid /interface/interface/name values e.g. ("ge0",
"ge1", .... "xe0", "xe1", "me0"). This can be useful in many ways e.g.
tab completion. Also the supported types for each of the interface names
and so on further reducing the entropy. Does anyone else see value in that?
On 08/31/2016 09:35 AM, Balazs Lengyel wrote:
Hello Jan,
This may be the best solution we have, but nacm rules may be changed,
and then device limits might be edited by the operator, and then we
have a problem.
The good solution would be to indicate that this is read-only static
data, and allow must, leafref towards it. However I don't see a way to
do this in YANG at the moment short of an ericsson-extension.
regards Balazs
On 2016-08-30 15:14, Jan Lindblad wrote:
Balazs,
We have the following design pattern.
1) An enumeration or a set of identities are defined that define a
set of options generally supported by Ericsson products. (e.g.
supported compression algorithms)
2) The specific node sets in run-time a leaf-list indicating the set
of values that this specific node supports (e.g.
nodes-supported-compression-types: zip, gzip, bz)
3) For some function the user has to select a specific option value
(e.g. leaf file-compression for transferring backup files)
Problem: how do you restrict values for (3) - file-compression so
that it is one of the nodes-supported-compression-types. The natural
solution would be to use a must expression or a leaf-ref, but as
nodes-supported-compression-types is config-false data, it is not
allowed to constrain the config=true leaf, file-compression, with it.
It would be perfectly reasonable because the
nodes-supported-compression-types only change during upgrade, but
YANG does not allow this.
I would still like to have some modeled solution, not just plain
English stating the constraint. Any idea how to do it?
I have seen this use case many times. I usually solve this by making
a container with device specific limits, lists of supported values,
etc, which is config true but with nacm rules preventing everyone
from making changes. Then I have a device specific database
initialization file with the correct settings for this device, which
is loaded into the database at first boot.
/jan
Vladimir
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
