Summary

  • An IRR route object states that a prefix may be originated by a named AS within one registry source. It is a declaration used to build policy, not a live observation of BGP, a resource certificate or a conclusive statement of legal title.
  • The usual operational chain expands an AS or AS-SET, retrieves matching route and route6 objects from selected IRR sources, compiles the resulting prefixes into a filter and deploys that filter to customer or peering sessions. An obsolete entity matters when it survives that selection and compilation chain.
  • Moving a network can mean changing transit while retaining the origin AS, changing origin while retaining the prefix holder, transferring the prefix, moving between RIR service regions, or using a temporary mitigation provider. Each event requires a different judgment about which route objects should continue.
  • Stale entries persist because the party motivated to create a replacement is often not the party holding the old maintainer credential. Former providers have little commercial incentive to clean up, staff and accounts disappear, and independent databases have no common transaction that retires every duplicate.
  • Neither a mismatch with current BGP nor old age alone proves that an entity should be deleted. Backup routes can be dormant, intended announcements can be prepared before use, and an observed route can itself be unauthorised. RPKI, registration records, holder authentication, notices and bounded BGP observations must be combined.
  • Deletion can interrupt reachability when operators automatically rebuild filters. Safe migration is make-before-retire: establish the intended new declaration in an appropriate source, test how named consumers resolve conflicts, notify affected parties, remove superseded authority, verify mirrors and then verify filter deployment.
  • A resource holder needs standing to challenge a route object covering its prefix even when another maintainer controls the entry. The registry also owes the listed maintainer notice, a reason, an evidence record, an emergency review path and a reversible suspension stage where the risk of mistaken deletion is material.
  • A Number Resource Society can define a portable migration receipt, source-quality tests and reciprocal duties for holders, registries and operators. It should not appoint itself as a universal routing authority or claim that observations at selected networks prove global filter convergence.

A route can leave while its declaration stays

Consider a company that has originated the same address block through one autonomous system for years. It buys service from a different carrier, changes its routing design and begins announcing through another AS. The new provider asks for a route object before opening its filter. The company creates one in a registry accepted by that provider. Traffic moves. The old carrier is disconnected. Yet a route object naming the former origin remains under a maintainer account controlled by an engineer who left long ago, in a database the company no longer uses.

Nothing in BGP automatically deletes that declaration. BGP distributes reachability; it does not send a cancellation instruction to every routing registry when a business relationship ends. Nor does a new route object supersede all older entities by a universal rule. The old and new prefix-origin pairs can coexist in different databases, or in the same one when their keys differ. A mirror can return both. A filter builder may include one, the other or both depending on its selected sources, query order, suppression settings and expansion method.

The resulting risk is often misunderstood. An old route object does not make a router originate a route. It can, however, make a filtering system regard an old origin-prefix combination as eligible. If the former AS mistakenly or maliciously announces the prefix, a network whose policy still admits that combination has one fewer barrier. In the opposite direction, deleting an entity still required by a provider can cause the next filter refresh to reject the legitimate announcement. Persistence creates residual permission; careless removal creates a reachability hazard.

This is why the problem is institutional rather than merely clerical. Different parties control the prefix registration, the origin AS, the route object, the mirror, the filter generator and the routers. The network move changes some of those relationships but may leave the old credentials and declarations untouched. A sound migration has to transfer operational recognition across the entire chain while preserving a means to contest mistakes.

The 1995 route object separated allocation from routing intent

The route object arrived with a useful act of conceptual hygiene. RFC 1786, published in 1995, separated address-space allocation information from information about a routing announcement. A route object identified an exact prefix and one origin AS. Where a route could be originated by more than one AS, the registry could contain multiple entities. The design acknowledged a fact that remains important: the organisation recorded as holding or receiving address space and the AS injecting a route are related, but they are not the same fact.

RPSL later standardised the representation. RFC 2622 made the prefix and origin pair the class key. It also described maintainers, route sets, AS sets and policy expressions that could be processed by software. The entity was not conceived as prose for a passive directory. It was intended to be combined with other entities so operators could check policies and generate configurations. RFC 2650 showed the practical bridge from published RPSL to vendor-specific router configuration.

That history explains both the endurance and the awkwardness of the system. Text entities were portable, public and automatable at a time when interdomain coordination needed a common language. Distribution across registries matched the distributed character of network administration. Yet the route object carried no automatic awareness of a later contract termination, merger, transfer or change in the live routing table. Its durability was a feature for stable policy and a liability for succession.

The early model even included a withdrawn attribute in the predecessor specification. Marking an old route as withdrawn could preserve historical routing information without presenting it as current. Modern operational practice has generally centred on current route and route6 objects, deletion, source selection and external history. The underlying governance question did not disappear: who may declare that an earlier routing intention has ended, and how does that decision reach every consumer that converted the declaration into policy?

The answer cannot be simply "whoever can still log in." Credentials are necessary for ordinary maintenance, but an abandoned credential arrangement should not freeze an obsolete permission forever. Nor can the answer be "whoever currently announces the prefix." Observed BGP is evidence of use, not self-authenticating authority. The separation introduced in 1995 has to be maintained during migration, not collapsed for convenience.

A route object is neither the route nor the resource

Three records are easily conflated. A number registry records the organisation to which an address block is allocated, assigned or otherwise registered under its rules. An IRR route object records a prefix and an intended origin AS in a named routing-registry source. BGP collectors observe announcements that appeared at particular vantage points. Each answers a different question.

The registration record can support a claim about who may manage the resource within an RIR's administrative system. It does not show that the holder is currently routing the prefix or which provider it has authorised. The route object expresses routing intent, but the strength of that expression depends on the database's admission and update controls. The BGP observation shows that an origin was visible, but not whether the resource holder consented to it. Treating any one as complete evidence makes migration either unsafe or impossible.

RPKI adds a stronger, narrower statement. A valid Route Origin Authorisation can cryptographically link certified address authority to an origin AS and permitted prefix lengths. That makes it highly relevant when deciding whether an IRR route object conflicts with current holder intent. It still does not reproduce all RPSL policy, prove a commercial relationship or show that a route is live. A holder can prepare a ROA before announcement; a route can be NotFound because no covering ROA exists; and a mistaken holder can authorise the wrong origin.

The stale-entity question must therefore be stated precisely. It is not "does this entity differ from today's BGP?" It is "does this entity continue to express a current, authorised routing possibility, and should named consumers still turn it into permission?" A backup route may be absent from the global table yet valid. A temporary scrubbing provider may appear only during an attack. An old transit origin can remain visible in a collector because withdrawal has not reached every path. A newly hijacked route can look current.

Evidence must be compared by function. Registration establishes administrative standing. Holder authentication establishes who is asking. RPKI can establish certified origin intent where deployed. Contract or change records establish the planned move. BGP observations show operational state. The old maintainer's response can explain a proxy registration or continuing service. No responsible registry should use one convenient signal as a universal deletion oracle.

Filters turn historical text into present permission

The route object's practical force appears in an operator's filter-building procedure. A transit network may ask a customer for an AS-SET name. Software recursively expands that set into AS numbers, looks up route and route6 objects whose origins match those ASes, obtains the relevant prefixes and emits a prefix list or policy fragment. The operator reviews or automatically deploys the result on the customer's eBGP session. Peering networks and route servers can use variations of the same method.

The bgpq4 utility makes this conversion explicit: it generates prefix lists, route filters and AS-path lists from IRR data, and it allows the caller to specify the IRR sources to use. RADb's query service likewise permits a client to select sources and otherwise returns information collected from multiple registries. IRRd can order default sources, apply RPKI suppression, apply scope filters and suppress lower-preference overlapping route objects. The database answer is therefore an input shaped by local policy, not one globally canonical set.

An old entity has several possible effects. If a filter is built for the former origin AS, the old prefix may remain on that AS's allowed list. If a customer's AS-SET still contains the former origin or an obsolete downstream, recursive expansion can carry the prefix into a broader policy. If the consuming IRR instance includes every mirrored source without preference, a duplicate in an independent database can survive after an authoritative copy is removed. If the operator never refreshes its generated configuration, even a correct deletion may not remove the old permission from the router.

The converse also matters. A new route object can be perfectly authorised in its home database and still fail to reach a carrier whose mirror is delayed, whose chosen source list excludes that database or whose configuration job has not run. Migration is not complete at acceptance by the registry. Acceptance starts a sequence of distribution, selection, compilation, review and deployment.

The relevant unit of governance is thus the effective filter, not merely the stored entity. Registries should publish enough status information to show when an update entered their authoritative state and their distribution services. Operators should record which snapshot, sources, query options and set expansion produced a deployed filter. Holders should be able to ask whether a named provider has consumed a change. Without these receipts, each party can truthfully say its own step succeeded while the route remains blocked or the obsolete permission remains active.

The incentives favour creation and neglect retirement

RFC 7682 described the asymmetry plainly in 2015. Customers have a strong reason to register new routing information when a provider will not update a prefix list without it. The incentive to remove old information diminishes sharply after a transit change, especially when the new provider does not enforce the same IRR discipline. The new circuit depends on creation; few invoices depend on deletion.

Control is also divided. A provider may have created route objects on a customer's behalf under its own maintainer. That proxy registration was convenient during service. At termination, the customer may control the prefix but not the entity's credential. The old provider's network team may regard cleanup as work for a former customer. The account manager may not understand the routing consequence. The original engineer may have left. A maintainer can survive as a technically valid identity after the human organisation capable of acting through it has become unreachable.

Corporate events compound the problem. A company changes name, merges, sells a network division or outsources operations. The prefix registration may be updated while IRR credentials remain with the predecessor or a contractor. An address transfer may give the recipient standing in the number registry without giving it the password or key referenced by an old route object's mnt-by. A move between RIR service regions can change which integrated IRR is best placed to authenticate the address holder, while independent third-party entities remain elsewhere.

There is no natural market penalty for every obsolete record. If the old origin never announces the route, most traffic flows normally. A stale entry can be ignored by filter generation for the new origin and remain invisible to the holder until a security review, another migration or an attempted creation encounters it. RADb's own stale-entity feature reflects this ambiguity: it can flag an entity using BGP, maintainer, RIR and other signals, but the mark itself does not change query behaviour. Information without an assigned duty can become a warning that everyone sees and nobody closes.

A better incentive design attaches retirement to the event that creates change. Transit termination should include an IRR inventory and deletion obligation. Resource transfer should expose all discovered route objects before completion. Registry and provider contracts should give the current holder a documented challenge route. Operators that consume IRR data should publish their refresh and exception practices. Cleanup must become part of ending authority, not volunteer housekeeping after the commercial relationship has disappeared.

"The network moved" describes several different events

Migration is too broad a word for one deletion rule. The simplest case is a transit change with no origin change. The holder keeps its ASN and announces the same prefixes through a new upstream. The route object may remain entirely correct because it binds the prefix to the holder's unchanged origin, not to the old transit provider. What needs removal may be an obsolete AS-SET membership or provider-managed proxy copy, not the prefix-origin declaration itself.

A second case changes origin while keeping the same holder. An enterprise may move from a provider-originated service to its own ASN, switch managed networks or place origin control with a different group company. Here the old route object can represent a permission that should expire. A planned overlap may be legitimate while both origins announce during cutover. Deletion before the new provider has rebuilt filters can interrupt service; indefinite coexistence leaves residual authority.

A third case transfers the address resource. The new registered holder may retain the old origin temporarily, use a new one immediately or appoint a third-party network. The transfer record supports the recipient's standing to manage current routing intent, but it does not reveal the intended route by itself. Old entities need review rather than mechanical deletion. The same prefix-origin pair can remain valid under a new holder, yet its maintainer and contact chain may still need migration.

A fourth case crosses registry regions. The authoritative number record and preferred integrated IRR can move, while route objects in a previous source, RADb or another independent registry continue. The RIPE NCC's treatment of out-of-region entities illustrates the significance of this boundary. Existing entities were relabelled RIPE-NONAUTH, new out-of-region creation was stopped, and later policy used conflicting RPKI evidence, notice and a waiting period for deletion. Source status changed because the institution's ability to authenticate the prefix changed.

Temporary operational changes form a fifth case. DDoS mitigation, anycast launches, disaster recovery and mergers can produce a second origin that is intended to exist only under stated conditions. A snapshot taken during activation may make the temporary entity look current; a snapshot taken during dormancy may make it look stale. Such entities need explicit purpose, owner and review conditions. Time alone is a weak substitute for declared scope.

The migration record must identify which event occurred. Otherwise a registry may delete a durable same-origin entity because a carrier changed, preserve an obsolete origin because the holder did not change, or treat a temporary emergency authorisation as permanent. Precision about the event is the first safeguard against both residue and mistaken cleanup.

Maintainer protection preserves control and can preserve abandonment

RPSL maintainers solved an essential problem: public routing declarations should not be editable by anyone who dislikes them. RFC 2725 distinguished authentication from authorisation and described how mnt-by, mnt-routes, mnt-lower, reclaim rules and related controls could govern additions and changes. In ordinary operation, the route object's own maintainer authorises modification or deletion. That protects operators from arbitrary interference.

Hierarchy was meant to add recourse. Address-space and AS maintainers could authorise route creation; reclaim concepts could allow a superior resource authority to recover subordinate entities; auth-override described delayed recovery when a maintainer had become inactive. Deployment varied, however, and the distributed repository design never became one uniform global authority chain. RFC 7682 observed that stale information could remain because third parties could not safely remove it and because override semantics risked acting before the listed holder received effective notice.

Current RIPE Database controls show one practical answer within an authoritative region. A current resource holder can force-delete certain blocking route objects through the maintainer on a covering address-space entity, even without the route object's own credential. The authority is bounded by the RIPE NCC-maintained resource hierarchy. It permits deletion, not silent reassignment, and it does not create equivalent standing in every independent IRR.

That limitation is appropriate. A registry serving a resource holder should not claim control over every third-party database merely because the address is registered in its region. Yet the holder should not have to plead informally with an abandoned proxy maintainer forever. Each IRR needs a published rule explaining what evidence gives a current holder standing, when another registry's record is accepted, what notice is sent, how a suspension can be contested and who approves irreversible deletion.

Maintainer protection is legitimate only when paired with succession. A credential identifies who may operate an entity under current rules; it does not prove that the underlying permission remains substantively valid for all time. The institution earns trust by preserving authorised control during service and enabling evidenced recovery after control has lawfully changed.

Mirroring distributes availability and also distributes delay

The IRR is a federation of databases rather than one table. Operators often query an IRRd instance that holds an authoritative local source and mirrored copies of several others. RADb advertises a combined query view drawn from registries across the IRR. The model improves availability and lets a filter builder use one endpoint instead of contacting every registry separately.

Mirroring also separates the moment of deletion from the moment of disappearance. An authoritative source accepts a change. A journal or snapshot makes it available. A mirror polls, validates sequence and applies the update. A downstream mirror may repeat the process. The operator's filter service then queries its local view on a schedule. The router receives a later configuration change. Each stage has its own clock and failure modes.

RFC 7682 documented older NRTM and flat-file practices, including insecure replication and substantial refresh intervals. Implementations have improved. Current IRRd can use imports, NRTM streams, journals, serials and source-specific settings; RIPE's newer NRTM design provides versioned snapshots and deltas with hashes and source identity. Better transport integrity and faster polling reduce uncertainty. They do not cause an operator to select the right source or remove an independently maintained duplicate.

An entity deleted in source A may continue as a distinct entity in source B. This is not necessarily mirror lag. It may have been separately submitted, copied under another maintainer or retained as a non-authoritative record. Conversely, an entity visible at a combined query endpoint may be a faithful mirror whose authoritative origin has not yet processed a challenge. Investigators need to distinguish provenance from transport.

Cross-database synchronisation therefore has two meanings. Technical synchronisation asks whether mirrors have applied a source's current serial or snapshot. Institutional synchronisation asks whether every source that independently asserts the superseded permission has reviewed the same migration evidence and reached a justified state. The first can be automated by replication protocols. The second requires common references, reciprocal notices and accountable decisions.

A migration receipt should record both. It names the entity in each source, the authoritative update time, mirror observations and the status of independent duplicates. "Deleted from RADb" or "updated at the RIR" is not enough when another selected source still returns the old pair. Nor should a team keep deleting blindly until a combined query looks clean; it must know which institution made each assertion and under what authority.

Source proof must travel with the request

The party seeking retirement should present more than a screenshot of the current routing table. A credible request starts with resource standing: an authenticated current holder in the relevant RIR, or an authorised delegate whose scope is clear. It identifies the exact prefix, old origin, new or continuing origin, every known source and maintainer, the migration event and the requested effective state.

The evidence can then be layered. A current registration record supports control of the prefix under the RIR's rules. A ROA can support current origin intent when its coverage and maximum length actually match the route in question. A signed or authenticated declaration from the holder explains whether an old origin is revoked, retained for backup or authorised through a transition date. Provider termination or transfer records can corroborate the event without requiring commercial terms to be made public. BGP observations show whether old and new origins are visible at named times and vantage points.

The old maintainer must also be heard where feasible. It may show that the entity covers an active customer route under a different corporate name, that a mitigation arrangement remains in force or that the requester's registration change is disputed. Silence after verified delivery and a defined response period is evidence of unresponsiveness, not proof of every underlying fact. The decision-maker should say what weight it assigned to silence.

The proof standard should rise with the consequence. Suppressing a clearly RPKI-invalid entity in a non-authoritative query view is different from erasing the only declaration on which a critical provider relies. An emergency challenge involving an apparent hijack may justify temporary suppression and rapid review. Permanent deletion in an ambiguous transfer may require stronger holder authentication, two-person approval and evidence that a replacement path is ready.

Every decision should preserve a non-public audit record: submitted claims, validation results, notices, responses, conflicts, reviewer identity, time and reason. Public output can be narrower, exposing entity status and a reason class without personal data or sensitive contracts. The point is not maximum disclosure. It is the ability to prove later that residual routing authority was removed by a rule rather than by influence or accident.

BGP is a witness, not a judge

Live routing data is indispensable because an IRR exists to describe operational policy. RADb's stale-entity assessment compares prefix-origin pairs with BGP and supplements direct matches with maintainer, AS-link, RIR and reputation signals. Recent measurement work presented through RIPE Labs similarly compares route objects with authoritative IRRs, RPKI and the default-free zone to identify conflict, redundancy and inactivity. Such methods reveal patterns that static registry inspection cannot.

Yet BGP visibility has sharp limits. Collectors see selected peers, not every private interconnection. A backup announcement may be intentionally absent. A more-specific may appear only during traffic engineering or attack mitigation. Aggregation can make a legitimate route object look unused. A route can be visible because an unauthorised origin succeeded. The absence of observation is not proof of abandonment, and presence is not proof of consent.

Time windows help but do not cure the problem. An entity that has not matched observed BGP for years deserves review, especially when contacts are dead and a current holder disputes it. It still may describe a cold standby or a prefix advertised only within a limited routing domain. A young entity can be wrong on the day it is created. Last-modified time measures interaction with the database, not truth.

The useful role for BGP is evidentiary and bounded. A migration team can name collectors, upstream looking glasses or its own session telemetry; record the observed origin before, during and after cutover; and retain contradictory results. If the old origin disappears everywhere observed while the new origin and replacement filter work, confidence in retirement rises. If the old origin persists, the team investigates whether it is propagation, leakage, intentional overlap or misuse.

Measurements should never be laundered into an unsupported global denominator. A study of selected IRRs and routing collectors can describe its dataset, dates and classification method. It cannot show how every private operator built filters, how many dormant entities were legitimate or how many migrations caused customer harm. Institutional decisions should use measurements as disciplined evidence, not as decorative certainty.

RPKI can establish precedence without becoming a deletion machine

RPKI offers something conventional IRR objects generally cannot: a cryptographically verifiable statement rooted in certified number-resource authority. When a current ROA covers a prefix and authorises one origin while an IRR object names a conflicting origin, the conflict is powerful evidence. RIPE policy 2018-06 used that property to clean conflicting route objects from RIPE-NONAUTH, with notification and a sustained conflict period before deletion.

IRRd can also suppress route objects that are RPKI-invalid and can expose ROA-derived pseudo-IRR objects to existing filter tools. ARIN has gone further in another direction by linking creation of authenticated IRR route objects to ROAs through its IRR Auto-Manager. These mechanisms reduce divergence and give operators a stronger origin signal without requiring every filter system to be replaced at once.

But three cautions matter. First, NotFound is not invalid. If no covering ROA exists, RPKI supplies no conflicting authority. Deleting every NotFound IRR object would punish holders that have not deployed RPKI and could remove legitimate routing data. Second, a valid ROA can coexist with a route object for the same origin while other RPSL policy remains wrong or stale. Third, a ROA can contain an operational mistake made by the legitimate holder. Cryptographic authority is not omniscience.

Precedence also needs entity-level precision. The comparison must use prefix coverage, origin and allowed length correctly. A ROA for an aggregate with a restrictive maximum length may make a more-specific route object invalid even when the holder intended that more-specific for a future event. The remedy may be to correct the ROA, not delete the IRR object. Notice allows the holder to distinguish a security conflict from a configuration error.

The right rule is that a valid, current, holder-controlled cryptographic statement deserves higher evidentiary weight than an unauthenticated third-party assertion. It does not eliminate the need to identify the event, warn affected operators, protect continuity and record the remedy. Strong proof should make due process faster and more exact, not unnecessary.

Deletion has to be staged because filters have memory

The safe sequence begins with inventory. Search authoritative RIR IRRs, independent registries, combined query services and the source sets used by known providers. Record exact prefix-origin keys, maintainers, contacts, creation and modification times, source labels, RPKI state and observed BGP. Expand relevant AS-SETs because an obsolete relationship can survive there even after a route object is corrected.

Next define the intended terminal state. Which origins should remain authorised? Which prefixes and lengths will actually be announced? Is there a planned overlap, backup or mitigation role? Which source is appropriate for the current holder? Who controls each replacement entity? This declaration prevents cleanup from becoming a contest to minimise the number of records regardless of operational purpose.

Then make before retire. Create or correct the intended route objects through sources that can authenticate the current holder. Create consistent ROAs where appropriate. Ask named transit and peering operators to run a preview of their generated filters. Confirm that the new origin would be accepted and that recursion through AS-SETs produces the expected prefixes. A registry acceptance email cannot substitute for this consumer-side test.

Only then should retirement notices issue. The old maintainer, current resource holder, origin-AS contact where available and known consuming providers receive the exact entity, evidence class, proposed action, response deadline and emergency contact. A disputed entity can be suspended from ordinary query views while remaining retrievable to reviewers, if the registry's rules support that remedy and the risk justifies it. The suspension must not silently become permanent deletion.

After the decision, each authoritative or independent references its action under a common migration reference. Mirrors are checked against source serials or snapshots. Combined queries are repeated with explicit source selection. Operators rebuild filters, review the delta and apply route refresh or their equivalent safe policy update. Observations confirm that the intended route remains accepted and that the superseded origin is no longer permitted at the named sessions.

Closure comes last. The receipt lists unresolved sources, unreachable operators and any continuing exception. If a third-party registry refuses deletion, the holder and providers can exclude or lower the preference of that source for the affected prefix, but the exception remains visible. A green status should mean bounded completion, not that inconvenient evidence was omitted.

Cross-database coordination needs a common event, not a central database

It is tempting to solve inconsistency by proposing one global IRR. That would simplify some queries while concentrating the ability to admit, suppress and delete routing declarations. The history of the Internet's routing registries reflects legitimate regional, provider and operational differences. Resilience can benefit from multiple publication and query services. The missing element is not necessarily one owner; it is an interoperable change event.

A migration event identifier can bind notices and receipts across registries without requiring them to surrender decision authority. The record includes exact resources, old and intended origins, holder-authentication method, supporting RPKI state, event type, effective interval and contacts. Each registry adds its own decision, reason, time and appeal route. Mirrors carry source data as before. Operators can consume the decisions according to declared preference.

This arrangement exposes disagreement instead of hiding it. An RIR-integrated IRR may accept the current holder's request. RADb may need to verify a separately maintained entity. Another registry may retain an entity because it documents an active backup relationship. The receipt shows three outcomes and their evidence. An operator can then distinguish justified coexistence from an abandoned copy.

Source-specific action also prevents accidental deletion by name collision. Route objects are identified by prefix, origin and source, not by prefix alone. An entity in one source may be a mirror of another or an independent assertion. A common event must preserve that provenance. It should never instruct every database to erase all matching text without asking who originally accepted it and which users depend on it.

Coordination should include negative acknowledgments. A registry that has no relevant entity says so. A mirror reports the authoritative serial it has applied. A provider states that it does not use the affected source. These bounded statements are more valuable than silence because they reduce the unknown surface. They also make post-incident review possible when a filter later differs from the expected state.

The model is federated accountability: common evidence and status semantics, local authority, portable receipts and visible exceptions. It aligns with the distributed character of the IRR while correcting the assumption that independent databases will somehow infer the same migration from BGP.

Notice is an operational control, not administrative courtesy

Notice is sometimes treated as delay added by lawyers. In routing-registry cleanup it is part of technical validation. The listed maintainer may know why an apparently obsolete entity remains. The current holder may discover a conflicting ROA. The origin AS may learn that a customer relationship was never closed. A provider may identify a filter dependency that needs a replacement before deletion.

Effective notice must reach more than the address embedded in a twenty-year-old entity. The registry should use the entity's notify and maintainer contacts, current RIR published contact points, the registered holder account and, where appropriate, the origin AS's operational contact. Delivery results should be recorded. Publicly exposing every address is unnecessary; proof that the institution tried the relevant channels is enough for review.

The message needs consequence and remedy. It states whether the proposed action is warning, preference reduction, suppression or deletion; when it will occur; what evidence triggered it; how to contest; and how to obtain urgent review if reachability is affected. Vague requests to "update your records" create no accountable deadline. Immediate deletion without a path to halt a mistake can turn data hygiene into denial of service.

Response periods should be risk-based rather than ceremonial. A clearly conflicting, non-authoritative entity during an active abuse event may warrant rapid temporary suppression. A dormant but uncontradicted backup entity may justify a longer review. The institution should publish the factors, not invent a different period for each influential requester. Any emergency action receives prompt independent review.

Notice also reaches consuming networks. A transit provider does not need confidential evidence, but it needs to know that a prefix-origin entry it uses will change and that a replacement has been prepared. Operators can stage filter deltas, inspect unexpected removals and avoid rebuilding at the worst moment. The cost of a few precise notices is small compared with debugging a route rejected by several layers of stale policy.

Rights and remedies determine whether cleanup is legitimate

The current resource holder needs a right to discover route objects covering its prefixes, including source, maintainer, status and challenge route. Discovery should not depend on knowing every database name. Combined search services can help, but their coverage must be stated. A missing result from one endpoint is not proof that no entity exists elsewhere.

The holder also needs standing to request correction or retirement. That right does not guarantee immediate deletion; it guarantees that the registry will authenticate the request, examine evidence, notify affected parties and issue a reasoned decision. Where the route object's maintainer is a former provider, the holder should not be told that only the former provider may speak. The very dispute is about whether that delegated operational authority ended.

The listed maintainer has reciprocal rights. It can see the claim, present evidence of continuing authorisation and appeal an adverse decision. If credentials were compromised, it can ask for emergency suspension. If the current holder is mistaken about a backup or customer arrangement, the record can be retained or amended. Due process protects accurate routing information as much as it removes residue.

Consumers need a different remedy: an exception with an expiry. If a registry decision is delayed while a stale entity creates demonstrable risk, an operator can exclude the entity or source for the affected prefix under documented policy. If deletion unexpectedly blocks service, it can temporarily restore a reviewed exception while the holder and registry repair the authoritative declaration. Exceptions should be narrow, logged and automatically reconsidered.

Independent review completes the structure. A reviewer checks the authority chain, evidence, notice, technical effect and consistency with published rules. It should be possible to reverse a mistaken suppression and to create a new current entity without falsifying history. Old versions can remain in protected history even when they disappear from normal policy queries.

Legitimacy is visible in remedy. A database that can accept entities but offers no practical correction path asks operators to trust permanence without accountability. A database that deletes on private request without notice asks them to trust discretion. The credible middle is evidence, standing, bounded action and review.

The useful metrics measure closure, not the size of the database

Counting route objects is easy and often misleading. A database can reduce its total by deleting legitimate dormant policy. It can boast high freshness by touching timestamps without confirming authority. It can report few conflicts because its source-selection rule hides lower-preference entities. Governance metrics should follow the migration event and retain the denominator.

For each participating migration, measure the interval from authenticated request to complete inventory; the share of discovered entities for which a responsible maintainer was reachable; the interval to replacement acceptance; the time to each independent source decision; mirror lag; the time to named operator filter refresh; and the number of unresolved exceptions at closure. Separate same-origin transit changes, origin changes, resource transfers, inter-regional moves and temporary services because their expected states differ.

Quality measures should also record false action. How many proposed stale classifications were withdrawn after a maintainer demonstrated current use? How many deletions required emergency restoration? How many replacements were syntactically accepted but omitted from a provider's selected sources? How many old permissions remained after the target date? Publishing both over-removal and under-removal discourages a registry from optimising only one side.

Source-level statistics need context. RADb's stale labels are useful review signals, but its documentation says the label does not alter query results. An IRRd deployment that suppresses RPKI-invalid or lower-preference entities is measuring effective visibility, not physical deletion. An RIR IRR may have a stronger resource-holder tie than an independent registry but narrower regional coverage. Comparisons should state these design differences.

No selected evidence provides a complete global denominator of route-object migrations, filters generated from stale entries, successful attacks enabled by residual permission or outages caused by deletion. Private provider configurations and customer disputes are not generally observable. Reports should describe the registries, dates, entity classes, BGP vantage points and participating operators actually studied.

Honest bounds do not weaken the case for action. They make performance claims useful. A holder cares whether its own move closed across named sources and providers. An operator cares whether its filter came from current, authorised inputs. A registry community cares whether its remedies work and mistakes are repaired. Those questions can be measured without pretending to see every router.

A Number Resource Society can standardise the handover receipt

Number Resource Society argues for accurate number registration, clearer rights for network operators and limits on concentrated administrative discretion. Applied carefully, those principles support a practical role in IRR migration. NRS can convene holders, registries, transit networks and software operators to define a portable receipt and evidence vocabulary.

The receipt would not be a route object and would not authorise BGP. It would record the event around authoritative declarations: prefix, old and intended origins, event type, relevant RIR, IRR sources, maintainer status, holder authentication, RPKI comparison, notices, source decisions, mirror observations, filter tests, exceptions and reviewer. Signatures or authenticated attestations identify who made each statement without pretending that one institution made them all.

NRS can also publish conformance tests. A registry demonstrates discovery, current-holder challenge, former-maintainer notice, reversible suspension, deletion logging and mirror status. A provider demonstrates explicit source selection, reproducible AS-SET expansion, staged filter update and exception expiry. A transfer or managed-network provider demonstrates that termination includes an IRR inventory. Test results expire and identify the version examined.

This would advance decentralisation by making service quality portable. Holders could compare whether an IRR offers credible recovery. Operators could prefer sources whose authority and freshness controls are measured. Registries could coordinate without creating a new central signer. Researchers could analyse completed events with consent and proper bounds.

NRS should remain evidence-aware. Its public materials state advocacy positions; they do not prove deployment of an IRR migration service or universal member consensus on technical details. Accreditation cannot compel an RIR to delete an entity, guarantee that a provider refreshes filters or establish legal title to address space. The Society's value would lie in standards, transparency and member support, not in claiming a root authority it does not possess.

The strongest positive role is to make rights executable. A holder who has moved should know where old declarations remain, how to challenge them, what proof is required and when each consumer changed. That is more concrete than a slogan about control and more compatible with a distributed Internet than replacing one unaccountable gatekeeper with another.

Migration ends when the old permission no longer reaches policy

A tidy IRR search result is not the final objective. The intended network must remain reachable through authorised origins, and the former permission must cease to influence the filters that matter. That state can be described without claiming universal knowledge.

The current holder is authenticated. The intended prefix-origin declarations exist in appropriate sources and, where used, align with valid ROAs. Planned backups and temporary origins have explicit scope. Superseded entities have been deleted or suppressed under published rules after notice and review. Independent duplicates are resolved or named as exceptions. Mirrors have applied the relevant authoritative changes. Named transit and peering networks have rebuilt and deployed filters. BGP observations at declared vantage points match the intended state.

Every clause matters. Without holder authentication, cleanup can become hijacking by administration. Without a replacement, deletion can block service. Without notice, a legitimate dormant route can be erased. Without source-by-source action, duplicates survive. Without mirror and filter evidence, a registry change may never reach routers. Without bounded observations, a completion claim outruns what anyone measured.

The old route object is not dangerous merely because it is old. It becomes dangerous when an obsolete assertion retains operational force without a current accountable principal. Nor is deletion inherently virtuous. It is safe only when the institution can explain why authority ended, how continuity was protected and what remedy exists if the judgment was wrong.

The IRR's founders designed a distributed means to turn declared routing policy into coordination. Three decades later, that same strength makes succession consequential. Text written for one commercial and technical arrangement can be copied, mirrored and compiled long after the arrangement changes. Networks move faster than institutional memory unless migration is made an event in its own right.

The governing rule is therefore simple but demanding: prove the present source of authority, make the intended policy usable, notify those who can contradict the evidence, retire old assertions across every independent source, verify distribution, and close only after named consumers have changed. A network has not fully moved while its former permission still lives in the filters of the networks on which it depends.

Sources