Summary
- RIPEstat routing history shows broad, sustained visibility for AFRINIC's core AS33764 prefixes from 2021 through 2025, while one IPv4 prefix, 196.192.141.0/24, had a marked visibility decline and a period with no interval returned above the chosen ten-peer threshold in 2025.
- That record is evidence of network reachability from RIPE RIS collectors, not proof that member requests, transfers, reverse DNS, RPKI issuance, registry accuracy, incident response, or decision authority remained normal during receivership.
- A credible continuity claim needs a service-by-service evidence chain: externally observed reachability, RPKI publication state, synthetic checks, change records, ticket ageing, authority for high-risk decisions, incidents, recovery results, and explicit limits on what each measure can establish.
Continuity is a claim with several possible meanings
AFRINIC's public story through years of litigation and missing corporate organs has rested partly on continuity. The Number Resource Organization praised staff in September 2023 for maintaining operations and services. AFRINIC's consolidated annual report for 2022 to 2024, published in 2026, says the institution sustained high service availability while governance and litigation pressures continued. Public services such as RDAP and the RPKI repository remain identifiable today. These are meaningful observations. They are not all the same proposition.
"The organisation continued" can mean that employees were paid and the company remained legally present. "The network remained reachable" can mean that prefixes originated by AFRINIC's autonomous system were visible to route collectors. "The service answered" can mean that a web, RDAP, Whois, DNS, or repository endpoint responded to a probe. "Registry operations continued" can mean that staff authenticated members, applied policy, approved changes, maintained accurate records, issued or revoked cryptographic entities, handled disputes, and recovered incidents.
"Normal operations" may be intended to encompass all of them.
The BGP record can test only part of that hierarchy. It can show whether routes to AFRINIC-originated address space were observed, from which origin, across how many collector peers, and over what intervals. It cannot see a support queue. It cannot know whether a member's authorised representative was verified correctly. It cannot prove that a transfer was lawful, an RPKI request was processed promptly, or a service returned complete and current data. It cannot identify the corporate authority behind a technical change.
This analysis therefore does not use routing data as a courtroom verdict on AFRINIC. It uses the data to reduce one area of uncertainty and to expose how much remains. The result is neither "nothing failed" nor "continuity was fictional." It is a narrower conclusion: substantial public network reachability persisted, a notable exception requires explanation, and the institution's broader continuity claim remains under-evidenced because the necessary operational measures have not been published in a joined-up form.
The test begins with AFRINIC's own network
AFRINIC operates AS33764 for its network services. A routing-history query for that autonomous system is an appropriate first test because it avoids guessing which websites or service names represent the institution. RIPEstat's Routing History service derives timelines from the RIPE NCC Routing Information Service, whose collectors receive BGP routes from participating peers. The interface can report the prefixes originated by an AS, the intervals in which those routes were visible, the average number of peers observing them, and a normalised visibility measure.
For this review, the period was 1 January 2021 through 31 December 2025. The query used a minimum of ten peers and requested normalised visibility. That setting removes very weakly observed intervals but also creates a limit: the absence of a returned interval does not prove that no route existed anywhere. It means the data did not return an interval meeting the selected collector-peer threshold. The reported timelines are aggregates with roughly twelve-day granularity, not one observation per day.
This distinction is important because governance arguments often overstate the precision of public routing archives. A graph can look continuous while averaging across changes inside the interval. A decline can reflect collector composition, upstream relationships, route policy, maintenance, or an actual service-network event. A BGP archive generally cannot supply the cause by itself. It can identify a time and prefix for investigation.
The appropriate question is thus: did the public routing record broadly agree with a claim that AFRINIC's own network remained reachable, and where did it diverge? It is not: can BGP certify all registry services? The data supports the first inquiry and is structurally incapable of answering the second.
Four core IPv4 routes show broad persistence
Four AFRINIC-originated IPv4 service prefixes in the returned history had the same broad timeline: 196.2.3.0/24, 196.192.114.0/23, 196.192.114.0/24, and 196.216.2.0/23. From 9 January 2021 to 10 May 2023, the average full-peer count reported for their intervals was about 319, with normalised visibility of 0.99. From 11 May to 3 June 2023, the average full-peer count was about 258 and visibility 0.94. From 4 June 2023 into January 2026, the returned timeline showed an average of about 377 full peers and visibility of 0.98.
Those figures are strong evidence that important AFRINIC-originated routes did not disappear from the collector view during the main governance crisis. The period includes the loss of a functional board, the September 2023 appointment of the Official Receiver, later litigation over authority, and the 2025 change of receiver and election process. Nothing in the four timelines suggests a broad withdrawal of the institution's core IPv4 reachability at those moments.
The finding deserves weight because reachability is not trivial. Registry services cannot be used remotely if routes to their infrastructure vanish. Persistent BGP visibility indicates that staff, transit arrangements, addressing, and network operations continued to produce externally observable results despite corporate paralysis.
It deserves equally clear limits. The four prefixes are not four proofs of complete service. Multiple services may share infrastructure, and one service may depend on systems outside those prefixes. A route can be visible while the application behind it is broken, slow, stale, misconfigured, or available only intermittently. Collector visibility does not equal end-user reachability from every African network. The repeated timeline also suggests that related prefixes may share routing policy; it should not be interpreted as four independent operational tests.
The evidence therefore supports substantial routing persistence, not the adjective "normal" without qualification.
One prefix records a material 2025 anomaly
The history for 196.192.141.0/24 followed the broad pattern until March 2025 and then diverged. It showed normalised visibility around 0.98 through 12 March. From 13 to 24 March, the returned average full-peer count fell to about 207 and visibility to 0.61. From 25 March to 17 April, the average fell to about 61 and visibility to 0.17. The query returned no qualifying interval from 18 April to 3 August at the selected minimum of ten peers. From 4 August through 26 October, the prefix returned with about 338 average full peers and visibility of 0.98.
This is not a marginal fluctuation. It is an externally observable change that should be reconciled with any broad statement of sustained high availability. Yet the responsible conclusion stops before assigning cause. The routing archive does not say whether the prefix hosted a critical service during the period, whether traffic moved to another prefix, whether the route was intentionally withdrawn, whether an upstream changed policy, whether there was maintenance, or whether collector coverage affected the result. It also does not justify calling every day in the gap an outage.
The anomaly creates a disclosure test. AFRINIC should be able to identify the services, if any, then associated with the prefix; the operational change or incident that explains the visibility pattern; whether users were affected; what monitoring detected; and what corrective action followed. If no public-facing critical service depended on it, that fact would narrow the significance. If a service moved safely, the route history may reflect a controlled migration rather than failure.
Without that context, outside analysts face an avoidable choice between exaggeration and dismissal. The prefix should not be used to claim that AFRINIC collapsed. It also should not be omitted from an account of continuity. Good institutional reporting would join the external signal to the internal event record and state what the routing data can and cannot prove.
IPv6 history needs architectural interpretation
The IPv6 record illustrates another danger in reading BGP mechanically. AFRINIC's returned history includes several /48 prefixes, such as 2001:42d0::/48, 2001:42d0:1::/48, 2001:42d0:2::/48, and 2001:43f8:d00::/48. Their timelines generally show broad visibility across the reviewed years, with normalised values commonly in the low 0.8s to low 0.9s and continuing through 2025. Some began in September 2022, while older aggregate forms ceased appearing as the more-specific structure emerged.
A naive chart could label the disappearance of an older aggregate as a loss of service. A better interpretation first checks whether more-specific announcements replaced it. Prefix-length changes can reflect routing architecture, traffic engineering, provider policy, or service migration. They are not automatically outages. The persistent /48 visibility makes a broad IPv6 disappearance less plausible, but it still does not identify application quality.
The lower normalised visibility relative to the core IPv4 routes also needs restraint. IPv6 collector peer coverage and routing policy differ from IPv4. A value below the IPv4 result does not by itself show that users experienced proportionately worse access. It is useful as a consistent time series and for detecting abrupt changes, not as a universal user-experience score.
This is why continuity reporting should preserve the relationship between route and service. An institution should know which public service names resolve to which addresses, which prefixes originate them, what failover exists, and when that mapping changes. External analysts can then assess a route anomaly without guessing. AFRINIC need not expose sensitive topology. It can publish service-level incident context and controlled migration notices that make the BGP record intelligible.
The IPv6 evidence supports continuity in the limited sense of persistent observed announcements. It also demonstrates that route inventories must be time-aware. Comparing a fixed list of today's prefixes against earlier years can manufacture failures or miss architectural transitions.
RPKI history supplies a different, still partial signal
BGP reachability and RPKI are related but distinct. BGP collectors observe announcements. RPKI relying parties retrieve signed entities that allow Route Origin Validation. AFRINIC operates a trust anchor and repository for its region, and its public documentation identifies rsync and HTTPS publication paths. A functioning RPKI service therefore requires more than a route to the repository: certificates, manifests, certificate revocation lists, and ROAs must be correctly generated, published, refreshed, and retrievable.
RIPEstat's RPKI History interface provides a public time series derived from archived validated ROA payload data. For AS33764 and IPv4, the returned monthly history for 2021 through 2025 generally shows three VRPs in every month for which samples are present. That stability is consistent with continued publication of the AS's own IPv4 route authorisations. It is evidence against a simple story in which AFRINIC's RPKI presence vanished throughout the governance crisis.
The archive is incomplete as an availability measure. Some 2025 months have no returned samples in this query, while other months do. Missing April, June, or July entries cannot be assigned automatically to an AFRINIC repository outage. The interface reports archived data products and their sampling, not a direct probe log of the authoritative repository. Conversely, three stable VRPs do not prove that member-requested ROA creations, modifications, or revocations were processed correctly or on time. They concern one origin AS and the payloads available to the archive.
This distinction prevents a false equivalence. A stable public trust entity for AFRINIC's own routes can coexist with delays elsewhere in the hosted certification service. A repository can be reachable while serving stale entities. It can recover quickly while leaving a transient validator impact. A member can be unable to authenticate to the management interface even though existing ROAs continue to validate.
RPKI continuity needs its own evidence, not a label borrowed from BGP.
A route is not a registry decision
The deepest limit in the BGP comparison is institutional. AFRINIC allocates and registers resources; network operators originate routes under their own commercial and technical relationships. An accurate registry can contain resources that are not routed. A visible route can exist even when registration data is disputed. The registry's authority and the routing system's observation intersect, but neither fully validates the other.
Suppose a member requests a change in its organisation record. The route may remain stable while the request waits for identity review. Suppose a transfer is contested. Existing announcements can continue while legal and policy questions remain unresolved. Suppose an RPKI change is delayed. BGP may show the same route, while networks performing origin validation classify it differently. Suppose reverse DNS delegation is wrong. Packets may still flow even as services depending on reverse resolution fail.
The receiver context increases this separation. A technically correct change can still lack clear corporate authority. A legally authorised instruction can still be technically unsafe. A route collector cannot see either defect. It reports the route it receives, not the governance process behind it.
For this reason, AFRINIC's continuity claim should be disaggregated into at least four dimensions: availability, integrity, timeliness, and authority. Availability asks whether a service could be reached. Integrity asks whether its data and outputs were correct and protected from unauthorised change. Timeliness asks whether requests and updates were completed within defined periods. Authority asks whether the person approving a consequential action had a lawful, policy-consistent mandate.
BGP offers useful evidence mainly for one component of availability. RPKI archives can add evidence about public cryptographic outputs. Neither resolves integrity, timeliness, or authority across the registry. A statement that treats them as a complete verdict gives the most visible technical signal more institutional meaning than it can carry.
RDAP proves a service exists, not its historical quality
AFRINIC documents a public RDAP endpoint at https://rdap.afrinic.net/rdap. A successful query can show that the endpoint responds at that moment and returns structured registration data for a resource. Repeated probes from independent locations could measure availability, response time, TLS health, and basic data consistency. Those are valuable tests because they move beyond the route layer to the application.
A present-day response does not reconstruct 2021 to 2025. Nor does it prove the completeness or correctness of every record. A monitor that queries only a known healthy resource may miss problems affecting other entity types, search functions, rate limits, referrals, or updates. A service can return HTTP success with stale or malformed content. A probe from one network can miss reachability problems in another region.
Historical continuity therefore requires contemporaneous observation. If AFRINIC maintained internal availability monitors, their design matters: probe locations, frequency, success criteria, maintenance exclusions, failure aggregation, retention, and reviewer independence. If it relies on vendor monitoring, changes to that vendor or configuration must be recorded. Summary percentages should name the service and measurement window rather than combining unrelated endpoints into one availability figure.
External monitors add credibility because the institution cannot rewrite their observations after an incident. Internal telemetry adds diagnostic detail. Neither is sufficient alone. The best evidence joins them: an external failure at a specified time, an internal incident record, the affected dependency, a restoration event, and a post-incident test.
RDAP also demonstrates the difference between public read service and member write capability. Anyone may query public data. Only authorised processes can alter the underlying registry. A continuity report that measures queries but omits request processing proves that readers could see records, not that members could maintain them.
Tickets reveal whether continuity was being rationed
In a prolonged governance crisis, service degradation may appear first as delay rather than outage. Staff can keep endpoints online while deferring requests that are legally complex, high risk, or dependent on absent executives. That may be prudent. It is still a material condition that should be measured.
A useful ticket record would show arrivals, closures, median and tail age, reopened cases, escalations, and unresolved inventory by service. It should separate routine contact updates from allocations, transfers, membership changes, reverse DNS, RPKI, billing, abuse reports, and appeals. Aggregate averages can conceal a small group of very old consequential requests, so age bands and the oldest unresolved items matter. Confidential case details can remain protected.
Reason codes are especially important under receivership. A request may wait because evidence from the member is incomplete, because policy criteria are not met, because technical work is pending, because a court order constrains action, because authority is disputed, or because no qualified approver is available. Those causes have different implications. Only the last two point directly to governance incapacity, but all affect the member.
The record should include denied and deferred requests, not merely completed ones. Otherwise, "all processed requests met target" can remain true because difficult cases were moved outside the measured population. Changes to ticket categories or closure rules must be disclosed so comparisons remain valid.
This evidence would also protect staff. A visible backlog can show that caution was required rather than negligent. It can identify where a receiver or court direction was needed. It can show that routine services continued even while exceptional cases paused. Without it, outsiders are left to infer institutional performance from route graphs, anecdotes, and broad annual-report language.
Continuity is not only whether the door stayed open. It is who was served, how long they waited, and which decisions the institution could no longer make.
Change records connect service availability to institutional action
Routing and application probes observe outcomes. Change records explain institutional action. For each material service, AFRINIC should be able to identify deployments, configuration changes, certificate renewals, DNS changes, key ceremonies, vendor transitions, capacity events, and emergency interventions over the reviewed period. The record need not disclose exploitable details; it should permit correlation with external signals.
The 196.192.141.0/24 anomaly is a clear example. A change record could show whether a service migrated before the decline, whether a route policy was intentionally altered, whether an upstream issue was opened, and whether restoration in August followed a planned event. If no correlated action exists, an incident investigation would be appropriate. The BGP data supplies the time window; the institution supplies operational meaning.
Change governance also tests authority. During the absence of a board and chief executive, who approved high-risk modifications? Which classes of change could staff perform under standing authority? Which required the Official Receiver or later receiver? Were emergency changes reviewed? Were vendor personnel given temporary access? A service that remained available through uncontrolled interventions presents a different risk from one preserved under a documented approval path.
Useful measures include change success and rollback rates, emergency-change counts, unauthorised or unrecorded changes found by review, time between execution and verification, and aged temporary exceptions. A zero count should be supported by a defined review rather than assumed from the absence of reported incidents.
Continuity reporting often isolates technical reliability from governance. AFRINIC's case shows why they must be joined. Corporate paralysis changes the instruction chain. The technical service can look stable while decision accountability erodes. A change record that includes both the operational reviewer and lawful approver can show whether the institution preserved not just availability, but controlled administration.
RPKI needs freshness and validator diversity, not only presence
For RPKI, the minimum public assurance should go beyond whether repository URLs answer. Relying parties care whether the publication point contains valid, current, internally consistent entities that can be retrieved across the methods they use. An institution can measure this without exposing private keys or member records.
The evidence should include publication freshness, manifest and revocation-list consistency, successful retrieval from independent networks, validation results from more than one implementation, and incident history. If AFRINIC operates a hosted portal for members, it should separately measure authentication, ROA request processing, issuance latency, revocation latency, and failed or disputed requests. Existing-entity continuity and change-service continuity are different products.
Validator diversity matters because a repository defect may affect implementations differently. An independent monitor using several relying-party clients can identify malformed entities, transport differences, or cache behaviour. It should record the repository serial or comparable state so investigators can determine whether different locations saw the same publication. Maintenance windows and emergency key or certificate events should be disclosed at an appropriate level.
The AS33764 RPKI history finding provides a useful baseline: where monthly samples exist, the returned IPv4 VRP count remained three. A richer institutional record could explain whether those entities were refreshed normally, whether any repository incidents occurred, and how quickly all publication channels recovered. It could also disclose aggregate member-service performance without revealing who changed a ROA.
Such reporting would prevent two symmetrical errors. Critics could not infer a complete RPKI outage from a missing third-party sample. AFRINIC could not infer full service continuity from the survival of its own authorisations. Freshness, consistency, retrieval, issuance, and governance would each have an observable place.
IRR, Whois, DNS, and member portals need separate tests
The public Internet often treats "AFRINIC service" as a single thing. Operationally, the institution exposes a set of services with different data, dependencies, users, and failure modes. An IRR database can be reachable while updates fail. Whois and RDAP can diverge. Reverse DNS can answer while a delegation-change request is delayed. A member portal can authenticate some users while rejecting others because authority records are stale. Billing can continue while technical requests pause.
Each service therefore needs a small, explicit test set. For public registry data, tests can cover reachability, response validity, freshness, consistency between interfaces, and authoritative serial or update state. For DNS, they can cover delegation correctness, authoritative reachability, DNSSEC where applicable, and propagation after approved changes. For the IRR, they can cover query behaviour, authenticated updates, entity consistency, and abuse controls. For member systems, they can cover authentication, role changes, request submission, status visibility, and recovery.
The tests should be run from multiple networks, including locations within the service region. A global monitor concentrated in Europe or North America may miss African connectivity problems. Conversely, a single test from Mauritius cannot establish reachability across the region. Results should identify probe coverage and known blind spots.
Service dependencies should also be declared. If RDAP and Whois share the same underlying database, their simultaneous success is not independent evidence of database integrity. If the portal and RPKI interface share identity infrastructure, an authentication failure may affect both. If failover uses the same provider or control plane, it may not survive the incident for which it was designed.
This service map is the missing middle between BGP and institutional reassurance. Routes show the outer transport path. Tickets and changes show administrative capability. Service-specific probes show whether the applications between them actually worked.
Incident disclosure should match consequence, not publicity
Continuity claims are often weakened by a narrow definition of incident. If only events that caused a public outage are counted, integrity failures, near misses, unauthorised access, backlog crises, and failed changes disappear. For a registry, those events can be as important as website downtime.
A material-incident policy should cover loss of service, significant degradation, data-integrity concerns, unauthorised or uncertain changes, key or credential compromise, failed recovery, incorrect resource publication, and a governance failure that prevents a required decision. The threshold should reflect consequence to resource holders and dependent networks, not whether social media noticed.
Public disclosure can be staged. An initial notice states the affected service, start time, known impact, and safe mitigation. A later review explains cause, duration, affected control, corrective action, and evidence limits. Security-sensitive details can be withheld with a reason. The incident record should still retain them for independent review.
The relationship to BGP is practical. A route-visibility anomaly may trigger an incident search. An incident may have no BGP effect because it occurs in the application or governance layer. Both should be possible in the evidence model. Treating route stability as a substitute for incident disclosure would systematically miss the failures most specific to a registry.
AFRINIC's prolonged legal conflict raises another reporting risk: every operational problem may be interpreted as a political weapon. That is an argument for more disciplined evidence, not less. Defined thresholds and consistent post-incident reports reduce the scope for selective disclosure. They also allow the institution to say when an external anomaly did not affect a critical service and show why.
A credible continuity record includes the events that challenge the claim. It does not require an impossible assertion that nothing went wrong.
The evidence must identify who was authorised to decide
Service measures can show performance while missing a constitutional defect. From June 2022 AFRINIC lacked a quorate board, and receiver communications say it had no directors from September 2023 until the later restoration process. The Official Receiver and successor receiver provided temporary corporate authority under court orders and Mauritius law. The operational question is how that authority reached each class of decision.
Routine staff actions may have continued under established delegation. High-impact actions may have required receiver approval. Some matters may have been deferred or taken to court. A continuity report should state the authority model over time: which functions staff could approve, which required a named office-holder, which were frozen, and when the model changed.
This is not a demand to publish every personnel decision. It is an integrity measure. If a transfer, revocation, credential reset, or vendor commitment occurred, later reviewers need to know that the decision came from a lawful role and received technical review. If action was delayed because no clear authority existed, that fact belongs in service reporting rather than being hidden as an ordinary backlog.
The authority record also helps interpret otherwise puzzling measures. A low emergency-change count may reflect strong planning, or it may reflect an inability to approve changes. A stable queue may conceal rejection at intake. A high completion volume may include only low-risk tasks. Connecting measures to delegated authority prevents flattering but empty statistics.
AFRINIC's public continuity narrative has largely praised the resilience of staff. That praise may be deserved. Institutional evidence should protect staff from being used as a substitute for governance. Employees can sustain systems; they should not have to carry unrecorded corporate authority because the public report prefers a simple story.
A continuity ledger should join claims to evidence
AFRINIC could make its continuity case stronger with a public ledger organised by service and period. The ledger would not expose member cases or security secrets. It would link each material claim to the type of evidence that can support it and state the evidence's limit.
For BGP, it would list relevant service prefixes, intentional routing changes, material anomalies, and external collector coverage. For public applications, it would provide measured availability, response validity, probe distribution, and incidents. For RPKI, it would cover repository freshness, retrieval, validation, and member change performance. For registry administration, it would report request volumes, age bands, reasons for delay, high-risk decisions, and appeals. For authority, it would identify the governing delegation model and changes to it. For resilience, it would report recovery tests and unresolved risks.
The ledger should preserve time. A retrospective annual statement cannot fully replace records created during the period. Monitoring methods change, service names move, and memory becomes selective. If a measure was not collected at the time, the report should say so rather than reconstructing a false precision. External archives can fill some gaps, but their limitations should remain visible.
Confidence should be attached to propositions rather than the whole institution. "Core IPv4 prefixes were broadly visible in RIS during 2021-2025" can carry high confidence under the stated query. "Every AFRINIC service was continuously available" cannot. "AS33764 had three observed IPv4 VRPs in reported monthly samples" is supportable. "All hosted RPKI changes were timely" is not established by that record.
This method would turn continuity from a branding term into an auditable set of claims. It would also allow disagreement to focus on evidence rather than institutional allegiance.
What the current record supports
The public evidence supports several positive findings. AFRINIC's core AS33764 IPv4 routes had broad collector visibility through the reviewed crisis period. Several IPv6 service prefixes also remained broadly visible. Public RPKI history for the organisation's own IPv4 origin shows a stable count of three validated payloads in the months for which samples were returned. AFRINIC continues to document public RDAP and RPKI services. These observations are consistent with substantial technical persistence.
The evidence also supports a material qualification. The 196.192.141.0/24 route experienced a pronounced decline in observed visibility in March and April 2025, followed by a period with no interval returned above the selected threshold and later recovery. Without service mapping and an incident explanation, the effect is unresolved. The correct description is an anomaly, not a proven total outage or an irrelevant chart artefact.
The record does not establish historical availability for every service, complete regional reachability, request-processing timeliness, correctness of registry decisions, RPKI issuance performance for members, absence of unauthorised change, or clear approval authority for every high-risk action. Public routing and RPKI archives are not designed to answer all of those questions.
That boundary does not invalidate AFRINIC's continuity claim. It narrows it to what can presently be verified. The institution appears to have preserved important elements of public network and trust-service presence under severe governance stress. The public record is not sufficient to call the entire operating state normal.
This distinction should matter to both critics and defenders. Critics should not use one route anomaly to erase years of sustained reachability. Defenders should not use sustained reachability to erase the institutional functions BGP cannot see.
The better standard is continuity with integrity
Availability is the visible edge of resilience. For an Internet registry, the deeper standard is continuity with integrity: services remain reachable; data remains correct; authorised changes can be made; unauthorised changes are prevented; requests are handled within known limits; incidents are recovered; and every consequential decision has a legitimate authority and evidence trail.
Under that standard, the BGP record becomes one instrument in a larger panel. It can verify that the transport path broadly persisted and identify anomalies worth investigation. RPKI archives can verify aspects of public cryptographic state. Synthetic probes can test applications. Ticket and change records can test administrative capacity. Incident and recovery evidence can test resilience. Authority records can test governance. No single measure is allowed to impersonate the whole.
AFRINIC has an opportunity to publish this joined account because the difficult period is now long enough to assess. The consolidated 2022-2024 annual report offers an institutional claim of high availability. A service-by-service supplement could show how that conclusion was measured, disclose gaps, reconcile the 2025 route anomaly, and distinguish preserved outputs from unresolved governance constraints. The result would be stronger than another assurance that dedicated staff kept working.
The comparison with BGP does not produce a dramatic verdict. It produces something more useful. It confirms that core routes were remarkably persistent. It finds a specific exception. It shows where public cryptographic history adds support and where it does not. And it demonstrates that the most important continuity questions lie beyond the reach of the routing table.
The institution responsible for registration should apply the same discipline to its own claims that it expects from resource records: identify the entity, state the time, preserve the evidence, disclose the authority, and do not assign a field more meaning than it can hold.
Sources and method
The institutional continuity claims are taken from the Number Resource Organization's September 2023 statement and AFRINIC's consolidated annual report page for 2022-2024. They establish what the organisations said, not independent proof of service quality.
Routing findings use the RIPEstat Routing History method and a query for AS33764 covering 2021 through 2025 with normalised visibility and a ten-peer minimum. The service derives observations from RIPE RIS collectors; its intervals are not daily measurements, its peers are not the entire Internet, and it does not identify application state or event cause. RPKI observations use the RIPEstat RPKI History method, whose archived samples are not a complete authoritative-repository uptime log.
Service boundaries are checked against AFRINIC's public documentation for RDAP, the RPKI trust anchor, and RPKI repository access. Those pages show intended services and endpoints; they do not establish historical availability, request latency, or the legality and correctness of individual changes.