<edit-data>
The <edit-data> operation can be used to load all or some configuration data to a specified target configuration database (<ietf-datastores:running/> or <ietf-datastores:candidate/>). The device authorizes the operation in <edit-data>. After the authorization succeeds, the device performs corresponding modification.
The <edit-data> 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-data> 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 <ietf-datastores:running/>.
- In two-phase validation mode, set the database to <ietf-datastores:candidate/>. After editing the database, perform the <commit> operation so that the modification takes effect.
- In trial mode, set the database to <ietf-datastores:candidate/>.
- default-operation: sets a default operation for the <edit-data> operation.
The default-operation parameter is optional. Its values are as follows:
- merge: merges the configuration data in the <config> parameter with that 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.
The following example shows how to change the description of GigabitEthernet interface
0/1/0 in the <ietf-datastores: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="5">
<edit-data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
<datastore>ds:running</datastore>
<config>
<ifm xmlns="urn:huawei:yang:huawei-ifm">
<interfaces>
<interface>
<name>GigabitEthernet0/1/0</name>
<description>huawei</description>
</interface>
</interfaces>
</ifm>
</config>
</edit-data>
</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="5"
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="5">
<edit-data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
<datastore>ds:running</datastore>
<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-data>
</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="5"
nc-ext:flow-id="28">
<ok/>
</rpc-reply>