You can use YANG data models to read operational state data from a device. The operational data allows you to determine the current state and behavior of a device, similar to IOS show commands.

You can perform NETCONF GET operations to retrieve read-only operational state data from a system. You must enable NETCONF, activate data parsers (where applicable), and then retrieve the data through an appropriate YANG model.

The How to Configure Operational Data section provides information on configuring operational data through a programmable interface and the CLI.

There are two types of operational data parsers; one that is always on, and the other that must be configured to poll operational data at regular intervals. For the first type of operational data parser, no configuration is required. Data is always fetched from the device during a NETCONF GET request. These data parsers do not have a polling-interval, and operational data is updated as soon as a change occurs.

The second type of operational data parsers must be activated either via the CLI or a NETCONF message (For more information, see the How to Enable Operational Data Parser Polling section.). The operational data for these types of parsers is polled at regular polling intervals and this information is retrieved during a NETCONF GET request.

The following table lists the data parsers that must be activated, and the corresponding YANG model where the operational data is stored.

Perform this task to enable operational data parser polling through a programmable interface:

1. After enabling NETCONF-YANG, send an <edit-config> remote procedure call (RPC) using cisco-odm.yang (available in the GitHub Repository) to enable operational data polling. When the polling is enabled, all operational data parsers are activated by default. The default polling-interval of each parser is 120 seconds (120000 milliseconds). The polling interval decides the frequency at which the parser obtains the operational data and updates the corresponding YANG model in the datastore.

2. After operational data polling is enabled, send a <get> RPC to obtain the operational data. Use the parser-to-YANG model mapping to determine which operational YANG model should be used to retrieve the operational data. The following RPC reply fetches access control list (ACL) operational data using Cisco-IOS-XE-acl-oper.yang:

   
        CORRESPONDING RPC REPLY:
   <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
       <data>
           <access-lists xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-acl-oper"> 
               <access-list>
                   <access-control-list-name>TEST</access-control-list-name>
                   <access-list-entries>
                       <access-list-entry>
                           <rule-name>10</rule-name>
                           <access-list-entries-oper-data>
                           <match-counter>100</match-counter>
                       </access-list-entry>
                       <access-list-entry>
                           <rule-name>20</rule-name>
                           <access-list-entries-oper-data>
                           <match-counter>122</match-counter>
                       </access-list-entry>
                   </access-list-entries>
               </access-list>
           </access-lists>
       </data>
   </rpc-reply>
   
   

Note	For more information, see the cisco-odm.yang model in the GitHub repository.