Transit architects compare management transports for model-driven automation on IOS XE. Which contrast correctly distinguishes NETCONF from RESTCONF at a conceptual level?
Select an answer to reveal the explanation.
Short Explanation
Same YANG brain, different accents: NETCONF talks SSH/RPC, RESTCONF talks HTTPS and web verbs. Pick the accent your automation stack already speaks.
Full Explanation
Transit architects comparing management transports for model-driven automation on IOS XE need a conceptual contrast: NETCONF commonly uses SSH with RPC operations, while RESTCONF commonly uses HTTPS with HTTP-style methods on YANG resources. Both are model-driven and YANG-based; the distinction is how clients speak to the device—RPC/XML (typical NETCONF) versus REST resource methods with JSON/XML (typical RESTCONF).
Saying NETCONF only works offline while RESTCONF only works during SPAN sessions fails by concept—both are online management protocols unrelated to SPAN session state. Claiming NETCONF requires Telnet and RESTCONF requires IP SLA responders is false; NETCONF is commonly over SSH, and RESTCONF does not depend on IP SLA. Asserting both protocols replace YANG with proprietary binary MIBs exclusive to CDP is wrong—YANG remains the modeling foundation, and CDP/MIBs are separate discovery/monitoring traditions.
Exam caveat: memorize the transport/operation pairing (NETCONF/SSH/RPC vs RESTCONF/HTTPS/HTTP methods) rather than exotic distractors tying them to SPAN, Telnet, or IP SLA.
Operational check for transit automation: pick the API style your tooling prefers, confirm IOS XE has the corresponding feature enabled with secure transport, run a read of a YANG interface/VLAN resource both ways if available, and standardize on one approach per pipeline to avoid dual-stack drift.