One significant difference between DataTree and NETCONF WG semantics are delete operations. DataTreeModification has a delete() operation which is significantly different from NETCONF/RESTCONF delete operation.

The NETCONF WG model defines two operations:

• remove, which behaves as DataTreeModification.delete() in that it ensures data is not present irrespective of whether it was present or not
• delete, which requires data to be present for it to succeed, i.e. unlike DataTreeModification.delete() it has a precondition on the data existing

This is a rather sticky situation, as at some point we want delete() do the same thing as NETCONF delete does to keep things organized.

Update DataTreeModification with:

• introduce remove(), which does exectly what delete() does today
• deprecate delete() for removal, pointing to remove() as its replacement
• netconfDelete(), which poses an existence precondition before deletion, enforced on transaction commit (or rebase that detects it early, if applicable)

The first two parts are trivial, the third is not. It requires a new LogicalOperation.DELETE_EXISTING, which has different semantics from LogicalOperation.DELETE: the operation requires that the targeted node has the same version (and, by extension, subtree version) as observed by the underlying DataTreeSnapshot.

The check for existence in DataTreeModification needs to be eager, i.e. fail immediately if the node is node present. Commit-time rebase needs to fail if the node has been removed, i.e. even when it exists but has a different version, i.e. commit validation needs to fail with a ModifiedNodeDoesNotExistException.