Difference between 'nc:operation delete' and 'nc:operation remove' in

[Manjunath T]

Hello everyone,

I have been working with NSO XML templates and have come across the 'nc:operation delete' and 'nc:operation remove' attributes. I would like to understand the difference between these two attributes and whether 'nc:operation remove' can be used as a replacement for 'nc:operation delete' in all scenarios. Here are my specific questions:

1. What is the difference between 'nc:operation delete' and 'nc:operation remove' in NSO XML templates? How do they differ in terms of behavior and implications?

2. Are there any specific use cases or scenarios where 'nc:operation remove' should be preferred over 'nc:operation delete'? Conversely, are there any scenarios where 'nc:operation delete' is required and 'nc:operation remove' cannot be used?

3. Can 'nc:operation remove' be considered a suitable replacement for 'nc:operation delete' in all cases? What are the limitations or considerations to keep in mind when deciding between these two attributes?

I would greatly appreciate any insights or experiences you can share regarding the usage and differences between 'nc:operation delete' and 'nc:operation remove'. If you have encountered specific scenarios where one attribute is more appropriate than the other, please share your thoughts.

Additionally, if there are any best practices or guidelines to follow when deciding between 'nc:operation delete' and 'nc:operation remove', I would love to hear about them.

Thank you in advance for your help!

[bigevilbeard]

Its been a while for me with these two. I think the main difference between nc:operation delete and nc:operation remove is that nc:operation delete will remove the entire leaf from the datastore, while nc:operation remove will only remove the value of the leaf. The nc:operation delete is typically used when you want to completely remove a leaf from the datastore. The nc:operation remove is typically used when you want to remove the value of a leaf, but you want to keep the leaf in the datastore.

Happy to be corrected here.

[snovello]

I could not find any evidence for this interpretation in RFC 6241.

Using a delete or remove operation on an element removes all the configuration data associated with the element. In the case of a leaf that means removing the whole leaf. If the leaf is 'mandatory true' that will result in an error when you commit the change.

To go a little deeper:

In fact if a leaf is present,  there are only a few cases where it might be present where it has no value.

• If the type is 'empty', it always has no value.
• If the type is a union of the empty type and another type. This is the case where I could change a leaf keeping it present but removing the value. To make that edit, passing from having a value to not having a value but keeping the leaf present, your edit-config call should contain the leaf with the merge operation specifying the. new value to be empty. i.e. <myleaf/> (operation is omittted since merge is the default).
• If the type is string, the value could be the empty string. Which you can say is having no value or having an empty string value. I mention this case because the edit to set the value to an empty string is again expressed by having the leaf with no value and the default merge operation, just as in the previous case. Note: in XML there is no difference in meaning between '<myleaf></myleaf>' and '<myleaf/>'.  XML parsers will in both cases create a 'myleaf' node with no content.

BTW: The question here is not very NSO related. In NSO, the Netconf NED is deciding the exact nc:operation to use to achieve a minimum diff, so in the NSO template for a service you have the 'tags' attribute which performs a similar function to 'nc:operation', the difference being that in an NSO template you are describing the intended state of the configuration, while in the netconf edit-config messages you are expressing operations to change the config from one state to another.

[ygorelik · Accepted solution]

I think the best description of these two operations is given in the RFC-6241 and corresponding YANG model ietf-netconf.yang:

typedef edit-operation-type {
  type enumeration {
    enum merge {
      description
        "The configuration data identified by the
         element containing this attribute is merged
         with the configuration at the corresponding
         level in the configuration datastore identified
         by the target parameter.";
    }
    enum replace {
      description
        "The configuration data identified by the element
         containing this attribute replaces any related
         configuration in the configuration datastore
         identified by the target parameter.  If no such
         configuration data exists in the configuration
         datastore, it is created.  Unlike a
         <copy-config> operation, which replaces the
         entire target configuration, only the configuration
         actually present in the config parameter is affected.";
    }
    enum create {
      description
        "The configuration data identified by the element
         containing this attribute is added to the
         configuration if and only if the configuration
         data does not already exist in the configuration
         datastore.  If the configuration data exists, an
         <rpc-error> element is returned with an
         <error-tag> value of 'data-exists'.";
    }
    enum delete {
      description
        "The configuration data identified by the element
         containing this attribute is deleted from the
         configuration if and only if the configuration
         data currently exists in the configuration
         datastore.  If the configuration data does not
         exist, an <rpc-error> element is returned with
         an <error-tag> value of 'data-missing'.";
    }
    enum remove {
      description
        "The configuration data identified by the element
         containing this attribute is deleted from the
         configuration if the configuration
         data currently exists in the configuration
         datastore.  If the configuration data does not
         exist, the 'remove' operation is silently ignored
         by the server.";
    }
  }
  default "merge";
  description "NETCONF 'operation' attribute values";
  reference "RFC 6241, Section 7.2";
}

The difference surfaces out when the corresponding object does not exist: the nc:operation="delete" will return you an error, whereas nc:operation="replace" silently ignores it. In this regards the nc:operation="delete" can be safely replaced by nc:operation="remove" in all the cases, unless you want to control the error conditions.

[karumugh]

Is it my understanding correct that a delete operation should be performed for deleting entry/leaf usually performed on the key field. Even if applied for non key field, the entry is deleted. Remove operation is basically remove a non-key field. It will just remove the value of non-key field. Doing remove operation on the key field will the entry as well. Basically it is meant to remove non-key fields.

[snovello]

In the case of a list element, to remove. the element you should apply the delete or remove to the list element itself, not the key field.

Attempting to delete or remove a list key leaf will result in a list element that has no key and should be rejected by the netconf server.

There are examples of removing a list element in RFC 6241, where the operation attribute is placed on the. list element,  and then the key leaf is used to specify which list element should be deleted.

   Delete the configuration for an interface named "Ethernet0/0" from
   the running configuration:

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <default-operation>none</default-operation>
         <config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
           <top xmlns="http://example.com/schema/1.2/config">
             <interface xc:operation="delete">
               <name>Ethernet0/0</name>
             </interface>
           </top>
         </config>
       </edit-config>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

   Delete interface 192.0.2.4 from an OSPF area (other interfaces
   configured in the same area are unaffected):

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <default-operation>none</default-operation>
         <config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
           <top xmlns="http://example.com/schema/1.2/config">
             <protocols>
               <ospf>
                 <area>
                   <name>0.0.0.0</name>
                   <interfaces>
                     <interface xc:operation="delete">
                       <name>192.0.2.4</name>
                     </interface>
                   </interfaces>
                 </area>
               </ospf>
             </protocols>
           </top>
         </config>
       </edit-config>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>