Balazs Lengyel <balazs.leng...@ericsson.com> 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.
I think this is the only correct solution available today. I.e.,
describe the behavior in description text, and/or add an extension
that makes this formal and machnie readable for your tools:
leaf-list supported-compression-algorithm {
config false;
type eri:compression-algorithm;
description
"Lists the compression algorithms supported by this device.";
}
leaf compression-algorithm {
config true;
type eri:compression-algorithm;
description
"Must be one of the values listed in
supported-compression-algorithm.";
eri:restrict-to "../supported-compression-algorithm";
}
But I assume that the list of supported-compression-algorithm can
change with a software upgrade, and if so, how do you handle the case
that the config contains a value that is removed in a software
upgrade?
/martin
>
> 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
> >
>
> --
> Balazs Lengyel Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909 email: balazs.leng...@ericsson.com
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
