Operating System: All
Platform: All

This is follow up issue of https://bugs.opendaylight.org/show_bug.cgi?id=7868

RFC 8040 defines the set of operations which we need to provide on the northbound. This notably includes more operations and the ietf-yang-patch model, which we should support in binding.

While most functionality can be provided by RESTCONF using emulation, which works reasonably well in local node scenarios, it is very clunky and error-prone.

In clustered scenarios the emulation layer needs to perform multiple operations, typicaly exists(), followed by puts(), which is inefficient as it:

• adds 'read' aspect to otherwise write-only transactions
• incurs multiple messages

Hence providing native support to these operations will provide significant performance benefits.

ietf-yang-patch defines effectively a DSL for expressing data store transformations, hence the set of operations we can provide to the end user (via DOM and Binding APIs) will vastly expand.

This is gaining criticality, as users are increasing using user-ordered lists, which require insert/point support as hinted in NETCONF WG RFCs.

The write side of APIs need to realigned with RFC 8072, which defines the following operations:

RFC ReadWriteTransaction equivalent
=== ===============================
CREATE exists() + put()
DELETE exists() + delete()
INSERT read() + put()
MERGE merge()
MOVE read() + put()
REPLACE put()
REMOVE delete()

Furthermore https://tools.ietf.org/html/rfc8040#section-4.5 requires REPLACE operation to indicate whether a new item was created or a previous one was replaced. This use case can be supported via invoking an exists() operation before the modification, recording its (future) result – and relying on transaction isolation/reconciliation to throw OptimisticLockFailedException.

The read side of APIs really just need to support depth/fields requests. Since this data access pattern would result in partial subtrees being reported, I think we can forgo that optimization for now and perform filtering in the NETCONF/RESTCONF components.

https://tools.ietf.org/html/rfc6241#section-6 additionally specifies subtree filtering capabilities, which are probably best served via (an optional) XPath evaluation engine.

Robert, for now I'm assigning this to you.

Please decide if it should be moved to someone else.

This one is on the backlog – we don't assign issues until someone actively is going to work on them.

We certainly want to use RFC8072 yang-data objects for modeling binding-api requests.

At DOM we probably want to go dual mode: based on NormalizedNode and API-driven, with a friendly Java API. If that is the case, one of those should be just a default method overlay in interfaces.