Hello,
The problem is not just about identities. It can be a value range.
Sometimes we have a generic module like iana-interface type that list a
lot of identities, and I don't want to have one YAM file per identity,
to allow a fine control. Also sadly it is not possible to have a
deviation removing identities. IMHO would be needed.
I would be more interested in having an extension saying static-data.
This would state that that part of config is set by the system, and can
not be modified by the user. So I could have conditions based on it, but
the user might not modify it.
regards Balazs
On 2016-08-31 12:38, Ladislav Lhotka wrote:
On 31 Aug 2016, at 11:10, Vladimir Vassilev <[email protected]> wrote:
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.
Right, and I have proposed this approach several times in the past. However,
some people prefer that the modules defining identities mirror IANA and similar
registries. In the case of iana-interface-types it also means that
implementations have to deal with obsolete, obscure and experimental interface
types that happen to be in the IANA registry but nobody will ever want to use.
Lada
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
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909 email: [email protected]
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
