Issue 11.2) Standard Capabilities

[Andy Bierman <abierman@cisco.com>]

Need to decide which capabilities are needed and for each one, 
specify how its parameters are specified

11.2.1) #manager capability

NETCONF peer acting in manager role

11.2.2) #agent capability

NETCONF peer acting in agent role

11.2.3) #writable-running capability

<edit-config> and <copy-config> can be applied to the 
<running> configuration 

11.2.4) #candidate capability

Protocol operations can be applied to the <candidate> 
configuration capability

11.2.5) #validate capability

The <validate> operation can be applied to configuration 
databases

11.2.6) #startup capability

Protocol operations can be applied to the <startup> configuration

11.2.7) #management capability

NETCONF management channel operations are supported

11.2.8) #notification capability

NETCONF peer can support a notification channel

Should a capability called #notification be added to indicate that
the agent supports the notification channel, or the manager desires
the notification channel?  It will only be created if both peers
advertise this capability during the <hello> exchange.

11.2.9) #url capability

Configurations can be identified by a (possibly remote) URL target

11.2.10) #user-db capability

User-created configuration databases are supported

11.2.11) #user-file capability

User-created configuration files are supported

11.2.12) #xpath capability

XPath content filtering is supported

11.2.13) #rollback capability

<rollback-on-error> error option is supported on the
<running> configuration for <edit-config> operations

Revert capability is supported for <commit> operations


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>