skip to content

A RESTCONF event-stream collector reconnects after a ten-minute outage; how do filter, start-time and stop-time recover only the missed interface events?

level: seniorimportance: nice to knowfreq 5%

answer

  1. a GET on the stream's location URL
  2. XPath, evaluated per notification
  3. replay needs replay-support on that stream
  4. no stop-time means stay live

basics

~20 s

On reconnect, the RESTCONF collector sets start-time to its last received eventTime and omits stop-time, so missed notifications replay and live delivery follows. filter, an XPath 1.0 expression, keeps only interface events. Replay needs replay-support on that stream.

solid answer

~40 s

A RESTCONF event stream is a `GET` with `Accept: text/event-stream` on the URL found in the stream's `location` leaf under `restconf-state/streams`. On that GET, `filter` takes an XPath 1.0 expression, with module names as prefixes, evaluated against each notification; only those that evaluate true are delivered. `start-time` triggers RFC 5277 replay from the server's log, so the collector sets it to the last `eventTime` it stored and de-duplicates the overlap. It omits `stop-time`, so after replay the stream simply stays live; `stop-time` is only for bounded backfills and must be later than `start-time`. Replay is per stream: if that stream's `replay-support` is not true, `start-time` draws `400 Bad Request`. A start earlier than the log's oldest record silently starts at the oldest one, so compare it with `replay-log-creation-time` to detect a real gap.

go deeper

for a junior

Recall that RESTCONF can stream notifications over a long-lived GET and that a client can ask for past events as well as live ones.

for a middle

Explain filter as XPath per notification, start-time as replay from the log, and stop-time as an optional upper bound that requires start-time.

for a senior

Design reconnect logic: resume from the last eventTime with no stop-time, de-duplicate the boundary, check replay-support per stream and record gaps against the log's creation time.

for a principal

Decide whether device-side replay is good enough for the events that matter, or whether loss-sensitive events need a collector that can never fall behind the log.

## How RESTCONF delivers events RESTCONF (RFC 8040 §6) delivers YANG-defined notifications over an ordinary HTTP connection using **Server-Sent Events**: 1. The client reads `ietf-restconf-monitoring:restconf-state/streams`, which lists each `stream` with its `name`, `replay-support`, `replay-log-creation-time` and one `access` entry per encoding carrying a `location` URL. 2. It sends `GET` to that URL with `Accept: text/event-stream`. 3. The server keeps the response open and writes each notification as an event, with its `eventTime` and payload. Three retrieval parameters belong to this GET and to no other resource: **`filter`**, **`start-time`** and **`stop-time`**. ## filter — choose which events The **`filter`** parameter (§4.8.4) is an **XPath 1.0 expression**, applied as described in RFC 5277 §3.6. The context node is the root of the conceptual notification document, and every supported YANG module name works as a namespace prefix. If the expression evaluates to true for a notification, it is delivered; otherwise it is dropped. Two consequences matter in practice: - a filter that tests a field the notification does not carry evaluates false, so the event is **filtered out** (RFC 5277 §3.6) — a typo silently hides events instead of raising an error; - RESTCONF's `filter` is XPath only, while NETCONF's own subscription operation also accepts subtree filters; a subtree filter cannot be carried across unchanged. The parameter is optional; a server that supports it lists `urn:ietf:params:restconf:capability:filter:1.0`. Filter is allowed only on a GET of an event stream resource and draws `400 Bad Request` elsewhere. ## start-time and stop-time — replay **`start-time`** (§4.8.7) asks for RFC 5277 **replay**: the server first sends logged notifications from that time onwards. **`stop-time`** (§4.8.8) bounds the replay at the newest notification of interest. | Rule | Source | |---|---| | `start-time` on a stream whose `replay-support` is not true gets `400 Bad Request` | §4.8.7 | | a `start-time` later than the current time is not valid | §4.8.7 | | a `start-time` older than the log starts the replay at the earliest available notification | §4.8.7 | | `stop-time` must be used with, and be later than, `start-time` | §4.8.8 | | without `stop-time`, notifications continue until the subscription ends | §4.8.8 | | replay support is advertised as `urn:ietf:params:restconf:capability:replay:1.0` | §9.1.1 | Both values are of the YANG `date-and-time` type from `ietf-yang-types` (RFC 8040 cites RFC 6991; RFC 9911 now obsoletes it). The client can read the server's current time from the HTTP `Date` header to avoid asking for a future start. ## The reconnect, step by step ```http GET /streams/NETCONF?filter=%2Fexample-if-events%3Alink-down&start-time=2026-09-30T14%3A02%3A00Z HTTP/1.1 Host: core1.example.net Accept: text/event-stream Cache-Control: no-cache ``` (`example-if-events` is a documentation module with a `link-down` notification; the filter is `/example-if-events:link-down`.) 1. The collector stored `eventTime` 2026-09-30T14:02:00Z as its last notification before the outage. 2. It reconnects with that `start-time`, the same `filter`, and **no `stop-time`**. 3. The server replays logged link-down notifications from 14:02 onwards, then keeps the connection open and sends live ones. 4. The collector discards anything it already holds with the same `eventTime` and payload, since the notification at the boundary may be sent again. If the collector had sent a `stop-time` too, the stream would end after the replayed window, and it would need a second subscription to return to live events — a needless gap. ## Encoding the parameters - Query values are percent-encoded: the `/` and `:` of an XPath and the colons of a timestamp all appear encoded in RFC 8040's own examples (Appendix B.3.6 to B.3.8). - Each parameter may appear only once, and names and values are case sensitive; a repeat draws `400 Bad Request`. - `filter`, `start-time` and `stop-time` are optional features: check `urn:ietf:params:restconf:capability:filter:1.0` and `urn:ietf:params:restconf:capability:replay:1.0` once per device, then `replay-support` per stream. ## Detecting what replay cannot give back - A replay log is finite. If the requested `start-time` is older than the log, the server **does not fail**: it starts from the earliest notification it still holds. Compare `start-time` with `replay-log-creation-time` and record the difference as a known gap. - Some streams have no replay. RFC 8040's own example shows one stream with `replay-support` true and another with false; check per stream, not per server. - A filter that is too narrow hides events in replay exactly as it does live; validate it against a known notification first. ## Summary `filter` decides *which* events (XPath, true means delivered); `start-time` decides *from when* (replay, per stream, clipped to the log); `stop-time` decides *until when*, and leaving it out is what turns a backfill into a continuous feed.

  • Why should a RESTCONF collector compare its start-time with replay-log-creation-time after a long outage?
    A `start-time` older than the replay log does not fail; the replay just begins with the earliest notification the server still holds. Without the comparison the collector cannot tell a quiet period from lost history, so it should record the span before `replay-log-creation-time` as a gap.
  • What happens to a RESTCONF notification that lacks the leaf a filter expression tests?
    It is filtered out. RFC 8040 applies the filter as RFC 5277 §3.6 describes: when the tested data item is not present, the expression cannot match and the notification is not delivered. A filter written against the wrong leaf name therefore hides events silently instead of failing.

saying these in an interview costs you the question

  • RESTCONF's filter parameter takes a subtree filter, like NETCONF.
  • start-time works on any stream once the server supports replay at all.
  • start-time needs stop-time, so replay always ends the stream.
  • A start-time older than the log is rejected with an error.
  • filter can also trim a GET on a data resource under /data.