An <edit-config> operation is supported with the <running> datastore only. The following <edit-config> operation attribute values are supported:
merge
remove
delete
A ‟delete” operation for a leaf or a presence container does not return an error if the item is already deleted.
An error is returned if attempting to delete a list node that does not exist.
A ‟delete” operation for a container without presence returns an error
create
A ‟create” operation for a leaf or a presence container does not return an error if the item is being set to the same value.
An error is returned if attempting to create a list node that already exists.
A ‟create” operation for a container without presence results in an "OK" response (no error) but is silently ignored.
The ‟replace” operation is not supported as an attribute value for the <edit-config> operation.
Both ‟delete” and ‟remove” operations have the following behavior:
Delete or remove operations are not supported for boolean leaves. For example, any of the following samples return an error:
<shutdown operation="delete"/>
<shutdown operation="delete">false</shutdown>
<interface operation="delete">
<interface-name>abc</interface-name>
<shutdown>true</shutdown>
</interface>
For this last case <shutdown operation="merge">true</shutdown> can be used instead to make the request valid:
A <delete> or <remove> operation is the equivalent of the no command in CLI. This no command is applied whether the default for the command is enabled, disabled (no), or a specific value. The delete operation is not aware of the default value of the object/leaf being deleted.
A <delete> or <remove> operation for a leaf, where the request also specifies a value for the leaf, results in an error.
The <edit-config> <default-operation> parameter is supported merge and none values. The ‟replace” value is not supported. An operation of "none" on a leaf node (inherited or direct) causes that leaf statement to be ignored. No error is returned if the leaf does not exist in the data model.
For merge and create operations, the operations and tags specified in an <edit-config> request are order-aware and order-dependent, and the sequence of operations must follow the required sequence of the equivalent CLI commands. The <edit-config> is processed and executed in a top-down order. The same leaf can be enabled, disabled, or enabled and then disabled, and the final result is whatever was last specified for that leaf in the <edit-config> request.
For <delete> and <remove> operations, the SR OS NETCONF server recursively unwinds any children of the node being deleted or removed first before removing the node itself. The deepest child branch of the request is examined first and any leaves are processed, after which the server works backwards out of the deepest branches back up to the object where the delete operation was specified. If children branches of an object must be removed before deleting the object in CLI, the equivalent delete request in a NETCONF <edit-config> must contain all those children if they exist, such as if the children are configured in the config datastore).
In the following example, SR OS shuts down the test interface, deletes the interface, shuts down the VPLS, and removes it.
<config>
<configure>
<service>
<vpls operation="delete">
<service-id>11</service-id>
<interface>
<ip-int-name>test</ip-int-name>
<shutdown operation="merge">true</shutdown>
</interface>
<shutdown operation="merge">true</shutdown>
</vpls>
</service>
</configure>
</config>
In the preceding example, if other children of vpls 11 exist in the config besides the interface test specified in the delete request, and it is required to delete those children in CLI before vpls 11 is removed, the deletion request fails. All configured children must be specified in the delete request.