[YANGTOOLS-764] yang-data-api: define the concept of a tainted NormalizedNode

Relates — Sun, 10 Apr 2022 18:35:58 +0000

Since NormalizedNodes are used as the lingua franca for transferring data between components with different use cases, they face two competing requirements:

1) Java Binding and applications deployed in ODL requires all data to be strictly valid

2) NETCONF-to-RESTCONF pass-through cases require dealing with southbound device data which often violates the device model

yang-data-codec-* are geared towards the first use case, not allowing invalid data to be passed into NormalizedNodes – leading to the operator needing to fix up the models to match the data.

The second use case could be taken care of if we had a way of communicating that a NormalizedNode tree is not completely valid – and NETCONF/RESTCONF provide faculties for reporting such problems.

Since NormalizedNodes are a hierarchical structure, we can record the fact that we have omitted a a subtree because it failed to validate, parse or similar in a relatively unexpensive fashion during the parse phase and then during the build phase.

This would require NormalizedNodeBuilders to expose an 'add taint' method, which would take an ConstraintMetaDefinition-type information as to what the taint is. Codecs would add the taint to the bottom-most NormalizedNode under which the problem occurred – for example an omitted leaf and the reason would be tracked in its parent. During the seal operation, the Builders would check if any child node is tainted and propagate a taint flag upwards (by constructing a different implementation of NormalizedNode).

Once the NormalizedNode tree is constructed, we would check it for taint as it enters a subsystem: RESTCONF egress could accept it and decode the warnings/errors associated with it and pass them back to the user. DataTree and Java Bindings would reject any tainted NormalizedNode, throwing an exception.

OpenDaylight JIRA

[YANGTOOLS-764] yang-data-api: define the concept of a tainted NormalizedNode