In general, there has been strong feedback from the Advisory Group and other sources that our YANG parser and YANG-modeled data verification are among the strictest available. This has some positive qualities of allowing for very strong assumptions about our data and YANG models, although it's unclear how often we use that.

However, this strictness has caused problems--especially when it comes to mounting NETCONF devices which tend to have both more issues with their YANG file sand strictness of interpretation of data, but are also hard to update as it typically requires firmware updates at the scale of months and require significant testing to ensure the firmware updates don't introduce regressions in other behavior.

These issues and possible solutions were discussed at length in a session at the Boron design forum here:
https://www.youtube.com/watch?v=fe9ec9r2O7c

And significant efforts were made to improve things in Boron, which have been documented in this demo video here:
https://www.youtube.com/watch?v=-MUneHaTCh0

However, there is still a long way to go to get things to be where we'd really like. It is often the case that you can make operations on devices using netopeer that OpenDaylight won't allow us to make.

Further, the general trend has been for us to make our YANG tools more strict, not less so. Until we can make that configurable at some granularity and understand the assumptions we are making about how yangtools operates in order to provide it now and in the future, this seems like an actively harmful direction to continue.

Thus, I'm raising this bug to track this issue as requested here:
https://lists.opendaylight.org/pipermail/release/2016-November/008768.html