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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
