Interpreting RESTCONF and NETCONF Output

Mental model

Cisco objective 5.10 says “Interpret the results of a RESTCONF or NETCONF query”. The exam shows you a response; you say what each piece means.

Both RESTCONF (JSON) and NETCONF (XML) carry YANG-shaped data: a container holds a list of entries; each entry has leaves (named values). Once you spot the module + container + list, the leaves are self-describing.

RESTCONF response — walk-through

GET /restconf/data/ietf-interfaces:interfaces
Accept: application/yang-data+json

Response:

{
  "ietf-interfaces:interfaces": {
    "interface": [
      {
        "name": "GigabitEthernet0/0",
        "description": "WAN uplink",
        "type": "iana-if-type:ethernetCsmacd",
        "enabled": true,
        "ietf-ip:ipv4": {
          "address": [
            { "ip": "10.0.0.1", "netmask": "255.255.255.0" }
          ]
        }
      },
      {
        "name": "GigabitEthernet0/1",
        "description": "LAN",
        "type": "iana-if-type:ethernetCsmacd",
        "enabled": false
      }
    ]
  }
}

Interpretation:

• Top-level key ietf-interfaces:interfaces → module ietf-interfaces, container interfaces.
• interface → a list; each entry is one interface.
• name → the key of the list.
• description, type, enabled → leaves of the interface entry.
• ietf-ip:ipv4 → nested container from a DIFFERENT module (ietf-ip). It is nested here because ietf-ip augments the interface entry to add IPv4 fields.
• address → a list inside ipv4, keyed by ip. Here one address: 10.0.0.1/24.

Natural-language summary: “Two interfaces. Gi0/0 is up, labelled WAN uplink, 10.0.0.1/24. Gi0/1 is down, labelled LAN.”

NETCONF response — same data, XML

<rpc-reply>
  <data>
    <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
      <interface>
        <name>GigabitEthernet0/0</name>
        <description>WAN uplink</description>
        <type xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">ianaift:ethernetCsmacd</type>
        <enabled>true</enabled>
      </interface>
      <interface>
        <name>GigabitEthernet0/1</name>
        <description>LAN</description>
        <enabled>false</enabled>
      </interface>
    </interfaces>
  </data>
</rpc-reply>

Same tree. The xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces" on <interfaces> is the XML way of saying “this is the ietf-interfaces module”. Everything else maps 1:1 to the JSON above.

Operational state vs config

Two parallel trees in RESTCONF:

• /restconf/data/ietf-interfaces:interfaces → configuration (what you asked for).
• /restconf/data/ietf-interfaces:interfaces-state → operational state (what the device sees, e.g. oper-status).

Example operational response:

{
  "ietf-interfaces:interfaces-state": {
    "interface": [
      {
        "name": "GigabitEthernet0/0",
        "type": "iana-if-type:ethernetCsmacd",
        "oper-status": "up",
        "statistics": {
          "in-octets": "12345678",
          "out-octets": "9876543",
          "in-errors": "0"
        }
      }
    ]
  }
}

Interpretation:

• oper-status: "up" — interface is UP in operational reality (regardless of config enabled).
• statistics — counters.
• in-octets, out-octets as strings of numbers (YANG uint64 is encoded as a string in JSON to preserve precision).

Finding specific fields fast

• Which interface? The name of the list entry.
• Is it configured up? enabled (config tree).
• Is it actually up? oper-status (state tree).
• What IP? ietf-ip:ipv4/address[0]/ip.
• MTU? ietf-ip:ipv4/mtu or /mtu depending on model.
• Traffic counters? statistics/in-octets, /out-octets.

Common gotchas on the exam

• Mixing config vs state trees — the exam often puts both in one JSON for confusion.
• JSON numbers vs strings — uint64 fields are strings. enabled is a boolean.
• Namespace prefixes — iana-if-type:ethernetCsmacd means “the ethernetCsmacd identity from the iana-if-type module”. You do not need to parse it, just recognise what it names.
• An interface present in config may be absent from state (not yet instantiated).

FAQ

Why is in-octets a string? JSON numbers top out at 2^53. YANG uint64 can exceed that. Encoding as a string keeps precision.

What is ietf-ip: doing nested inside ietf-interfaces? Augmentation. The ietf-ip module augments ietf-interfaces to add IPv4 and IPv6 fields. From the client’s view it is one tree; under the hood it is two modules merged.

Why does the JSON use colons like ietf-interfaces:interfaces but Python dict access is data["ietf-interfaces:interfaces"]? The colon is part of the key name. Pass it as-is to dict indexing.

What is -netconf namespace stuff in NETCONF? NETCONF envelopes (<rpc-reply>, <data>) carry the YANG tree. Namespaces (xmlns=...) identify which module each element belongs to. Different from HTTP headers; think of them as XML’s version of RESTCONF’s module-prefix in the JSON key.