Summary

  • RIPE Database release 1.124 entered production on 27 August 2026 with a change saying that the NRTMv3 server should skip invalid objects.
  • Skipping an unusable object may protect availability, but a stream that continues does not by itself prove that a mirror contains every object the authoritative server considered.
  • RIPE's public material does not state how many objects are affected, which classes or sources are involved, which validation rules apply, how serials behave, or whether skipped objects can later be corrected and replayed.
  • A privacy-safe omission receipt should identify the stream boundary, source, object class, validation-rule version, reason family, count, disposition and replay state without publishing the rejected object or personal data.

The serial moved; what did the mirror learn?

On 27 August, RIPE Database software version 1.124 moved into production. Its release notes list authentication and browser-security changes, new response formats and one sentence about replication: “NRTMv3 server should skip invalid objects.” The sentence does not name an incident or announce a policy dispute. It describes running code, and that is precisely why it deserves close attention.

An NRTMv3 mirror begins from an exported database and a current serial. It then consumes near-real-time changes. RIPE's setup documentation tells an operator to preserve the serial corresponding to the downloaded snapshot and later confirm that the maximum serial in the mirrored database has advanced. That test is useful. It shows that the replication process is moving. It does not, after the 1.124 change, necessarily show why every eligible object is or is not present.

Suppose an authoritative update reaches a state the NRTMv3 server regards as invalid. Before this release, attempting to emit it may have failed noisily, produced malformed output or obstructed the stream—the public record does not tell us which condition motivated the change. With 1.124, the stated behavior is to skip the object. The operational gain is intuitive: one unusable record should not prevent later valid changes from reaching mirrors. The evidentiary cost is equally intuitive: a mirror may see later work arrive without receiving a typed explanation for the absent item.

That does not prove that serials develop a visible gap. It does not prove that a client accepts a corrupt replica. It does not even prove that production has skipped a single object since deployment. The release note leaves wire behavior, counts and client effects unstated. The narrower conclusion is enough: when omission becomes an intentional server behavior, continuity and completeness become different claims.

“Invalid” is a decision, not an eternal property

The word invalid sounds binary until it meets a registry with decades of history. RIPE's combined Database documentation acknowledges that many objects have syntax that is invalid under current rules. A record may predate a later schema restriction. It may be interpretable to one implementation while failing the stricter validation used for authoritative updates. It may contain a field that should not be distributed. Or it may be malformed in a way that no mirror can use safely.

Those cases should not be collapsed. A route object whose origin cannot be parsed is different from an old but intelligible object that violates a newer naming convention. A record suppressed to protect personal data is different from one rejected because its structure cannot be indexed. A temporary software defect is different from a durable policy exclusion. Each case can justify a different disposition: omit permanently, transform safely, quarantine for repair, or replay after correction.

The current NRTMv4 Internet-Draft draws a useful distinction without deciding the NRTMv3 question. It advises flexibility where a nonconforming object remains unambiguous, while recognising that some objects cannot be usefully interpreted. It also says that restrictions should be applied consistently to snapshots and deltas. These are design ideas for another protocol, still in draft. They are not evidence that RIPE's NRTMv3 server follows the same rules. They show why a bare “invalid” label is too thin for downstream assurance.

Validity also changes with version. If release 1.124 omits an object under rule set A, and release 1.125 changes the parser or schema to rule set B, the object's status may change without its text changing. A mirror operator needs to know which rule set produced the omission. Otherwise a later correction cannot be distinguished from a different interpretation of the same historical material.

Availability is a serious counterargument

The strongest case for skipping is operational, not rhetorical. Replication is shared infrastructure. A malformed record should not hold every subsequent change hostage. Operators rely on mirrors for research, routing-policy tools, internal searches and local resilience. A server that stops at the first object it cannot serialise can turn one data defect into a service-wide delay.

Continuing the stream can therefore be the safer action. It limits the blast radius, preserves later valid changes and gives the authoritative operator time to repair the exceptional record. Demanding that every invalid body be emitted would be worse. It could expose personal data, distribute material clients cannot parse, or recreate the very failure that the release sought to contain.

But availability does not require opacity. The choice is not between publishing the defective object and saying nothing. A server can preserve the stream while issuing a compact record that an omission occurred. Such a record can identify a class and reason without revealing the object's body, primary key, credentials, contact details or sensitive dispute.

This is the thin-coordination answer. The authoritative server keeps authority over validation and correction. Mirror clients keep authority over their own operational response. The shared layer carries only enough evidence for both sides to agree on the event recorded at the boundary.

Four control surfaces, four different duties

The authoritative database controls acceptance and storage. Its duty is to know which object state exists, which validation rule applies and whether a defect is repairable. That information need not all be public, but it is the origin of any trustworthy omission record.

The NRTMv3 server controls emission. Its decision is narrower: given an authoritative change, can this object be sent in a form the protocol and recipient can handle? Release 1.124 changes this surface by making “skip” an explicit possible outcome. The server should therefore be able to account for that outcome as an outcome, not merely as the absence of bytes.

The mirror client controls ingestion. It may reject malformed input, apply its own object-class filters, retain a local quarantine or alert an operator. A client-side exclusion is not the same event as a server-side skip. Without a receipt, both may appear downstream as “object absent”, even though responsibility and remedy differ.

Finally, a filter builder, analyst or network operator consumes the mirror. That user may never see the replication logs. An absent route object may mean no record was ever created, a record was deleted, the authoritative server withheld it, transport failed, the mirror rejected it, or a local filter excluded it. Treating all six states as one negative answer turns absence into false certainty.

RIPE NCC should not decide how every network interprets an absent object. Nor should it become a central route-acceptance authority. Its narrower responsibility is to make the state transition it controls distinguishable from failures outside its control.

What the public record does not yet establish

No checked source gives the number of skipped objects. None names an affected source such as RIPE or RIPE-NONAUTH. None lists the object classes involved. None states whether skipping happens during serialisation, query construction or another stage. None explains whether an omitted object consumes a serial, whether clients receive a comment, or whether an operator can request replay after correction.

The release notes also do not say that a customer complained, a route was filtered, a mirror became incomplete or an incident occurred. The RIPE 92 transcript explains why NRTMv4 was designed around snapshots, deltas, notification files and recovery, but it cannot fill the factual gaps around a later NRTMv3 release. A protocol comparison is a way to frame questions, not a substitute for production evidence.

These absences should shape the article's recommendation. It would be irresponsible to demand a public list of object keys or bodies. Some omitted material could contain personal data or reveal a record under repair. It would also be premature to prescribe one client action for every reason. The first need is a stable, privacy-safe statement of the server's own decision.

The minimum omission receipt

For each bounded publishing interval, RIPE NCC could expose an aggregate or per-event receipt containing nine elements:

  1. the source and NRTM protocol version;
  2. the affected serial or bounded serial interval, expressed in whatever way matches actual wire behavior;
  3. the object class, but not necessarily its primary key;
  4. the validation-rule identifier and version;
  5. a reason family such as unparsable, unsafe to distribute, legacy-rule conflict or internal processing failure;
  6. the number of omitted objects in that class and interval;
  7. the disposition—quarantined, permanently excluded, transformed, awaiting correction or corrected;
  8. the replay or reconciliation state; and
  9. the receipt timestamp and correction history.

If even object class plus interval would create a disclosure risk, counts could be delayed or grouped. A stable receipt identifier could let authorised operators seek more detail privately. The public layer should reveal that the authoritative stream made a deliberate choice, not the sensitive content on which the choice was made.

The receipt must also close. “Awaiting correction” cannot remain an indefinite label. When an object is repaired, the record should say whether it entered a later stream, appeared only in a new snapshot, remained excluded or was deleted from the authoritative database. That closing state lets a mirror operator reconcile without guessing.

Running code deserves a running record

Release notes are valuable because they show that behavior changed. They are not a substitute for the evidence generated when the behavior runs. Version 1.124 tells users that the server may skip. It does not yet let a downstream operator prove which omission, rule and remedy accompanied a particular stream.

The improvement should not be reversed merely to preserve an illusion of completeness. A replication system that fails closed on every malformed object may be less reliable than one that continues safely. The better answer is to make degraded completeness observable: preserve availability, protect sensitive data, identify the governing validation version and give operators a bounded path to reconciliation.

A moving serial proves movement. After 1.124, RIPE NCC has an opportunity to make it prove something more precise: which changes were delivered, which were deliberately withheld, and whether the missing state can ever be recovered.

Sources