An operations team wants interface oper-status transitions pushed to a collector the moment they happen, while interface counters arrive on a fixed schedule to the same collector. The engineer must describe the subscription precisely enough that the device knows which nodes to stream, when to stream them, and where to send the data. Which subscription parameters should the engineer set for this delivery?
Select an answer to reveal the explanation.
Short Explanation
A telemetry subscription bundles four choices: the xpath names the data, on-change or a sample period sets the rhythm, and the receiver says where it lands. Status changes and counters move at different speeds, so one schedule cannot serve both. Set them side by side and your collector gets prompt changes plus steady counter samples.
Full Explanation
A model-driven telemetry subscription is really four decisions bound together. The xpath is the filter naming exactly which nodes the device should read, and without it the platform has no idea what to stream. The subscription type decides the rhythm: on-change reports a node only when its value changes, which suits oper-status transitions, while a sample period drives periodic reports that keep counters arriving on a fixed schedule. The receiver is the destination address and port where the device pushes encoded data, so both kinds of report must point at the collector. Collapsing everything into one sample period fails the immediacy requirement, because a status change only surfaces at the next interval. Streaming back to the address that opened the subscription fails the delivery requirement, since telemetry is a push to a collector rather than a reply to a requester, and leaving node selection to the device fails the filter requirement entirely. Caveat: not every node supports on-change, so check the model before relying on it. Practical check: capture traffic at the collector and confirm you see both a status change and a periodic counter update.