Send RPC and Action commands (NETCONF)
=========================================================================
NETCONF defines several standard RPC commands such as
get, get-config and edit-config.  The protocol also allows defining new RPC
commands in any IETF or vendor defined YANG modules. 

Send NETCONF standard get, get-config and edit-config RPC commands
-------------------------------------------------------------------

    We have covered how to send NETCONF's built-in <get>, <get-config>, and <edit-config> etc.
    See :ref:`edit_config_rpc` or  :ref:`retrieval_config_rpc`.

Send RPCs and Actions in any YANG modules
---------------------------------

    There can be many RPC and Action commands defined in either standard or proprietary YANG modules. 

    That is, you want to send RPCs that are not NETCONF built-in commands like <get>, <get-config>, <edit-config>....

    It is pretty easy in NETCONFc to send these commands.

    You just need to expand the module tree to locate the RPC command, click the ``Value`` cells to enter values for 
    input parameters (if there is any) required, and right click to choose sending the RPC command! 

    If the input parameters include list or leaf-list, you can also build a single RPC with multiple list or leaf-list
    entries, just like building an <edit-config>. See :ref:`edit_config_rpc_multiple_list_leaflist` .
    
	.. image:: images/add_to_built_rpcs.*

    The following example sends a **system-restart** RPC defined in ietf-system@2014-08-16 module.

    .. image:: images/send_a_rpc.*
    
    
        
How to specify input parameter value with a namespace?
------------------------------------------------------------------------

    Let's look at the <get-schema> RPC defined in RFC6022 ietf-netconf-monitoring module.
    This RPC defines three input parameters. The optional third ``format`` parameter 
    is an ``identityref`` type. The value should be identities such as ``yang``, ``yin``, etc.
    as defined in the namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring".

    The way you specify such an identityref value is to use ``module-name:identity`` form or
    ``prefix:identity`` form. If you use ``module-name:identity``NECONFc will automatically
    convert it to an appropriate prefix encoding.
    
    
    In an older NETCONFc release, you may have to use ``prefix:identity`` form. If you are 
    required to use ``prefix:identity`` form then how do we know what prefix to use? 

    In NETCONFc, you can view all known prefix/namespace mappings by right-clicking on a node,
    and select "View prefix-namespace mapping"

    .. image:: images/get_schema_namespace.*

    In the dialog popped up, find the prefix that is mapped to the namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring"
    and use the to specify ``format`` value.

    .. image:: images/prefix-namespace-mapping.*


    In this case the value for yang format must be given as **ncm:yang** as shown below:

    .. image:: images/send_get_schema.*    


Kill session
-------------
    You need to kill a session that may be unexpectely holding the datastore lock.

    To invoke NETCONF kill-session RPC, click the ``kill-session`` toolbar button.
    
    .. image:: images/kill_session.*    
    
    You need to enter the session ID you want to kill.
    One way to find the sesion ID is by looking at netconf-monitoring module as shown below:
    
    .. image:: images/find_session_id.*    
    
Validate config
----------------------
    
   If ``Validate`` capability is advertised, the device supports the <validate>
   protocol operation and checks at least for syntax errors for the config data supplied.
   
    To invoke NETCONF <validate> opertion, click the ``validate config`` toolbar button.
    
    .. image:: images/validate_config.*    
    
copy-config,  backup and restore 
-----------------------------------
    To invoke NETCONF copy-config opertion, click the ``copy-config`` button.
    
    .. image:: images/copy_config.*    
    
    The running config can be saved into a file as a checkpoint before updating it.
    If updating fails, it can be restored by reloading the checkpoint file.

    The checkpoint file can be created by using a file url as the target. Example:

    ``Target:  file://localhost/checkpoint.conf``, or if host name is omitted, 
    
    ``Target:  file:///checkpoint.conf``, (note it has three '/' here!)

    To restore the checkpoint file, reverse the <source> and <target>  parameters

    A with-defaults option can also be selected. However the <copy-config> operation 
    is only affected by the <with-defaults> parameter
    if the target of the operation is specified with the <url> parameter.
