<edit-config>

An <edit-config> operation is supported on the <candidate> datastore. The <edit-config> requests that specify the <running> datastore as a target when using the "urn:nokia.com:sros:ns:yang:sr:conf" namespace (the Nokia SR OS YANG modules) result in an error response.

The <edit-config> requests to the <candidate> datastore only result in XML- formatted content.

An internal "implicit" lock is in place on the <running> datastore; the datastore has a scope of all configuration commands in SR OS (not just the "urn:nokia.com:sros:ns:yang:sr:conf" namespace). The following actions affect the "implicit" lock.

The following scenarios are impacted when the "implicit" lock is in place.

One or more <edit-config> requests can be performed on the <candidate> datastore before the changes are committed or discarded.

The supported <edit-config> operation attribute values are listed in Table: <edit-config> operation attribute values.

Table: <edit-config> operation attribute values
Command Notes

urn:nokia.com:sros:ns:yang:sr:conf namespace

Nokia SR OS YANG modules

merge

(Nokia SR OS modules)

Supported

remove

(Nokia SR OS modules)

A <remove> operation removes the deleted configuration and returns it to the default value.

A <remove> operation automatically removes all child objects of a deleted object (leaves, lists, containers, and so on).

Explicit shutdown of the object being removed (or any child) is not required and results in an error if a merge operation is specified on a tag that inherits a <remove> operation.

A <remove> operation is allowed on non-presence containers. The non-presence container and all of its children are removed (for example, a non-presence container with no child nodes is not displayed in a <get> or <get-config> reply).

A <remove> operation is allowed on an object where all child branches and dependencies are automatically removed (but the <remove> operation fails if any outside objects is linked to the object being removed).

A <remove> operation is allowed on a <shutdown/> leaf (which returns it to its default value).

A <remove> operation is allowed on a non-Boolean leaf.

Upon specifying a <remove> operation on a node where none of its children belong to the urn:nokia.com:sros:ns:yang:sr:conf namespace (the Nokia SR OS YANG modules), SR OS does not return an error and completes the node removal.

A <remove> operation for a leaf, where the request also specifies a value for the leaf, results in an error.

delete

(Nokia SR OS modules)

SR OS returns an error if a <delete> operation is performed on a list that does not specify a key (that is, an attempt to delete all members of a list).

SR OS returns an error if a <delete> operation is performed on a leaf or presence container that is already deleted (or has the default value and the default-handling is trim).

SR OS may return an error and may not complete the deletion operation when a <delete> operation is performed on a node where any of its children do not belong to the urn:nokia.com:sros:ns:yang:sr:conf namespace (the Nokia SR OS YANG modules).

A <delete> operation removes the deleted configuration and returns it to the default value.

A <delete> operation automatically deletes all child objects of a deleted object (leaves, lists, containers, and so on).

Explicit shutdown of the object being deleted (or any of its children) is not required and results in an error if a merge operation is specified on a tag that inherits a <delete> operation.

A <delete> operation is allowed on non-presence containers. The non-presence container and all of its children are deleted (for example, a non-presence container with no child nodes is not displayed in a <get> or <get-config> reply).

A <delete> operation is allowed on an object where all child branches and dependencies are automatically deleted (but the <delete> operation fails if any outside objects is linked to the object being deleted).

A <delete> operation is allowed on a <shutdown/> leaf (which returns it to its default value).

A <delete> operation is allowed on a non-boolean leaf.

Upon specifying a <delete> operation on a node where none of its children belong to the urn:nokia.com:sros:ns:yang:sr:conf namespace (the Nokia SR OS YANG modules), SR OS does not return an error and completes the node deletion.

A <delete> operation for a leaf, where the request also specifies a value for the leaf, results in an error.

create

(Nokia SR OS modules)

When a <create> operation for a leaf or presence container is performed, SR OS returns an error if the leaf or presence container is being set to the same value (unless the default-handling is trim and the value being set is the default value).

replace

(Nokia SR OS modules)

Supported

The <edit-config> operation <default-operation> parameter is supported with the following values:

For <delete> and <remove> operations in the Nokia SR OS namespace, the SR OS NETCONF server will recursively unwind any children of the node being deleted or removed first before removing the node. 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.

The following applies to the urn:nokia.com:sros:ns:yang:sr:conf namespace (the Nokia SR OS YANG modules):

See Application of default operation value for parent and child nodes and Exceptions to the default operation handling for more information.

The following scenarios simplify ‟operation" inheritance, where the first line in each scenario represents the operation value of the parent node and the following lines represent the possible operation values for the child nodes and the SR OS behavior in each case:

The <error-option> is supported. SR OS implements the rollback-on-error behavior at all times, when:

As per RFC 6020, YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF), the ‟insert” and ‟value” attributes are supported with user-ordered leaf-lists to insert or move a user-ordered leaf-list entry in the candidate datastore.

As per RFC 6020, the ‟insert” and ‟key” attributes are supported with user-ordered lists to insert or move a user-ordered list entry in the candidate datastore.

With a NETCONF <edit-config> RPC, SR OS authorizes all configuration changes in the <candidate> datastore; that is, it checks the YANG tree and authorizes every changed managed object (MO).

The deletion of a container results in the deletion of any children containers that are authorized for deletion, as well as their contents. Children containers that are not authorized for deletion, as well as their contents, are retained. For example, upon deletion of configure system, configure system security is not deleted because the deletion of that child container is not authorized.

Note: A ‟no change” for a value does not require authorization. Therefore, it is possible to execute a non-authorized command if there is no change in value.

For example, when a user is not authorized to change access li, but attempts to change it for another a user who already has access li, SR OS allows that action because there is no change in value.

To edit BOF configurations, the ‟bof” <configuration-region> must be specified within the <edit-config> <target>. For example:

<?xml version="1.0" encoding="UTF-8"?> 
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
  <target>
       <configuration-region>bof</configuration-region>
    <candidate/>
  </target>
    <config>
          <bof xmlns="urn:nokia.com:sros:ns:yang:sr:bof-conf">
               <console>
                     <wait-time>5</wait-time>
               </console>
          </bof>
    </config>
</edit-config>  
</rpc>
]]>]]>

To edit LI configurations, the ‟li” <configuration-region> must be specified within the <edit-config> <target>. For example:

<edit-config>
  <target>
    <configuration-region>li</configuration-region>
    <candidate/>
  </target>
  <config>
    <!-- place LI configuration changes here -->
  </config>
</edit-config>

Alternatively, the <target> can be specified in the format of ‟configuration-region”-”datastore”. For example:

<edit-config>
  <target>
    <li-candidate/>
  </target>
  <config>
    <!-- place LI configuration changes here -->
  </config>
</edit-config>

When both the <configuration-region> and the ‟configuration-region”-”datastore” format are used, SR OS applies the last tag used in the XML request. For example:

<edit-config>
<target>
    <configuration-region>configure</configuration-region>
    <li-candidate/>
</target>
<config>
    <!-- place LI configuration changes here -->
</config>
</edit-config>

When a mismatched namespace or <configuration-region> combination is specified, SR OS returns an error.

The <edit-config> RPC can only be used to push LI configuration changes if all of the following conditions are true.

If any of the preceding conditions is false, SR OS returns an error.

See Table: Protocol operations and level of support in Nokia SR OS NETCONF servers for more details.

Configuration annotations may be encoded with the nokia-attr:comment attribute to add, change, or delete the annotations. In the following example, configure system name is annotated with the comment ‟This is a comment on the system name.” in the <edit-config> RPC:

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <edit-config>
    <target><candidate/></target>
    <config>
        <configure xmlns="urn:nokia.com:sros:ns:yang:sr:conf" xmlns:nokia-attr="urn:nokia.com:sros:ns:yang:sr:attributes">
            <system>
                <name nokia-attr:comment="This is a comment on the system name."> node2</name>
            </system>
        </configure>
    </config>
  </edit-config>
</rpc>
]]>]]>

See the following sections for examples of <edit-config> request and response messages:

Parent topic: NETCONF operations and capabilities