Supported Operations
All NetConf operations are captured based on the capability. Hence, any operation falling in multiple capabilities are documented separately.
Capability “base:1.0” supports candidate and running configuration store.
|
Capability |
Operation |
User Role |
Supported (Yes/No) |
Comments |
|---|---|---|---|---|
|
:base:1.0 |
<get> |
User, Operator, Engineer, Admin |
Yes |
|
|
:base:1.0 |
<get> with subtree filter |
User, Operator, Engineer, Admin |
Yes |
|
|
:base:1.0 |
<get-config> |
User, Operator, Engineer, Admin |
Yes |
|
|
:base:1.0 |
<get-config> source=<target> |
User, Operator, Engineer, Admin |
Yes |
|
|
:base:1.0 |
<get-config> with subtree filter |
User, Operator, Engineer, Admin |
Yes |
|
|
:base:1.0 |
<edit-config> <target> as parameter |
Operator, Engineer, Admin |
Yes |
Running configuration as target is not supported because writable-running capability is not supported; instead, candidate configuration store is supported. |
|
:base:1.0 |
<edit-config> <config> as parameter |
Operator, Engineer, Admin |
Yes |
|
|
:base:1.0 |
<edit-config>: <default-operation> as merge |
Operator, Engineer, Admin |
Yes |
|
|
:base:1.0 |
<edit-config>: <delete> |
Operator, Engineer, Admin |
Yes |
Supports attribute-level 'delete' operation only with 'merge' as default-operation. For a leaf-level delete operation, a value is not required. If given, it is ignored by the server. For example: <mtu operation="delete"/> << This is enough to delete/unset a leaf. <mtu operation="delete">1560</mtu> << while processing this, the value (1560) is ignored by server.
A "delete" operation at the key-leaf level is not allowed. Instead, use a delete operation at the list level (with key leaf(s) to identify list instance):
|
|
:base:1.0 |
<edit-config>: <remove>
|
Operator, Engineer, Admin |
Yes |
Supports attribute-level 'remove' operation only with 'merge' or ‘replace’.
If data is absent in the running configuration, the system will not generate a “data-missing” error for the user. Instead, it will silently ignore the “data-missing” error and continue with subsequent processing.
For a leaf-level “remove” operation, a value is not required. If given, it is ignored by the server. For example:
<mtu operation=”remove”/> << This is enough to remove a leaf. <mtu operation="remove">1560</mtu> << while processing this, the value (1560) is ignored by server.
A “remove” operation at the key-leaf level is not allowed. Instead, use a remove operation at the list level (with key leaf(s) to identify list instance):
|
|
:base:1.0 |
<edit-config>: <error-option>as stop-on-error |
Operator, Engineer, Admin |
No |
|
|
:base:1.0 |
<edit-config>: <error-option>as continue-on-error |
Operator, Engineer, Admin |
No |
|
|
:base:1.0 |
<get-schema> |
Operator, Engineer, Admin, User |
Yes |
|
|
rollback-on- error:1.0 |
<edit-config>: <error-option>as rollback-on-error |
Operator, Engineer, Admin |
Yes |
By default, this is the behavior. So there is no need to pass this error-option. |
|
:validate: 1.1 |
<edit-config>: <test-option> |
Operator, Engineer, Admin |
No |
By default, configuration entries are validated and stored, hence this operation and its parameters are not handled. External configuration store validation is not supported (i.e URL). |
|
:base:1.0 |
<copy-config>: <target><source> |
Engineer, Admin |
Yes |
<copy-config> is applicable only from running to candidate and running to startup. |
|
:base:1.0 |
<lock>: < target> |
Operator, Engineer, Admin |
Yes |
|
|
:base:1.0 |
<unlock>: < target> |
Operator, Engineer, Admin |
Yes |
|
|
:base:1.0 |
<close-session> close current session |
User, Operator, Engineer,Admin |
Yes |
|
|
:base:1.0 |
<kill-session>: Close other session |
User, Operator, Engineer,Admin |
Yes |
|
|
:base:1.0 |
subtree filtering |
User, Operator, Engineer, Admin |
Yes |
|
|
:Startup:1.0 |
get-config <source=startup> |
User, Operator, Engineer,Admin |
Yes |
|
|
:Startup:1.0 |
copy-config <source=startup> |
Engineer,Admin |
No |
Copy to candidate is not supported, and copy to running is not applicable because candidate configuration store is supported. |
|
:Startup:1.0 |
copy-config <target=startup> |
Engineer, Admin |
Partial |
Running to startup copy is supported; copying from candidate to startup is not supported. |
|
:Startup:1.0 |
lock <startup> |
Engineer, Admin |
Yes |
|
|
:Startup:1.0 |
unlock <startup> |
Engineer, Admin |
Yes |
|
|
:Startup:1.0 |
validate <source=startup> |
Engineer, Admin |
No |
Always configuration entries are validated and stored, but external configuration store validation is not supported. |
|
:Startup:1.0 |
delete-config |
Engineer, Admin |
Yes |
Running and candidate configuration store cannot be deleted. |
|
:url:1.0 |
URL capability |
User, Operator, Engineer, Admin |
Yes |
URL to startup is not supported. |