<edit-config>

The <edit-config> operation loads all or some configurations to a specified target configuration database (<running/> or <candidate/>). The device authorizes the operation in <edit-config>. After the authorization succeeds, the device performs corresponding modification.

The <edit-config> operation supports multiple modes for loading configurations. For example, you can load local and remote files, and edit files online. If a NETCONF server supports the URL capability, the <url> parameter (which identifies a local configuration file) can be used to replace the <config> parameter.

Parameters in an RPC message of the <edit-config> operation are described as follows:

<config>: indicates a group of hierarchical configuration items defined in the data model.
The <config> parameter may contain the optional operation attribute, which is used to specify an operation type for a configuration item. If the operation attribute is not present, the <merge> operation is performed by default. The values of the operation attribute are as follows:
- merge: modifies or creates data in the database. Specifically, if the target data exists, this operation modifies the data. If the target data does not exist, this operation creates the data. This is the default operation.
- create: adds configuration data to the configuration database only if such data does not already exist. If the configuration data already exists, <rpc-error> is returned, in which the <error-tag> value is data-exists.
- delete: deletes a specified configuration data record from the configuration database. If the data exists, it is deleted. If the data does not exist, <rpc-error> is returned, in which the <error-tag> value is data-missing.
- remove: removes a specified configuration data record from the configuration database. If the data exists, it is deleted. If the data does not exist, a success message is returned.
- replace: replaces configuration data records in the configuration database. If the data exists, all relevant data is replaced. If the data does not exist, the data is created. Different from the <copy-config> operation (which completely replaces the configuration data in the target configuration database), this operation affects only the configuration that exists in the <config> parameter.
target: indicates the configuration database to be edited. The configuration database can be set based on the scenario.
- In immediate validation mode, set the database to <running/>.
- In two-phase validation mode, set the database to <candidate/>. After editing the database, perform the <commit> operation to submit the configuration for the modification to take effect.
- In the trial mode, set the database to <candidate/>.
<default-operation>: sets a default operation for the <edit-config> operation.

The default-operation parameter is optional. Its values are as follows:
- merge: merges the configuration data in the <config> parameter with the configuration data in the target configuration database. This is the default operation.
- replace: completely replaces the configuration data in the target configuration database with the configuration data in the <config> parameter.
- none: ensures that the configuration data in <config> does not affect that in the target configuration database, with the exception that the operation specified by the operation attribute is performed. If the <config> parameter contains configuration data that does not exist at the corresponding data level in the target configuration database, <rpc-error> is returned, in which the <error-tag> value is data-missing. This prevents redundant elements from being created when a specified operation is performed. For example, when a specified child element is deleted, <config> contains the parent hierarchical structure of the child element but the target database does not contain the configuration of the parent element. If the value of the default-operation parameter is not none, the configuration of the parent element is created in the database when the child element is deleted. Otherwise, the child element is deleted, and the configuration of the parent element is not created.

<error-option>: sets a processing mode for subsequent instances after a configuration error of an instance occurs. The default value is stop-on-error. The values are as follows:

1. If the target configuration library is <running/>:
- stop-on-error: stops the operation if an error occurs and roll back the configuration according to the rollback-on-error mode.
- continue-on-error: records the error information and continues the execution if an error occurs. The NETCONF server returns an <rpc-reply> message indicating an operation failure to the client after an error occurs.
- rollback-on-error: stops the operation if an error occurs and rolls back the configuration to the state before the <edit-config> operation is performed. This operation is supported only when the device supports the <rollback-on-error> capability.
2. If the target configuration library is <candidate/>, set the value of <error-option> to rollback-on-error for subsequent instances after a configuration error of an instance occurs.

The following example shows how to change the description value of the interface named GigabitEthernet0/0/1 in the <running/> configuration database to huawei.

RPC request

<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="15">
  <edit-config>
    <target>
      <running/>
    </target>
    <config>
      <ifm xmlns="urn:huawei:yang:huawei-ifm">
        <interfaces>
          <interface>
            <name>GigabitEthernet0/0/1</name>
            <description>huawei</description>
          </interface>
        </interfaces>
      </ifm>
    </config>
  </edit-config>
</rpc>

RPC reply

<?xml version="1.0" encoding="utf-8"?>
<rpc-reply xmlns:nc-ext="urn:huawei:yang:huawei-ietf-netconf-ext"
           xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
           message-id="15"
           nc-ext:flow-id="27">
<ok/>
</rpc-reply>

The following example shows how to delete the configuration on the interface named LoopBack1023 from the running configuration database.

RPC request

<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="844">
  <edit-config>
    <target>
      <running/>
    </target>
    <config>
      <ifm xmlns="urn:huawei:yang:huawei-ifm">
        <interfaces>
          <interface xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" nc:operation="delete">
            <name>LoopBack1023</name>
          </interface>
        </interfaces>
      </ifm>
    </config>
  </edit-config>
</rpc>

RPC reply

<?xml version="1.0" encoding="utf-8"?>
<rpc-reply xmlns:nc-ext="urn:huawei:yang:huawei-ietf-netconf-ext"
           xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
           message-id="844"
           nc-ext:flow-id="29">
<ok/>
</rpc-reply>

If the validate capability is supported, the <edit-config> operation can carry the <test-option> parameter. If the <test-option> parameter is not specified, the system processes the <edit-config> operation based on the test-then-set process by default.

If the <test-option> parameter value is test-then-set or the parameter is not specified, nodes at any layer support the <delete> and <remove> operations that delete all configuration data of a specified node in the configuration database.

Example of deleting the vplsInstances configuration.

RPC request

<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="849">
  <edit-config>
    <target>
      <running/>
    </target>
    <config>
      <l2vpn xmlns="urn:huawei:yang:huawei-l2vpn">
        <instances xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" nc:operation="delete"/>
      </l2vpn>
    </config>
  </edit-config>
</rpc>

RPC reply

<?xml version="1.0" encoding="utf-8"?>
<rpc-reply xmlns:nc-ext="urn:huawei:yang:huawei-ietf-netconf-ext"
           xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
           message-id="849"
           nc-ext:flow-id="31">
<ok/>
</rpc-reply>