To change the candidate configuration on a C-series Controller, a client application encloses the <edit-config> and <target> tag elements and the <candidate/> tag in the <rpc> tag element:
<rpc>
<edit-config>
<target>
<candidate/>
</target>
<!- - EITHER - ->
<config>
<!- - tag elements representing the configuration elements to change - ->
</config>
<!- - OR - ->
<url>
<!- - location specifier for file containing changes - ->
</url>
<default-operation>(merge | none | replace)</default-operation>
</edit-config>
</rpc>
]]>]]>
The other child tag elements in the preceding syntax statement specify additional parameters, and are described in the indicated sections:
The NETCONF server confirms that it incorporated the configuration data by returning the <ok/> tag in the <rpc-reply> tag element:
<rpc-reply xmlns="URN" xmlns:sdx="URL">
<ok/>
</rpc-reply>
]]>]]>
If the NETCONF server cannot incorporate the configuration data, the <rpc-reply> tag element instead encloses an <rpc-error> tag element explaining the reason for the failure.
Regardless of the value provided, the NETCONF server for the SRC software performs a basic syntax check on the configuration data in the <edit-config> tag element. It performs a complete syntactic and semantic validation in response to the <commit> tag element (that is, when the configuration is committed), but not in response to the <edit-config> tag element. For information about the <commit> tag element, see Committing Configurations.
The client application can also include the operation attribute in the opening tag for a configuration element to specify the manner in which to incorporate the element, which can differ from the manner specified by the <default-operation> tag element. See Changing Individual Configuration Elements.