I85PREP
⌘ K
JCPA study materials
JCPA study resources

YANG Model Mismatch Breaks RESTCONF GET for Interfaces

JCPA · Put your knowledge to work in context.

All case studies

YANG Model Mismatch Breaks RESTCONF GET for Interfaces

An engineer writes a Python tool that calls GET https://router.example.com/restconf/data/ietf-interfaces:interfaces against a Junos device running a recent Junos release. The tool expects JSON and parses response.json()['ietf-interfaces:interfaces']['interface']. On one device the call returns HTTP 200 but the JSON key is different; on another device the call returns HTTP 406 with Accept set to application/yang-data+json. The team's Ansible playbook uses junos_command with show interfaces and works everywhere. The engineer has a YANG file [email protected] and a pyang -f tree output. The deadline is Friday.

1. Explain the 406 and the differing JSON key, and what the engineer should verify before changing code.

Read the worked answer

406 Not Acceptable means the server cannot produce a representation matching the Accept header. RESTCONF media types are versioned: application/yang-data+json is the modern type; older implementations expect application/yang.data+json (dot, not dash) or may not support JSON at all and require XML (application/yang-data+xml). The fix is to negotiate: send Accept: application/yang-data+json, application/yang.data+json;q=0.9, application/yang-data+xml;q=0.8 or detect and adapt.

Differing JSON key: the top-level key in a RESTCONF JSON body is the module name prefix as the server emits it. If the server emits ietf-interfaces:interfaces vs a different prefix, or if the module revision differs such that the node is namespaced differently, the key changes. The engineer should:

  1. GET the /restconf/data/ietf-interfaces:interfaces with Accept: */* or XML and inspect the actual envelope.
  2. Confirm the device's supported YANG modules (pyang tree of the device's model, not the local file) - the local 2018-02-20 revision may not match.
  3. Check whether the device supports the ietf-interfaces model natively or only via a mapping layer.

Do not hardcode the key; parse the envelope defensively (e.g., find the key ending in :interfaces).

2. The engineer proposes switching everything to `junos_command` to meet Friday. Evaluate that trade-off.

Read the worked answer

junos_command works because it runs CLI and scrapes text - it sidesteps the YANG/RESTCONF model entirely. For Friday, it is a legitimate stopgap for read-only interface status, but it is a poor long-term choice:

  • Brittle: text output formats change across Junos versions; parsers break silently.
  • No schema validation: you lose the contract that YANG provides.
  • Inconsistent with the RESTCONF tool's purpose: the whole point of the JSON tool is structured, model-driven data.

Recommendation: ship the junos_command fallback behind a feature flag for the deadline, but keep the RESTCONF path in development with a media-type negotiation helper and a device-capability probe. Document the debt and a follow-up ticket. The judgement call is: unblock the deadline without pretending the workaround is the architecture.

3. How should the tool discover which media types and models a device supports at runtime?

Read the worked answer

Use the RESTCONF discovery endpoints:

  • GET /.well-known/host-meta → returns the RESTCONF root (often /restconf).
  • GET /restconf/data/ietf-yang-library:modules-state (or yang-library) → lists supported modules and revisions.
  • OPTIONS on a resource can reveal allowed methods; GET with Accept: */* reveals the server's preferred representation.

The tool should cache this per device (it rarely changes) and choose media type and model revision accordingly. If the device does not expose ietf-yang-library, fall back to XML and a conservative parser. This turns a hardcoded assumption into a negotiated contract - the difference between code that survives a Junos upgrade and code that breaks on one.