Summary

  • In March 2026, RIPE NCC said it would contact roughly 1,600 legacy resource holders without a contract with RIPE NCC or a sponsoring LIR, verify their status and add a co-maintained organisation object.
  • No contract is a policy-recognised state, not evidence of an illegitimate holder. RIPE-639 preserves existing registry services when no formal relationship exists.
  • RIPE NCC’s Q3 2026 plan says these resources had been missing the organisational object used by standard business rules and that a change had to be completed manually in two places.
  • A privacy-safe verification-to-cutover record could bind the outcome, organisation object, two update steps, reconciliation, exception and correction without publishing identity evidence.

The most revealing sentence in RIPE NCC’s current legacy-object plan is not about 1,600 holders. It is about one change.

The Q3 2026 Business Applications plan says that legacy resources without a contract had been missing the organisational object through which other resources are managed under standard business rules. In practice, it adds, a change had to be completed manually in two places. The tooling effort aims to eliminate that duplicate work.

That is a candid description of a migration, not proof of a malfunction. Two deliberate writes can be safer than one premature automation. A historic resource population may contain dissolved companies, renamed institutions, inherited holdings, individuals, partial transfers and contact structures that do not fit the portal path built for current members. RIPE NCC can reasonably want a human to see both states until it understands the exceptions.

The strongest case for the programme begins there. A central organisation object gives each resource a durable management anchor. Co-maintenance brings RIPE NCC into later changes without deleting the holder’s role. A verified update path can reduce reliance on a mailbox or maintainer credential whose institutional context is no longer obvious. And the public plan openly says that the duplicate work is technical debt to be removed, rather than pretending the migration is already complete.

The accountability question is therefore narrower than “is the registry accurate?” It is this: while one case still passes through two places, what proves that both places describe the same result, or records why they do not?

Roughly 1,600 is a campaign population, not a verdict

The starting point is RIPE NCC’s March 2026 Address Policy Working Group announcement. Marco Schmidt, its Registration Services manager, said RIPE NCC planned to contact roughly 1,600 legacy resource holders who had no contractual relationship with RIPE NCC or a sponsoring LIR. The policy did not require a contract. The difficulty was that for many resources the holdership or contact information was outdated, unclear or missing.

“Many” matters. The post did not label all 1,600 records inaccurate. “Roughly” matters too. The number describes the campaign as announced, not the count still unresolved today. The RIPE 91 Registration Services session and its slides give the initiative its earlier public context, but neither turns the population into a list of defective holders.

The announced sequence was concrete. RIPE NCC would contact holders using the available registration information. Once it had verified their status, it would add a co-maintained organisation object to the resources. Future updates would then involve RIPE NCC and undergo similar verification. Where holdership could not be verified, an organisation object with an anonymised name would mark that state until later evidence allowed it to change.

A follow-up sharpened the boundary. RIPE NCC would contact all no-contract legacy holders, but the project’s present task was to verify status. After completion, it would report the cases it could not verify and present possible next steps. The announcement did not say unverified space would be reclaimed. It did not turn non-response into abandonment. It did not make a contract the condition for historical legitimacy.

The no-contract path is part of the policy

That restraint follows RIPE-639. The policy separates a contractual relationship from the underlying legacy resource. It says rights to hold, use or transfer a legacy resource are outside its scope. It also excludes the resolution of disputes over the right to use a particular resource.

Section 2.6 expressly deals with the case in which no formal relationship has been established. RIPE NCC continues the registry-service elements already provided, is not obliged to begin services not previously provided, and may update database entries so they correspond to the current situation. Current legacy-holder service guidance likewise offers a route for a no-formal-relationship holder to request changes. RIPE NCC performs due diligence and, after its evaluation, updates the RIPE Database objects and its internal records.

The distinction is institutional. A contract defines services, duties and remedies between parties. A registry record identifies the resource and the party the registry recognises for a defined purpose. A route announcement shows an operational claim on the network. A transfer procedure evaluates a proposed change of holder. These states can be related without being interchangeable.

The latest due-diligence procedure, RIPE-863, makes the same separation visible by describing controls before and after registration. The current confirmation form for legacy changes asks the requesting organisation to attest that it is the legitimate holder, identify the resource objects and specify the attributes to change. The form is an evidentiary input to a process. It is not a public court judgment.

An organisation object is an anchor, not a deed

The RIPE Database documentation describes the organisation object as the central starting point for managing database data. It links the human and Internet resources associated with an organisation. It also carries authorisation rules: adding a reference requires authorisation from the organisation, whereas removing one does not. Jointly managed member objects have their own division of fields and portal controls.

Those details explain why adding the object is operationally useful. They also show why the word “verified” needs a type and a scope.

A holder can be verified as the party RIPE NCC will involve in future registry updates. That does not automatically prove every historical link in a chain of succession. It does not create a contract. It does not establish current routing control. It does not decide whether a transfer will pass a later review. It does not, by itself, provide RPKI access.

The separate procedures make this visible. The legacy transfer guidance requires clarity about the legitimate holder and supporting documents before RIPE NCC updates the database for a new holder. The RPKI guidance for independent and legacy end users requires an appropriate contract and an Access account authorised for the organisation object associated with the resource. The current legacy agreement, RIPE-834, is yet another object: a voluntary contractual framework for defined services.

If the campaign collapses these states into one label, an organisation object will carry more meaning than the public rules give it. If it keeps them typed, the object becomes what it should be: a management anchor whose provenance and authority can be inspected.

Two places create a reconciliation obligation

The quarterly plan does not name the two places at field level. Public guidance says that no-contract changes can update both RIPE Database objects and internal records. That is enough to explain why two surfaces may exist, but not enough to claim which exact database, screen or transaction the Q3 sentence meant.

The safe conclusion is bounded. The public plan acknowledges manual duplicate handling. It does not publish a case-level reconciliation record, a cutover criterion or a current count of cases in each outcome class. This absence does not prove RIPE NCC lacks internal case files, logs, locks, rollback, monitoring or reconciliation. It means an outside holder cannot use the checked public record to reproduce the transition.

A useful public receipt would not expose a passport, corporate extract, contact address or confidential dispute. It would expose the mechanics of state change:

Receipt field What it proves
Campaign and process version Which verification rules and source population applied
Protected case or resource-set digest Which case moved, without publishing identity evidence
Verification outcome and time Verified, pending, unverified or corrected, with a defined scope
Organisation-object state Object ID or anonymised-unverified marker, plus effective time
Maintainer boundary Who can initiate or authorise which class of update
Pre-state digest The state from which both update steps began
Surface A and surface B results Success, rejection, not applicable or exception for each required step
Reconciliation Whether the states agree, and the reason class if they do not
Cutover and post-state Which system or rule now controls future updates
Correction lineage How later evidence supersedes an earlier outcome

The receipt should be case-specific but privacy-safe. RIPE NCC could publish aggregate campaign counts and make the detailed receipt available to the affected holder, with a public digest proving that the same record existed at the time. An anonymised-unverified marker would then be a reviewable state, not an unexplained stain.

This would also vindicate the present design. If the two steps agree, the receipt shows competent migration. If one is not applicable, it records why. If a case remains pending, it prevents a temporary classification from being mistaken for a final finding. If later evidence changes the result, the correction lineage preserves both accountability and fairness.

The programme should end with a declared cutover

The October 2026 target is not merely a deadline for sending emails. A campaign can contact every holder and still leave the operating model half-migrated. Completion needs at least three independent statements: what share of the announced population reached each outcome class; which exceptions remain; and whether future changes now travel through one authoritative workflow rather than two manual steps.

RIPE NCC has already supplied the crucial honesty: the duplicate work exists and the tooling is meant to remove it. The next public account should close that sentence. It should show when the organisational object became the reliable management anchor, when the second manual action ceased to be required, and how the last unresolved cases remain visible without being prejudged.

The question is not whether old records should be modernised. They should. The question is whether modernisation leaves a record of its own authority. Roughly 1,600 holders are too many for trust to depend on a collection of unjoined case notes, and too varied for one organisation object to become a universal answer. The durable result is not the object alone. It is the reconciled path by which the object came to govern the next change.

Sources