Summary

  • RFC 5277 allows a replay request to begin at the earliest notification still available when the requested start predates retention. replayComplete can then truthfully close that replay while the older interval remains absent.
  • Completeness is bounded by the retained log, stream definition, client filter and per-session access control. Delivery, clock quality, downstream processing and operational outcome require separate receipts.

The marker closed a smaller set than the report named

A client requested events beginning at time A. The server's replay store now began at time B. RFC 5277 does not require the impossible. When A is too old, replay starts with the earliest available notification. At the end, the server emits replayComplete.

The marker means all replay notifications applicable to the subscription have been sent. It does not mean the system recreated A-to-B, proved that no events occurred there, or established that every relevant system event ever became a notification.

This is a classic scope error. A precise protocol statement is promoted into a historical verdict because its label contains the word “complete.” The repair is not to distrust the marker. It is to keep the set that the marker closes.

RFC 5277 remains a Standards Track foundation, while RFC 8639 updates the subscription model and RFC 8641 expresses the notification management schema in YANG. This article analyses RFC 5277's bounded replay semantics; it does not claim the 2008 framework is the only current notification architecture.

Retention defines the left edge

Replay is optional and depends on a logging service. RFC 5277 deliberately leaves stored quantity and retention controls to implementations. A stream can advertise replay support and expose replayLogCreationTime and replayLogAgedTime.

The name replayLogCreationTime invites another overclaim. The schema says this time may be earlier than the earliest notification currently available. A log object can survive while its oldest contents age out. Log birth is therefore not evidence of uninterrupted history since birth.

A defensible client records requested start, effective earliest event, log creation, aged boundary and a log generation or reset identity. If the effective start is later than requested, the gap is a first-class result. It should survive exports, summaries and incident closure instead of being normalized into a successful replay.

Stream membership is already a projection

An event stream is a set of notifications matching forwarding criteria. The default NETCONF stream contains all NETCONF XML event notifications supported by that server. “Supported notifications” is not synonymous with every state transition inside the managed system.

Other stream sources and stream configuration are outside the RFC's scope. A vendor, operator or configuration can decide which internal events become members of which stream. The central processor can classify one notification into several streams, or none relevant to a particular consumer.

Historical claims therefore need the stream definition and its version. “No notification in the stream” cannot become “no event in the system” unless an independent contract proves that the stream completely represents the event class being asserted.

Filter and authorization create a session-specific history

The client can add a filter when creating a subscription. Matching occurs against generated notification elements. Access control is applied after a notification is generated; if a session lacks permission, that notification is discarded for that session.

Two authorized clients can consequently receive different valid histories from the same source interval. Neither view is necessarily corrupt. Each is a projection of stream membership, filter and authorization at that time.

replayComplete closes the view made available to the session. It cannot certify events the filter excluded or the access-control policy withheld. For audit, preserve the exact filter, authenticated session identity, authorization-policy generation and counts at each visibility boundary. A policy change during an investigation can otherwise make two replays look like contradictory accounts of reality.

Subscription acceptance is not notification receipt

create-subscription returns a positive RPC response when the server accepts the subscription. Later notification elements are one-way messages; RFC 5277 defines no per-notification response. The acceptance receipt proves the server installed a request, not that every later message reached the client or entered its durable store.

Transport closure, session failure, queue overflow, decoder rejection and client persistence remain later boundaries. A server can correctly send its replay and marker while the client loses a segment after receipt by the network stack. End-to-end completeness therefore needs receiver-side sequence or inventory evidence beyond RFC 5277's marker.

The protocol also distinguishes replayComplete from notificationComplete. The first marks the end of the replay portion. The second marks termination of a subscription with a stop time. Neither marker asserts that the underlying system generated every event a business process might need.

The live transition is another join

For a replay subscription without a stop time, the server sends replayComplete, then notifications generated since subscription creation, then new notifications as they naturally arise. This sequence bridges stored history and live delivery.

The marker locates the protocol transition. It does not by itself prove there was no loss between the replay store and live publisher, no duplication across the boundary, or no reordering introduced downstream. A client that needs continuity should preserve a producer epoch, sequence evidence when available, event identifiers and both send and receive times.

eventTime is the time the event source generated the event. It is not server receipt time, network arrival time or proof that the clock was synchronized. Ordering by that field may be useful, but a polished timeline cannot certify clock quality or causality.

Build a bounded replay receipt

For a consequential historical claim, retain:

  • authenticated server and NETCONF session identity;
  • advertised notification capability and stream discovery response;
  • stream name, definition version and replay-support state;
  • requested start and stop times;
  • log creation, aged boundary, reset or generation identity;
  • earliest and latest events actually observed;
  • exact filter and authorization-policy generation;
  • counts before filter, after filter and after access control when available;
  • subscription RPC result and server-side subscription identity;
  • replayComplete and notificationComplete with receive times;
  • the replay-to-live transition and any detectable gaps or duplicates;
  • source eventTime, server send time and client receipt/persistence time;
  • decoder and durable-store acceptance; and
  • the authoritative state or application outcome used to validate the notification claim.

The receipt should say “complete for retained, applicable, authorized events from B through C.” Removing those qualifiers is not simplification. It is a change in meaning.

Sources