A 911 PSAP tooling team prefers simple HTTPS/JSON clients for routine reads but needs transactional candidate/running datastore commits for complex multi-leaf changes on IOS XE. Which protocol pairing matches those needs?
Select an answer to reveal the explanation.
Short Explanation
RESTCONF is the easy HTTPS/JSON counter window; NETCONF is the escrow desk that holds a whole candidate config until you commit. Grab the simple reads over RESTCONF, and bring the multi-leaf surgery to NETCONF. SNMP SETs and telemetry streams are not that transaction desk.
Full Explanation
PSAP tooling that prefers simple HTTPS/JSON clients for routine reads but needs transactional candidate/running datastore commits for complex multi-leaf changes should prefer RESTCONF for straightforward HTTPS/JSON operations and NETCONF when full datastore transactions are required. That protocol pairing matches strengths: RESTCONF convenience versus NETCONF transactional rigor on IOS XE.
Using only SNMP SETs for both simple reads and multi-leaf transactions lacks YANG transactional semantics. Using gRPC telemetry subscriptions to write candidate configurations confuses streaming telemetry with configuration transactions. Relying on Guest Shell cron alone because neither NETCONF nor RESTCONF supports YANG is false.
Exam caveat: some edits are safe on RESTCONF; use NETCONF when you need lock/candidate/confirmed-commit behavior for multi-leaf civic changes. Operational check: perform a simple RESTCONF GET/PATCH in lab, then a multi-leaf NETCONF candidate commit with confirm, and document which tool PSAP runbooks use for each class of change. Record the chosen control and rejected alternatives in the municipal change record so future on-call engineers understand the failure modes avoided for city services.