The route-server maintainer has seen this kind of ticket before. A small access provider wants a new prefix accepted at an African exchange. The email is polite and urgent. The customer says the prefix belongs to a university foundation that has recently moved hosting to a local data centre. The letter of authorisation is signed by a finance director whose name does not appear in the registry contact. A route object exists, but its origin AS points to a former transit provider. The AS-SET supplied by the customer expands to two downstream networks and a reseller whose maintainer is held by a managed-service company in another country. The registry contact replies from a personal mailbox. The customer says the change is routine, because packets already move through a backup link. The route server's tooling says something else: accept the announcement and the exchange may help an unauthorised route propagate; reject it and a real African network may lose a cheaper path to local reachability.
The same scene appears, with small variations, in transit departments, cloud onboarding queues, managed-router teams and enterprise procurement reviews. Nobody in those rooms should mistake a route object for a deed. Nobody should treat it as a cryptographic Route Origin Authorisation. Yet the record can still decide whether a prefix enters a filter, whether a migration proceeds this week or next month, and whether a customer is treated as ordinary or exceptional. A carrier needs to know whether a buyer of transit may announce a block. An IXP needs to know what its route servers should pass. A reseller needs to persuade an upstream that its customer delegation is real. A public network needs continuity during a contractor change. A data centre needs to move a customer without becoming the weak link in a hijack. In each case, an old text entry in an Internet Routing Registry can become a practical ticket into the routing economy.
That is the importance of AFRINIC route-object rules. RPSL route and route6 entries are operational prefix-origin declarations: they associate an IP prefix with an autonomous system in a form that network engineers and filtering software can consume. They are not legal title, not a court order, not a membership certificate and not a signed RPKI assertion. Their authority is softer and more institutional. But because carriers, IXPs, managed providers, cloud platforms and customers often use IRR data to build prefix and origin filters, these records can affect whether a prefix is easy to make reachable. In a region where IPv4 scarcity has made operational acceptance valuable, a registry convenience can become a shadow gatekeeper if its purpose and correction rules are not tightly bounded.
AFRINIC's recent institutional history gives the problem unusual force. The registry has faced long-running legal and governance stress, public reporting about IPv4 misappropriation concerns, court-supervised periods, receivership, an annulled 2025 election after reported irregularity allegations and a later restoration of a board. None of those facts proves that any particular routing declaration is wrong. A difficult election does not show that an origin AS lacks authority; a court fight does not show that a maintainer is compromised; a reported address scandal does not justify treating every legacy holder as suspect. But institutional stress changes the cost of ambiguity. When correction channels are slow, contested or poorly documented, operational records acquire more market weight. The answer is not to turn every routing edit into a property trial. It is to make authority narrow, auditable, notice-based and cheap to correct.
The small file that becomes a boarding pass
The route object began as a way to describe routing policy, not as a market instrument. In RPSL, the route class specifies an inter-AS route originated by an autonomous system. Its key is the prefix and the origin AS. The IPv6 route6 class performs the equivalent role for IPv6, using the route6 and origin attributes as its key. The form is deliberately spare. It answers one operational question: if a network claims that AS X originates prefix P, is there a registry entry saying so?
That answer matters because BGP is permissive. A router that receives an announcement does not inherently know whether the announcing AS is entitled to originate the prefix. Operators therefore add policy. They may reject unallocated space, reject overly specific routes, reject routes inconsistent with RPKI data, or reject routes absent from an IRR-derived allow list. Each check answers a different question. The IRR record answers a narrow one: has somebody with relevant authority published the prefix-origin declaration that my tooling expects?
In a low-friction setting, this file stays invisible. A customer asks to announce a prefix. The upstream sees a clean IRR entry, a registry holder record, a contact that matches the request, perhaps a ROA, and an AS-SET that expands as expected. Provisioning closes the ticket. The customer gets transit, the upstream books revenue, the route server avoids an obvious error, and no one needs a theory of institutional design.
Friction begins when the records diverge. A prefix may be registered to one organisation, originated by another, maintained by a third, delegated to a customer and presented to a route server by a fourth. That is not necessarily suspicious. Modern networks are layered. Holders outsource routing. Universities hire service providers. Public agencies procure connectivity through framework contracts. Data centres announce customer space. Resellers aggregate customers behind their own ASNs. Managed security providers steer traffic during attacks. A prefix can move through several legitimate hands before it reaches the person asking an upstream to accept it.
Layered operations create a documentation burden. The registry holder may control legal or contractual rights. The origin AS may control the actual BGP announcement. The maintainer may control the IRR edit. The customer may control the commercial relationship. The third-party carrier may control acceptance. If the entry is stale, or if the maintainer no longer represents the holder, filter tooling can convert old paperwork into present-day reachability. If the carrier rejects the request, it may strand legitimate traffic. If it accepts, it may normalise a weak authority chain. The small file becomes a boarding pass because outsiders can process it more easily than they can process the underlying institutional reality.
This is why the subject belongs in institutional economics rather than in a clerical appendix to BGP. The cost of an unclear record is not borne only by the registry. It is borne by the access provider that loses a customer, by the exchange that has to make an exception, by the data centre that cannot complete a migration, by the public network that pays for manual review, and by the upstream whose security team must decide whether to trust a document it cannot fully verify. Good rules lower transaction costs. Weak rules move them outward into the market, where they appear as delay, risk premiums, bilateral favours and inconsistent filtering decisions.
RPSL's narrow declaration and its wide consequences
RPSL was designed so that routing policy could be expressed in a structured way. RFC 2622 describes the route class as a way to specify an inter-AS route originated by an AS, with the route prefix and origin AS forming the class key. RFC 4012 later extended RPSL for additional address families and describes route6 as the IPv6 counterpart. Those documents are technical anchors, not commercial manifestos. Their importance for AFRINIC is that they define the narrowness of the entry. A route or route6 object is not a general statement about who owns a resource. It is a prefix-origin declaration inside a routing-policy system.
That narrowness is often lost in practice. A network engineer under time pressure asks for "the IRR object" as proof that a customer may announce a prefix. The customer produces the entry. The entry is treated as evidence of legitimacy because the filter tool consumes it. If nobody objects, the operational decision may become a market fact. The route is accepted, traffic flows, contracts are performed and later reviewers may assume that acceptance itself proved authority. The record has not changed legal nature. Its social function has changed.
The gap between legal nature and operational function is where rulemaking matters. If the record is understood too broadly, it becomes a surrogate for title. Whoever can create or preserve it gains leverage over reachability. If it is understood too narrowly, operators may ignore it and fall back on private letters, ad hoc exceptions and relationship-based trust. Neither extreme is healthy. The entry should be treated as a structured operational declaration with known limits and known authority requirements.
The route6 comparison helps because it shows that the issue is not only a relic of IPv4 scarcity. IPv6 networks also need prefix-origin declarations. IXPs and upstreams also build filters for IPv6. But IPv4 scarcity raises the stakes because a single accepted IPv4 prefix can carry market value, customer history and replacement difficulty. A stale route6 entry can create operational risk; a stale IPv4 route object can also affect a scarce asset's liquidity and bargaining power. The problem is the same in form and different in intensity.
These records also differ from ROAs. A ROA is part of the RPKI system and is validated through cryptographic resource certificates. An IRR entry depends on database rules, maintainer authentication, source selection and operator trust. Comparing the two is useful only if the comparison stays disciplined. ROAs can show that a resource holder has published a cryptographically verifiable origin authorisation within the certificate system. Route objects can show that a prefix-origin declaration exists in a routing registry under that registry's update rules. Many operators use both. Neither removes the need to understand who had authority to publish the relevant signal.
The practical consequence is that syntax alone cannot settle the important questions. Who may create the entry when the resource holder and the origin AS differ? Who may delete it when a customer relationship ends? What happens when two sources hold different origins for the same prefix? What if a maintainer is controlled by an outsourced provider that no longer represents the holder? What if the holder is a university whose registry contact retired years ago? What if a receiver, liquidator, court-supervised administrator or public agency claims authority? RPSL supplies the form. Institutional rules determine whether the form remains reliable in real markets.
Maintainers, credentials and the value of edit authority
The mntner object is the quiet centre of the system. RFC 2622 describes maintainers as entities authorised to add, delete and modify sets of objects. That sounds administrative. In a filter-dependent environment, edit authority has economic value. The party that can create, preserve or delete a prefix-origin entry can influence whether a prefix appears in filters. The party that can control an AS-SET can influence which customer ASNs are included in recursively generated allow lists. The party that can update contact fields can affect who receives notice. The party that can authenticate changes can make an operational declaration look orderly even when the underlying business relationship is contested.
Authentication is necessary but insufficient. A password, key, certificate, portal session or two-factor step can show that the user controls the maintainer credential. It does not by itself show that the user still represents the resource holder, the origin AS, the customer or the party with current delegation. A corporate email account can remain valid after a contract ends. A former managed-service provider may retain credentials. A reseller may have edit access for a customer prefix but no authority to authorise a new origin. An employee may control a maintainer while lacking corporate authority. Strong login controls reduce impersonation; they do not settle mandate.
For AFRINIC, the distinction is valuable because institutional stress and address-market value make stale authority more expensive. If maintainer access is loose, entries can be created too easily. If maintainer access is treated as conclusive, old credentials can become economic weapons. If access is too hard to recover, legitimate holders with poor historical records may be locked out of the very files that upstreams expect them to maintain. The registry therefore needs an authority model that separates authentication from entitlement.
The simplest error is to collapse maintainer authority into holder authority. A maintainer may be attached to the holder's records, but the person controlling it may be a contractor, a former network administrator or a third-party provider. The opposite error is to ignore maintainer authority and demand full registry-holder proof for every minor edit. That would make routine operations too slow, especially for small networks that depend on managed services. The useful approach is tiered. Routine updates by a stable, validated maintainer should be quick. Changes that alter the market meaning of the entry, such as a new origin AS, a contested deletion or an edit after account recovery, should trigger stronger checks.
Maintainer rules are also a way to allocate responsibility without pretending to eliminate it. A record can be wrong because the holder made a mistake, because the customer supplied bad information, because the origin AS changed, because a contractor failed to clean up, because the registry process allowed an unauthorised update, or because another IRR copied an old entry. AFRINIC cannot absorb every operational error in the routing economy. But it can require enough attribution to make errors correctable. A change log should show which maintainer acted, under what authenticated account, with what declared basis and with what notice to affected contacts. That evidence reduces the cost of later disputes.
The burden of poor maintainer practice falls unevenly. Large carriers can assign staff to clean records across multiple sources. Smaller ISPs may have one engineer who also handles power failures, procurement, customer escalations and security. A university may not know which former contractor holds an old maintainer. A government network may need a formal letter chain before an engineer can even ask for a correction. If edits depend on informal knowledge, those organisations pay more. If the registry provides a clear, narrow authority process, they can compete with less reliance on personal connections.
Five forms of authority operators often compress into one
The dispute that reaches an upstream rarely arrives in a clean legal form. It arrives as a customer request. The customer may say "we own this prefix" when it means "our service provider told us we may announce it." It may say "AFRINIC has the record" when it means "there is an entry somewhere with our AS." It may say "the holder authorised us" when it has a letter from a person who used to be the holder's network manager. The operator has to translate imprecise language into risk. A good process helps by separating forms of authority that operations often compress.
The first form is registry-holder authority. This is the organisation recognised in the registry record as the holder or assignee of the number resource. It is the starting point for many decisions, but it does not mean the holder's own AS must always originate the prefix. Holders delegate routing all the time. A company may use a carrier's AS. A public agency may outsource infrastructure. A university may let a research network carry traffic. The holder's authority is foundational, but it is not self-executing in BGP.
The second form is origin-AS authority. The AS that originates the prefix must be willing and operationally able to announce it. The origin AS may be a transit provider, a customer, a data centre, a content network, a managed DDoS provider or the holder itself. Its authority may arise from contract, customer relationship or operational delegation. A prefix-origin entry is meaningful only if the underlying relationship exists and if the party publishing it had standing to make that declaration.
The third form is maintainer authority. This is the ability to edit the IRR record. It is narrower than holder authority and origin-AS authority, but it can be more immediately powerful because filters depend on published data. A maintainer can belong to the holder, the origin network, a registry, a contractor or a historical arrangement. Control of it should not be confused with the full right to decide the resource's future.
The fourth form is customer delegation. A customer may have a letter, contract, ticket approval or service order that allows it to route a prefix through a specific provider. Delegation can be broad or narrow, temporary or indefinite, revocable or tied to a paid service. The upstream or IXP needs to know whether it covers the requested origin, prefix length and period. A letter authorising "connectivity services" may not authorise creation of a route object for a different AS three years later.
The fifth form is third-party acceptance. No registry can force every carrier or IXP to accept a route. Operators decide their own filters. They may use AFRINIC-linked data, other IRRs, RPKI, manual exceptions and private trust history. Their acceptance is not title either. It is an operational decision. But enough acceptance creates reliance, and enough rejection can destroy practical usability. That is why the preceding forms of authority must be legible to third parties.
When these forms line up, the system is boring. When they do not, the question is not "who owns the Internet number?" in the abstract. It is "what operational declaration may be published, by whom, with what notice, for what routing purpose, and how can it be corrected if the authority chain is wrong?" That framing keeps the registry's role narrow while still addressing the economic fact that filters turn records into access conditions.
How IRR data becomes filters at carriers and exchanges
RFC 7454 describes the operational logic plainly. Prefix filtering is a core part of BGP operations. IRR information can be used to build, for a given neighbour AS, a list of originated or transited prefixes that may be accepted. A peer supplies an AS and perhaps an AS-SET; tools expand the AS-SET recursively to obtain AS numbers; the operator then looks up associated prefixes and builds permitted prefix and origin lists. The RFC also warns that registries are not always accurate, objects vary over time, source selection is difficult and filters should be refreshed regularly. It recommends proper publication and maintenance of resources in the RIR IRR when available.
This is the bridge from database discipline to market cost. An AFRINIC-linked entry may be consumed by a transit provider's nightly filter build. The provider's router configuration may not know the story behind it. It only knows whether a prefix-origin pair appears in a source the provider has chosen to trust. If the entry is missing, stale or disputed, the customer may be rejected automatically. If it is present but unauthorised, the route may pass automatically. The human decision has been moved upstream into data curation.
Automation is economically necessary. A large carrier cannot manually review every route change. An IXP route server cannot operate safely on informal promises. A managed provider cannot treat every new customer as a bespoke legal file. IRR-derived filters make the market cheaper by turning repeated review into software. But automation also amplifies record errors. A single bad entry can be pulled into many filters. A single deletion can remove acceptance across many peers. A single source-selection rule can privilege one version of a dispute over another without affected parties noticing until traffic fails.
IXPs expose the issue sharply. An exchange route server is not merely a bilateral relationship; it is a shared convenience for many members. If the server accepts bad data, the risk spreads. If it rejects too aggressively, smaller members lose one of the main benefits of joining an exchange: simple multilateral reachability. Many African IXPs exist to reduce dependence on expensive international transit and keep local traffic local. An ambiguity that might be a nuisance in a large European market can be a material cost in a smaller ecosystem where local peering is still being deepened.
Transit providers face a different incentive. They want to sell service, avoid hijacks and reduce support labour. A clean record lets sales and provisioning proceed. A messy one creates internal delay. If the customer's revenue is small, the provider may refuse rather than investigate. That refusal is rational for the provider but costly for the market. The result is a bias in favour of customers whose data is already tidy, whose engineers know the ritual, or whose brand is large enough to justify manual escalation.
The economics of filtering therefore depend on upstream data quality. AFRINIC does not control every operator's routing policy, but it can affect the cost of using AFRINIC-linked records. If creation and correction are clear, operators can rely on the source with fewer exceptions. If authority is opaque, operators either distrust it or use it with hidden risk. Both outcomes are expensive. Distrust pushes networks toward fragmented evidence and bilateral exceptions. Over-trust lets stale or unauthorised entries shape reachability.
AS-SET recursion and the quiet power of delegated lists
Route objects declare prefix-origin pairs, but AS-SETs often decide how those pairs enter filters at scale. A transit customer may tell an upstream to build filters from AS-CUSTOMER. That set may contain the customer's AS, downstream customer ASNs and other AS-SETs. The recursion can continue through resellers and managed networks. The result is a large list of ASNs whose associated prefixes are accepted from the customer path. The process is efficient when the sets are curated. It is risky when they become stale or overbroad.
AS-SET practice belongs in the same discussion because the two instruments interact. If a set includes a downstream ASN and that ASN has route objects for several prefixes, an upstream's filter may accept those prefixes from the customer path. If the downstream relationship ended but the set was not updated, the filter may continue to authorise acceptance. If a reseller adds a customer without sufficient proof, the upstream may accept that customer indirectly. If a route-set includes prefixes by reference to maintainers, maintainer control can shape which prefixes appear in derived lists.
The risk is not only malicious hijack. Overbroad sets create accidental exposure. A managed-service company may include all customer ASNs in a single set for convenience. A data centre may forget to remove a departed tenant. A small ISP may copy an upstream's recommended structure without understanding recursion. A university may rely on a research network that maintains files for many campuses. The filter output looks technical, but it reflects choices about delegation, custody and cleanup.
For AFRINIC's region, recursive lists can impose a development cost. Many operators depend on managed providers because they lack staff to maintain every registry file. That is reasonable. But dependency becomes lock-in if the provider controls the AS-SET and route objects that make the customer's prefixes acceptable. A small ISP leaving a managed transit arrangement may discover that the previous provider controls the records needed by the next provider. The dispute may not concern legal ownership of the prefix. It may concern the practical ability to update the data that filters consume.
Good rules should therefore treat delegated lists as revocable operational instruments. The party that controls an AS-SET should be identifiable. The basis for adding customer ASNs should be documented. There should be a simple path for a resource holder or current origin AS to challenge stale inclusion. There should be notice before deletion where deletion may interrupt current service, unless an urgent security reason justifies faster action. The record should distinguish ordinary customer churn from suspected unauthorised use. That distinction keeps cleanup from becoming a weapon.
Source selection complicates the matter. Operators may query multiple IRRs and prefer some sources over others. A clean AFRINIC-linked entry may be overridden in practice by a stale record elsewhere if the operator's tooling gives that other source priority. Conversely, a stale AFRINIC-linked entry may carry more credibility than a newer third-party file because it appears closer to the resource record. This article does not turn on global IRR fragmentation; the focus is AFRINIC-linked authority and correction. Still, AFRINIC's own data has to be good enough that operators have a reason to prefer it. Authoritative-looking bad data is worse than obviously informal data because it is more likely to be automated into filters.
AS-SET recursion is a multiplier. It multiplies trust when records are clean. It multiplies mistakes when delegation is stale. It expands market access for small networks when managed well. It deepens dependence on intermediaries when correction is hard. AFRINIC cannot treat prefix-origin files as isolated entries if the same acceptance decisions are built through recursive sets.
Stale and conflicting records as hidden taxes
The cost of a bad routing declaration rarely appears as a line item. It appears as a week of delayed provisioning, a lost customer, an engineer's Sunday spent cleaning registry data, an exchange member excluded from a route server, an enterprise migration postponed, a support ticket translated through three organisations, a manual exception that later nobody remembers, or a higher price quoted by a carrier expecting trouble. These costs are real even when traffic eventually flows.
Staleness is the most common tax. A prefix that once originated from AS A now originates from AS B, but the old record remains. Some tools may accept both. Some operators may see a conflict and reject the request. Some may ask for a deletion that the current customer cannot perform because the maintainer belongs to the former provider. The situation may be harmless in intent yet expensive in time. Staleness is particularly costly in markets with staff constraints because the person who knew the original arrangement may have left years earlier.
Duplicates create another cost. If the same prefix appears with different origins, operators must decide whether the situation reflects legitimate multi-origin routing, staged migration, traffic engineering, error or unauthorised use. Multi-origin arrangements do exist, and overly rigid deletion rules can break them. But duplicates without context force outsiders to guess. A registry that permits them should make the reason and authority visible enough for operators to interpret the result.
Conflicts across sources create a subtler cost. An AFRINIC-linked entry may show one origin; a commercial IRR may show another; a route-set may include a prefix by reference; an RPKI ROA may point to a third origin or be absent. The carrier's tooling may be configured to trust one source for some customers and another source for others. The customer does not experience that as elegant pluralism. It experiences arbitrary delay. It is told to fix "IRR" without knowing which file matters.
Unauthorised entries are the most severe case because they externalise risk. A party that can publish a plausible prefix-origin declaration may convince some networks to accept a route before the holder notices. Even if no traffic is stolen, the record can pollute filters, create later cleanup work and reduce confidence in the registry source. In a scarce IPv4 environment, it can also support business models that depend on apparent control. A buyer, lessee, customer or hosting provider may rely on the entry as part of a due-diligence file. When the record is corrected, the reliance chain breaks.
The hidden tax falls especially hard on African networks trying to lower connectivity costs. Local peering and regional transit reduce dependence on long international paths. But peering requires trust. If a small operator's records are messy, a route server may reject it or peers may avoid bilateral sessions. If a data centre's customer prefixes are hard to validate, the data centre may use a more expensive upstream willing to handle exceptions. If public-sector networks cannot clean old files, they may remain tied to incumbent providers longer than procurement policy intended.
The point is not that every stale entry is a scandal. Registries and operators maintain imperfect data everywhere. The point is that the cost of imperfection rises when the records become admission inputs for scarce, valuable connectivity. In that environment, AFRINIC's rulebook is a cost-reduction tool. It lowers the ordinary cost of saying yes to legitimate African routes.
The users who pay when ambiguity persists
Small ISPs pay first because they lack negotiating weight. A large carrier can persuade an upstream to create a temporary exception. A small ISP is more likely to be told to return when its objects are clean. That may sound fair, but it can entrench incumbency. The small ISP may be the network bringing service to a secondary city, a rural area or a specialised business community. If its prefix records are inherited through a reseller, old contractor or customer delegation, it may face weeks of delay before a provider will accept its announcement. A network problem becomes a capital problem: revenue is delayed while fixed costs continue.
Resellers pay differently. Their business depends on assembling connectivity, addresses, hosting and support into a package customers can buy without becoming routing experts. A reseller with poor record discipline becomes a risk to everyone upstream. A reseller subject to arbitrary correction rules becomes commercially fragile. The policy goal should not be to stigmatise reselling. It should be to make delegation visible. If the reseller is authorised to route a customer's prefix through a named AS for a defined purpose, the entry should say enough for operators to understand that fact. If the delegation ends, cleanup should be predictable.
Data centres pay through migration friction. A customer moving into a data centre may bring its own address space and expect the facility to announce it. If the existing entry still names an old transit AS, the data centre cannot simply ask routers to comply. It needs registry alignment, customer authority, maybe a new route object, maybe an updated AS-SET, perhaps a ROA and sometimes deletion of stale data. The data centre's value proposition is speed and reliability. Ambiguous IRR data turns onboarding into an investigation.
Enterprise legacy holders pay because their history is often administratively untidy. A company may have received space under old arrangements, merged several times, outsourced network operations and retained addresses that still support remote access, industrial systems or customer-facing services. The person who can sign a contract may not know the maintainer. The person who knows the maintainer may not be authorised to sign. If correction rules are too rigid, legitimate holders may be unable to modernise records. If the rules are too loose, legacy space becomes a target for opportunistic claims. Proportional evidence is the only workable answer.
Universities pay because academic networks often mix autonomy and dependence. A university may have historical space, a national research network relationship, campus IT departments, outside hosting providers, grant-funded labs and old contacts. A route object may have been created by a former provider for a research project that ended long ago. When the university wants to move traffic to a new provider, it may be told to fix a record nobody remembers. The public interest is not served by making such institutions choose between insecure looseness and impossible paperwork. It is served by documented routes to authority that can handle institutional continuity.
Public-sector networks pay because their authority chains are formal and slow. Ministries, municipalities, health systems and agencies may depend on contractors while retaining public accountability. A routing edit may require a letter, procurement file or named officer. If a contractor controls the maintainer, the agency may have practical dependence on a private intermediary. If the registry insists on only one form of proof, the agency may fail despite legitimate control. If it accepts any letter, it invites abuse. Public networks need evidence categories that recognise statutes, appointments, procurement instruments and continuity obligations without exposing sensitive internal details to the public record.
These groups are not decorative examples. They are the market. AFRINIC's route-object rules either reduce their operating costs or increase them. Scarce-resource debates often focus on large address holders and high-value disputes, but the daily economic value of sound IRR practice is smaller and more widely distributed: fewer tickets, faster peering, cleaner migrations, lower dependence on incumbents and less need for personal intervention.
Institutional stress and the price of correction
AFRINIC's route-object system cannot be analysed as if the institution had enjoyed a quiet decade. Public reporting since 2019 has described serious concerns about IPv4 misappropriation and registry-record abuse. Separate legal disputes placed the registry under intense pressure, including court involvement, asset-freeze episodes, board discontinuity and receivership. In 2025, a board election process was annulled after reported irregularity concerns, including allegations around votes and powers of attorney; a later election restored a board. Subsequent public reporting described continued efforts to rebuild ordinary management and planning while litigation pressure remained.
Those facts should be used conservatively. They do not prove that any particular route object is invalid. They do not mean that AFRINIC staff cannot operate technical services. They do not justify outside actors treating AFRINIC-linked records as guilty until proven innocent. The lesson is narrower: correction paths matter more when institutional confidence has been stressed. If a routing declaration is wrong, who can fix it? If two parties disagree, who receives notice? If a maintainer is compromised or obsolete, how is authority restored? If a court-appointed or board-restored leadership period changes who may act for the registry, how are technical records insulated from institutional turbulence?
The price of correction has three components. The first is time. A prefix that cannot be accepted today may lose a customer today. The second is uncertainty. If parties cannot predict what evidence the registry will accept, they over-collect documents, hire intermediaries or abandon the change. The third is legitimacy. If the losing party cannot see why an entry was created, deleted or preserved, it may move the dispute into public accusation or litigation. Transparent correction rules reduce all three costs.
Stress also changes incentives. When a registry is under criticism, it may avoid decisive corrections for fear of being accused of taking sides. Delay feels safe internally, but it externalises cost to operators. The opposite temptation is to over-correct, using the need to repair old records as justification for broad discretionary control. That may look like strength, but it can turn routine routing edits into political events. AFRINIC needs neither paralysis nor theatrical control. It needs narrow procedures that are boring enough to survive criticism.
The address-misappropriation history is relevant because it shows that record-integrity failures can have large consequences. The right response is not a permanent presumption of bad faith. It is better access control, stronger logs, separation of duties, documented authority checks, escalation for high-risk changes and clear public labels for record status. A registry that has seen record abuse should become more precise, not more vague.
The 2025 election episode is relevant for a similar reason. Allegations around institutional voting do not decide routing authority. But they remind market participants that governance processes can be contested. If legitimacy is being rebuilt, technical correction systems should require less personal trust. A holder should not need to know which faction, officer or insider to call. An IXP should not need to guess whether a deletion request reflects a legitimate correction or an institutional pressure point. The record itself should show the process category, notice status and basis for action.
This matters because routing disputes can become proxies for larger conflicts. A fight over resource use, leasing, customer control, corporate succession or policy compliance may surface as a request to create or delete an entry. The registry should resist both sides' attempts to turn a prefix-origin file into a final ruling on everything. Its question should remain operational: does the evidence justify publishing, maintaining, annotating or removing this declaration for routing purposes?
Deletion is governance, not housekeeping
Creation gets most attention because a new entry can enable reachability. Deletion deserves equal attention because removal can disable acceptance. A stale record should not live forever merely because deletion is risky. But deletion without notice can break real service. The problem is to distinguish cleanup from disruption.
There are several deletion scenarios. The easiest is uncontested cleanup: the holder or current authorised maintainer removes an entry that everyone agrees is obsolete. The second is provider turnover: a former origin AS remains after a customer moves. The third is contested delegation: a customer says it still has authority; the holder says it does not. The fourth is suspected unauthorised creation: the file appears to have been made without standing. The fifth is institutional correction: the registry discovers that historical data or maintainer linkage is wrong. Each scenario needs a different standard.
Provider turnover should usually be notice-based and time-limited. If a record names the old provider as origin, deletion may be necessary. But immediate deletion may harm traffic if migration is staged or if the old provider still carries backup service. The registry or maintainer process should allow a defined cure period, with notices to the holder, origin AS, relevant maintainers and published contacts. If no party objects with evidence, deletion proceeds. If a party objects, the entry may need an annotation or temporary status while the narrow routing question is reviewed.
Suspected unauthorised creation may justify faster action, but the standard should be explicit. The registry should ask whether the entry was created by a maintainer with recognised authority, whether the holder or delegated operator was notified, whether the origin AS confirms the relationship, whether there is a matching or contrary ROA, whether the route is active, and whether immediate deletion would create disproportionate collateral damage. Emergency action may be necessary, but it should be logged, reviewed and time-limited.
Contested delegation is harder because the edit can become leverage in a commercial dispute. A holder may want a reseller cut off. A reseller may say customers depend on it. A provider may claim unpaid invoices. A customer may point to a contract. The registry should not become a debt collector or commercial arbitrator. It should ask only what is necessary for the routing declaration: who can authorise this origin for this prefix now, what evidence supports that claim, what notice has been given, and what transitional period protects innocent users if the current record is withdrawn?
Deletion standards also need to address duplicates. If two entries exist for the same prefix with different origins, the answer is not always to delete one. Multi-origin routing, anycast, staged migration and DDoS mitigation can be legitimate. The issue is whether the reasons are documented and whether the holders and origins have authority. A duplicate without explanation should trigger review; a duplicate with clear, current authority may be acceptable.
Treating deletion as a policy act has one further benefit: it reduces the incentive to create defensive clutter. If operators fear that entries can be deleted unpredictably, they may create duplicates in multiple sources, preserve old AS-SET members or resist cleanup. If deletion is predictable, they have less reason to maintain redundant claims. Clean procedures produce cleaner data.
Evidence rules for a convenience markets rely on
The right evidence model for route objects should be narrow in purpose and broad in accepted proof. Narrow in purpose means the registry asks only whether a route or route6 object should exist as an operational prefix-origin declaration. Broad in proof means different actors can show authority in different ways: registry holder records, corporate authority documents, public-sector instruments, customer letters, provider confirmations, routing history, ticket records, maintainer logs, ROAs, observed BGP, prior entries and court or insolvency documents where relevant.
Evidence should be labelled by distribution. Some facts can be public: the existence of the entry, the origin AS, the maintainer, timestamps, status and perhaps a reason category such as holder-authorised, customer-delegated, provider-confirmed, migration, multi-origin or under-review. Some material should remain non-public: contracts, identity documents, internal tickets, security reports, government letters, account-recovery materials and sensitive customer details. Public transparency does not require dumping private files into a registry. It requires enough visible structure for operators to understand status.
The registry should also distinguish evidence strength from final adjudication. A current holder confirmation plus origin-AS confirmation may be strong enough to create an entry. It does not prove that every commercial relationship behind the route is beyond dispute. A court order may determine who may act for a company, but the registry still needs to map that order to a routing edit. Observed BGP may show that a route is active, but it does not prove that the route is authorised. A ROA may support the origin claim, but RPKI remains a comparator and supporting signal here, not the centre of the decision.
Notice is part of evidence. Before creating an entry that changes the accepted origin for a prefix, the process should notify holder contacts, existing maintainers, the proposed origin AS and any current origin visible in existing objects where feasible. Before deleting, it should notify the same affected parties unless emergency conditions justify immediate action. Notice transforms surprise into process. It gives legitimate parties a chance to cure records and gives the registry a record of who failed to respond.
Cure periods should be calibrated to risk. A routine stale-record cleanup might allow several business days or a defined operational window. A suspected hijack may require immediate temporary suspension followed by rapid review. A public-sector or university continuity case may need more time because authority chains are slower. The cure period should not become a way to keep bad entries alive indefinitely; nor should urgency become a way to bypass review in ordinary commercial disputes.
Audit logs should be tamper-evident and usable. The market does not need to see private documents, but the registry should preserve who requested the change, which maintainer authenticated it, which contacts were notified, which evidence category was accepted, who approved escalation, what changed and when. If AFRINIC later faces criticism or a court request, the log should show process without reconstructing memory from inboxes. For a registry recovering from institutional stress, this kind of record is not bureaucratic luxury. It is legitimacy infrastructure.
The model should avoid one-size-fits-all demands. A small ISP may not have formal board minutes for a routine update. A ministry may require formal letters. A university may prove continuity through old allocations, network records and institutional officer statements. A data centre may have a customer letter and ticket history. A reseller may have customer authorisation and upstream confirmation. The registry should require evidence proportionate to the risk of the action and the harm caused by delay.
Continuity, emergency correction and review under stress
Route-object work must continue when the institution is not calm. AFRINIC's experience shows why. Technical services cannot wait for every governance dispute to settle. Operators need registry data, IRR entries, reverse DNS, contact updates and routing-support services to keep working during litigation, receivership, board transition or management change. The continuity plan should therefore identify route-object operations as a protected technical function, not as a bargaining chip in institutional conflict.
Continuity begins with role separation. The people who administer IRR changes should have clear authority under documented procedures. High-risk changes should require review by more than one role. Emergency changes should be logged and later reviewed. Institutional leadership should set policy, but individual corrections should not depend on personal approval from directors unless a case genuinely raises policy or legal exceptions. The more routine the process, the less edit authority becomes a prize in governance conflict.
Emergency correction is still necessary. If an unauthorised entry is being used to support an active hijack or serious misrouting, waiting through a normal cure period may be irresponsible. But emergency power needs boundaries. It should be limited to routing harm, unauthorised creation, compromised maintainer access, clear holder denial, conflict with stronger current evidence or immediate risk to third parties. It should produce a temporary status, notice to affected parties, a short review clock and a path to restore the entry if the emergency finding was wrong.
Review should be independent enough to matter and narrow enough to be fast. The first review can be internal escalation by staff not involved in the original change. A second review can involve a defined technical or dispute panel for difficult cases. The review should not decide all property, contract or policy issues. It should decide whether the route-object action matched the published standard. If parties need a court or arbitrator for broader rights, the routing process can preserve or annotate operational status while those rights are tested elsewhere.
Appeal language should be careful. If every edit becomes appealable as if it were a resource revocation, the system will freeze. If no edit can be reviewed, edit authority becomes too powerful. The middle ground is operational review: was notice given, was the evidence category appropriate, was emergency action justified, was the cure period reasonable, was the decision logged, and does new evidence require correction? That is enough to discipline the process without converting it into a property court.
Continuity also requires external communication. AFRINIC should publish aggregate metrics: how many route-object creations, deletions, contested corrections, emergency actions and reviews occurred; average time to completion; how many were resolved by notice; how many involved stale maintainers; how many involved public-sector, academic or legacy authority issues. Aggregate reporting reduces rumour without exposing private files. It also lets operators price the reliability of the source. A registry that reports correction performance is easier to trust than one that asks for trust in silence.
During institutional stress, these mechanics do more than keep routers clean. They lower the economic reward for capturing the institution. If edit authority is narrow, logged, reviewable and continuity-protected, then gaining influence over the registry is less useful as a way to affect market access. That is a governance benefit of a technical rule. Narrow procedures can reduce political stakes.
A cheaper market for reachability
The best route-object system is not the one with the most dramatic enforcement language. It is the one that makes ordinary legitimate routing cheap. A small ISP should be able to get a valid prefix accepted without knowing the private habits of every transit provider. A data centre should be able to migrate a customer without begging for exceptions. A university should be able to repair a stale entry without proving its entire institutional history in public. A public agency should be able to delegate routing without surrendering practical control to a contractor. A carrier should be able to build filters without wondering whether the source it uses is a lottery.
For AFRINIC, the design should start with purpose. Route and route6 objects exist to support routing-policy publication and filtering. They should not be treated as legal title, as a substitute for RPKI, as proof of commercial virtue, as a sanction tool for unrelated disputes or as a broad licence to operate. Their power comes from usefulness. Their danger comes from the same place. Because they are useful, markets rely on them. Because markets rely on them, weak rules can turn them into hidden gates.
The design should then define authority. Registry-holder confirmation, origin-AS confirmation, maintainer authentication, customer delegation and third-party acceptance are distinct. The process should say which combinations are sufficient for creation, modification, deletion and emergency correction. It should not pretend that one credential answers every question. It should not let a stale maintainer defeat a current holder. It should not let a holder disrupt a current delegated route without notice where innocent users depend on it. It should not let an origin AS preserve a record after authority ends.
Next comes evidence. Public labels should tell operators whether an entry is ordinary, delegated, multi-origin, under notice, under review or emergency-corrected. Non-public evidence should be preserved without exposing sensitive details. Audit logs should make later reconstruction possible. Cure periods should give real parties time to respond. Deletion should be as disciplined as creation. Emergency action should be possible but bounded.
Finally comes continuity. The system must keep working through legal and institutional turbulence. AFRINIC's board restoration matters, but restored governance will be judged in the market by small operational facts: whether tickets close predictably, whether stale entries can be corrected, whether disputed ones are labelled rather than hidden, whether emergency changes are reviewed, whether operators can see aggregate performance, and whether the registry resists using routing records as proxies for broader institutional fights.
This is not a plea for laxity. Weak route-object practice can support hijacks, stale acceptance, dependence on former providers and a grey economy of apparent authority. Nor is it a plea for registry maximalism. Overbroad control can lock legitimate networks out of reachability, raise the cost of moving providers and convert a technical database into a discretionary market gate. The discipline is narrower: make the right operational declaration easy to publish, make the wrong one easy to challenge, and make every consequential edit visible enough to trust.
The route-server maintainer at the beginning of the story does not need a theory of property. She needs a reliable reason to accept or reject the prefix. The customer does not need a sermon about institutional design. It needs a path to prove authority without losing the week. The holder does not need its scarce resource turned into a hostage of old credentials. The origin AS does not need every routing change litigated. The exchange does not need to absorb registry ambiguity into its own risk. Sound AFRINIC route-object practice serves all of them by lowering the cost of reachability.
The economics are plain. A route object is a modest operational declaration. In a filter-driven market, modest declarations can become admission tickets. If AFRINIC keeps their purpose narrow, authority verifiable, evidence labelled, correction paths fast and review credible, route objects will reduce the cost of African interconnection. If it lets them become stale, opaque or discretionary, they will raise the price of every network that has to explain itself before packets can move.