[YANGTOOLS-764] yang-data-api: define the concept of a tainted NormalizedNode Created: 22/Mar/17  Updated: 10/Apr/22

Status: Confirmed
Project: yangtools
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature
Reporter: Robert Varga Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Relates
relates to YANGTOOLS-777 yang-data-api: Add support for Anydat... Confirmed
relates to YANGTOOLS-717 Provide support for sloppy/quirks mod... Confirmed

 Description   

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.


Generated at Wed Feb 07 20:54:14 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.