OcNOS-SP : NetConf User Guide : Supported Operations
Supported Operations
All NetConf operations are captured based on the capability. Hence, any operation falling in multiple capabilities are documented separately.
Note: Capability “base:1.0” supports candidate and running configuration store.
 
Table 10-2: Supported Operations 
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.
 
Note: 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):
 
<list operation="delete">
<key>value</key>
</list>
: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.