Summary

  • AFRINIC's RRDP notification captured on 14 September 2026 listed 32 consecutive deltas, from serial 96961 to 96992, under one session identifier.
  • Public Last-Modified metadata for the first and last retained deltas spanned 425 minutes, but that observation is not a promised seven-hour recovery allowance.
  • RFC 8182 permits incremental recovery only when every missing serial is available; otherwise the relying party processes the current snapshot.
  • AFRINIC should pair the visible serial chain with a compact continuity receipt covering time, bytes, session resets and tested fallback, without exposing validator users or member activity.

The validator that comes back late

A network operator restarts an RPKI validator after maintenance. The local copy remembers a repository location, a session identifier and the last serial it processed. The validator fetches AFRINIC's update notification and asks a simple question: are all the steps from my old state to the current state still here?

If the answer is yes, recovery can be incremental. Each delta describes one repository revision. The client verifies the referenced files and applies the missing changes in serial order. If even one required serial is outside the published chain, unavailable or rejected, the shortcut closes. The normal protocol path is then to retrieve and verify the current snapshot: a complete representation of the repository at one session and serial.

Neither path is evidence of a fault. RRDP was designed to support both. But they impose different transfer and processing work, so an operator planning maintenance, redundancy or incident recovery needs more than the number of delta links visible at one moment.

What the captured notification says

At 16:49 UTC on 14 September, the public file at AFRINIC's RRDP notification endpoint identified session 8fe3109e-2561-4627-8850-83ab94b9bb91 and current serial 96992. It contained 32 delta references. After ordering them by serial, they formed a complete chain from 96961 through 96992.

The response itself carried a one-minute cache instruction: max-age=60, with a stale-if-error allowance. That matters because RFC 8182 recommends that the changing notification file not be cached for longer than a minute. On this evidence, the cache clock is doing the job the standard describes. It is not the problem examined here.

The public HTTP metadata supplied another pair of facts. The first retained delta, serial 96961, had a Last-Modified time of 07:40:05 UTC. The newest, serial 96992, had 14:45:06 UTC. Those timestamps are seven hours and five minutes apart. The current snapshot URL was on the same AFRINIC RRDP origin and returned HTTP 200 during the bounded capture.

That is a useful observation of one repository state. It is not a service commitment.

Why 32 is not a clock

A serial range counts publication revisions, not hours. Thirty-two changes can accumulate quickly during a burst of certificate, manifest, CRL or ROA updates, or more slowly when little changes. The 425-minute spread between the retained endpoints describes this capture's public metadata; it does not guarantee that the next 32 revisions will cover the same period.

The protocol gives a second reason not to translate the count into time. RFC 8182 tells a repository server to exclude older deltas when the combined size of those deltas and all newer ones would exceed the size of the current snapshot. The starting serial is therefore an efficiency boundary selected by the repository, not a fixed retention-day promise. A large burst can shorten the visible time span even if the number of retained files looks familiar. A quieter period can lengthen it.

The same standard tells a relying party what to do at the boundary. It may use deltas only if the notification offers the entire missing chain. If that condition is not met, it processes the snapshot. The distinction is operational: a validator that was disconnected before the earliest useful serial has a different recovery job from one that missed only the latest two updates.

The missing object is a continuity receipt

AFRINIC's current RPKI Certification Practice Statement says that the CA supports RRDP and names the notification endpoint. It also separates publication duties from the signed objects that relying parties validate. The captured materials establish the protocol and the current chain. They do not publish a stable answer to the planning question: what recovery work should an operator expect after a gap of a given length?

A narrow public receipt could answer without promising what the protocol cannot promise. It would show the observation time, session identifier, current and first retained serials, retained count and wall-clock span. It would add compressed and decoded snapshot bytes, total retained-delta bytes, recent session resets, and bounded tests showing that both delta replay and snapshot fallback completed with their hashes verified.

The labels matter. The time span should be called observational, not an SLA. Snapshot retrieval should be separated from validation of certificates, manifests, CRLs and ROAs. CDN response, repository publication, validator processing and the operator's eventual routing policy are different control surfaces. Combining them into one green badge would destroy the value of the receipt.

What this evidence does not show

The 32-delta chain does not prove that AFRINIC retained too little history. The standard does not prescribe a fixed number of delta files or hours, and its size rule can make a shorter chain the efficient result. No real validator was shown to have missed serial 96961, downloaded the snapshot, failed a hash check or produced stale routing data. The endpoint, both sampled deltas and the snapshot reference responded during the capture.

The point is narrower. A live serial list is enough for software to choose its next protocol action. It is not enough for a human operator to budget a maintenance window, assess fallback load or compare redundancy designs. That translation needs a dated record of time, bytes and tested recovery.

Primary sources