Operating System: All
Platform: All

TypeUtils.getTypeFromEffectiveStatement() was edited in Change 28478.
Was that Change a cause (or possibly a fix) of this Bug?

Please talk to the device vendor to fix their models, as type statement is absolutely critical to correct interpretation of the data. It is also critical that invalid models get fixed, otherwise we will end up in interoperability hell, as different systems will end up fixing flawed models in different ways, thus leading to incompatible behavior.

In the meantime, you can deploy a fixed-up version of the model in the NETCONF cache, so it will not get pulled from the device.

Downgrading priority to normal, since this is not blocking an ODL project as far as I can tell.

Eventually the vendor will fix the issue, and then eventually all customers will upgrade all devices to make this all go away ... but that timeline is beyond our control.

This is blocking the use of the controller to mount network devices which are being mounted by Helium & Lithium based controllers.

> This is blocking the use of the controller to mount network devices
> which are being mounted by Helium & Lithium based controllers.

Statement is not correct, this is only blocking specific vendor and only in case broken model is downloaded from device.

> In the meantime, you can deploy a fixed-up version of the model in
> the NETCONF cache, so it will not get pulled from the device.

Work-around for such devices (without introducing validation regression in parser)
is to load modified models in cache/schema folder of OpenDaylight controller,
which is used to provide models without downloading them from device.

If such "exception" for non-strictness should be part of parser, not enforcing
correct behaviour will allow for additional models like the one you mentioned to be created.

Cleaner way will be introduction of STRICT and COMPATIBILITY modes into parser, where
one will be used during compile time and other in runtime, but introducing such APIs and rule-sets (and chosing which part of YANG do not enforce in COMPATIBILITY mode) will require lot of work and redesign of some of API contracts.

Also behaviour of COMPATIBILITY fixes is left out to dispuse - how parser should render effective model from which NETCONF, RESTCONF, MD-SAL derives it's behaviour and are this choices really right?
Eg. in your use-case it may falling back to string be right choice, but what if other system with same issue was implemented to expect is as type empty or type identityref?

Robert's idea allows for users, integrators and vendors to provide fixed models and to sideload them to OpenDaylight without modifying actual device and to specify such behaviour on per-model basis, instead of creating "default" rule for specific types of not honoring YANG.

As discussed on the MD-SAL meeting, the problem here is that a single model which fails to parse renders the entire mount point unusable. This problem can be solved acceptably by excluding the model from the resulting schema context, which is something the NETCONF SB plugin can do based on its configuration (either global or for that particular element).

The other issue raised is the fact the mount point access from RESTCONF NB to NETCONF SB forces data validation, which breaks with devices which do not enforce their own models (like allowing an out-of-range value to be configured) – leading to get-config failing. This is needed for the ability to project the data on the NB in both JSON and XML, but could potentially be addressed by re-architecting the RESTCONF/NETCONF interactions.

An idea of 'sloppy' mount points was discussed, which requires some level of design and changes to the MD-SAL APIs to expose how sloppy the mount point is being, so its interactions with the rest of the system can be properly guarded – for example blocking MD-SAL applications from seeing non-conformant data, so they do not break on it.

Since the two immediate problems can (and should) be addressed within the NETCONF project, I am moving this issue there.