Closed fnchooft closed 1 month ago
@robshakir : Hi Rob, appreciate all the work you guys are doing, would be great to get some feedback on this issue from the architects. I have modified some models to fit our needs where config-containers are not conditioned anymore on non-config-elements.
Thanks, Fabian
I am facing the same issue. The third-party YANG datastore I am using complains because the "when" XPATH expression in openconfig-if-ethernet.yang refers to state data in a data node.
We're running into this as well with model validation in the ntc-rosetta project. Is this still in active development?
This is an unfortunate limitation of the YANG language -- there are use cases, for example, where some configuration is only applicable/valid when some other read-only property has a certain value. A canonical example is Ethernet configuration on an interface only being valid when the interface is of type IF_ETHERNET (or another valid type).
As validation tools like pyang have added more complete support for XPATH validation, there are more reports of this, but the original issue with the language is unchanged. You didn't provide any info about the validation you're doing so not sure what tools you're using. In particular, tying these constraints to assumptions about the layout of datastores in NETCONF is problematic.
The workaround at this time is to remove these validation conditions from the models. (we have to go back and check if this arises in cases other than validation). There is an argument that such validation should be done on the server (device) only, but when writing these models, we felt that a priori validation on the client side would be valuable. We can bring it up again in the working group to see if we want to revisit.
Sounds good, thanks for the update!!!
This issue is stale because it has been open 180 days with no activity. If you wish to keep this issue active, please remove the stale label or add a comment, otherwise will be closed in 14 days.
Good Afternoon,
A question which came up recently is the fact that some config-containers are constrained by must-expression where the conditions points from a config-container to a non-config-container. As per:
Thus this construct where config-containers only exist if a state container has a certain condition seems not to be allowed.
A quick grep in the repository shows the following models which are at least affected by this condition:
In the FAQ i could not find any reference to this type of modelling.
Kind regards,
Fabian