Summary

  • IANA's current number-resource pages expose important public evidence: IPv4 and IPv6 allocation registries with last-updated dates, available CSV, XML, HTML and text formats, AS-number ranges, RIR references, global-policy references and request procedures. That is a strong public record, but it is mostly a current-state registry plus limited dates, not a complete external audit trail.
  • RFC 7020 describes the IANA role as managing the top of the IP-address and AS-number allocation hierarchies, with registration accuracy and uniqueness as core requirements. Those requirements imply more than a visible final table. They require enough history for an outsider to test whether a change was authorized, timely, non-overlapping and consistent with the applicable global policy.
  • The public request procedure identifies evidence that RIRs provide for IPv6, AS-number and recovered IPv4 allocations. Much of that evidence proves eligibility, but the public registry does not expose every request package, validation step, timestamp, approval state, correction, return, replacement or signer identity. Some confidentiality is proper; total dependence on trust is not.
  • A better allocation audit trail would publish signed registry snapshots, cryptographic hashes, dated change records, request-class references, before-and-after states, reversible correction notes and RIR acknowledgment receipts. The goal is not to politicize IANA, but to make the global uniqueness ledger independently reconstructable.

A ledger is not the same as an audit trail

The Internet number-resource system has long relied on the public visibility of registries. Anyone can open the IANA IPv4 address-space registry and see a table of /8 blocks, designations, dates, WHOIS and RDAP references, status values and notes. Anyone can open the IPv6 global unicast address-space registry and see allocated prefixes, RIR designations and dates. Anyone can open the autonomous-system-number registry and see ranges administered by the RIRs. The public nature of these pages is one of the quiet successes of Internet coordination.

Yet a current table and an audit trail are different things. A table says what the registry says now. An audit trail lets an outsider rebuild how it became that way. It answers when a change was requested, who requested it, what eligibility rule applied, what evidence was checked, what the prior state was, what changed, who approved the change, when the public record was updated, whether any later correction altered the entry, and whether the change can be verified against an independent record.

That distinction matters because IANA sits at the top of a hierarchy. Most address and AS-number decisions occur at the RIR level. IANA's direct transaction count may be small compared with regional registries. But the top-level record establishes the pool from which regional authority flows. If a global-pool entry is ambiguous, every later reliance chain inherits that ambiguity. If a top-level allocation date, designation or status changes without visible history, downstream users can see the result but not the proof.

The article's thesis is therefore narrow. It does not claim that IANA's current registries are unreliable. It does not claim that a hidden dispute exists behind a particular entry. It claims that institutional reputation should not be the primary proof method for global pool changes. A system that coordinates globally unique numbers should let outsiders reconstruct its own history with the same seriousness that operators bring to route, certificate and registry data.

The top of the number hierarchy

RFC 7020 is a useful starting point because it states the structure without romanticizing it. The Internet Registry hierarchy is rooted in the IANA address allocation function, which serves the Regional Internet Registries. The RIRs then serve local registries and other customers. The document describes goals that include allocation pool management, hierarchical allocation and registration accuracy. The registration-accuracy goal is especially important: uniqueness ensures that IP addresses and AS numbers are not allocated to more than one party at the same time.

The same RFC also limits the registry role. Whether addresses are actually announced to the Internet and how they are advertised are operational considerations outside the registry system. That boundary is healthy. IANA should not become a routing police force, a market regulator or a judge of every downstream dispute. But the boundary also clarifies what IANA must do well. If IANA's job is the top-level registry, then the evidentiary quality of top-level registry changes is central to the job.

ICANN's bylaws echo the narrowness of the mission. They describe ICANN's role in coordinating the allocation and assignment at the top-most level of IP numbers and AS numbers, providing registration services and open access for global number registries as requested by the IETF and the RIRs, and facilitating global number registry policies by the affected community and agreed related tasks. That is not a general power over every network. It is a registration and coordination function. A narrow function should be easy to audit precisely because its boundaries are limited.

This is why an allocation audit trail is not a demand for new policy power. It is a demand that the public record match the importance of the existing power. If IANA changes the status of a block, allocates an IPv6 prefix, records an AS-number range, accepts a return or changes a named registrant, the event should be externally provable at a level appropriate to the risk. The higher the registry sits, the less acceptable it is to say simply that the final table looks right.

What IANA exposes today

The current public record has several strengths. The IPv4 address-space registry states a last-updated date of 2025-10-10. It lists the registration procedure: allocations to RIRs are made under global policies, while other assignments require IETF Review. It explains that IANA originally managed all IPv4 address space directly and that later parts were allocated to other registries for specific purposes or regional areas. It points to RFC 7249 and offers CSV, XML, HTML and plain-text formats.

The IPv6 global unicast registry also states a last-updated date of 2025-10-10, points to global policy for RIR allocations and IETF Review for other assignments, and explains that assignable global unicast space is the 2000::/3 block, with unlisted space in that block reserved by IANA for future allocation. It too provides CSV, XML, HTML and plain-text formats. The table includes entries where a later allocation incorporates a previous allocation, making visible at least some historical consolidation.

The AS-number registry states a last-updated date of 2026-06-01. It explains that AS numbers are used by routing protocols, that IANA allocates AS numbers to RIRs, and that RIRs further allocate or assign them to network operators under RIR policies. It lists the five RIRs and provides multiple public formats. The number-resources page also links to RIR allocation data, request procedures, global policies and technical documentation.

These are not trivial disclosures. They make the registries usable. They support automated checks. They let researchers and operators compare top-level designations with RIR data. They create a public baseline against which downstream registries can be understood. The available formats are especially important because a registry that can be downloaded and compared is more accountable than a web-only table.

The gap is what the public record does not show. A last-updated date says the registry was changed or republished by that date. It does not show each event that led to the current state. A date column may show an allocation month or day for an entry. It does not necessarily show request receipt, validation, approval, publication, correction or later change. A CSV file lets the public compare two versions if the public preserved both. It does not itself provide a complete version chain.

IPv4 after exhaustion still needs history

The easy answer is that the IANA IPv4 free pool is exhausted, so the audit problem is largely historical. That answer is too shallow. Exhaustion did not end the need to know what happened to IPv4 records. It changed the nature of the evidence. The remaining questions involve recovered space, legacy designations, status clarity, returns, special-purpose entries, RIR references, and the relationship between the IANA table and regional records.

IANA's request procedure for IPv4 recovered space shows why. When an RIR has less than half a /8 in inventory, it should notify IANA to begin allocations to all RIRs from the recovered IPv4 pool. The page says this is a one-time event, made on a schedule rather than in response to separate requests from each RIR, and that only one RIR needs to make the request for allocation to all RIRs to begin. That design makes procedural evidence important. The triggering notice, inventory condition, schedule, formula and allocation result are all part of the public legitimacy of the recovered-pool event.

The public should not need to trust only that the event happened correctly. It should be able to see, at an appropriate level, that the trigger was valid, the schedule was applied, the pool state before and after the distribution was preserved, and each RIR acknowledgment matched the final entries. Sensitive operational correspondence can be protected, but the event proof should remain visible.

Historical IPv4 designations also matter in economic and legal contexts. Legacy blocks, special-purpose blocks and RIR-administered blocks can appear in transfer due diligence, routing-security decisions, lender files, procurement reviews and court records. The IANA table is not the whole proof of a holder's rights, but it is part of the chain that tells readers which registry is responsible for a space. If an entry was corrected or reclassified, the history of that correction can matter. A current table alone is not enough for a disputed chain.

IPv6 entries show the value and limits of visible dates

IPv6 looks cleaner because the public table lists larger prefixes and more recent allocation architecture. The IPv6 global unicast page identifies the 2000::/3 space, states that unlisted space in the block remains reserved by IANA, and lists prefixes allocated to RIRs with WHOIS and RDAP references. Some entries include notes about a later allocation incorporating an earlier one. That is valuable because it alerts the reader that the visible current prefix is not the whole story.

But the same example shows the limit. If a later allocation incorporates a previous one, the reader needs to know the earlier state, the new state, why the consolidation occurred, whether any downstream records changed, and which request or policy condition supported the update. A note is useful; a reconstructable event history is better.

IANA's request procedure for IPv6 requires RIRs seeking additional space to provide utilization and fragmentation summaries or recent allocation data, depending on the eligibility path. That means a public allocation entry rests on underlying evidence. The public does not need every operational detail of an RIR's planning, but it should see the request class, the eligibility rule invoked, the date the request was accepted as complete, the date of approval, the allocation made, and the version of the global policy applied. Otherwise an external reader can see the result but cannot fully test the path.

IPv6 also has a long time horizon. The fact that much of 2000::/3 remains reserved for future allocation means decisions made now can shape the future for decades. A weak historical trail may not hurt when events are few and uncontested. It becomes costly when a later institutional dispute asks why one allocation happened, whether another was delayed, or whether policy criteria were applied consistently across RIRs.

AS numbers make boundary changes visible but not complete

AS numbers are often treated as simpler than addresses because they are identifiers for routing systems rather than address blocks with size and geography. The AS-number registry is still a top-level allocation record. It tells the public which ranges are administered by which RIRs, and it distinguishes reserved or special-use ranges by reference. RIRs then allocate or assign ASNs to network operators under regional policies.

The AS-number request procedure shows the need for evidence. An RIR requesting additional AS numbers because it has assigned or allocated more than eighty percent of its last block must provide a summary of assignments or allocations. If the RIR requests more than one block, it must provide a six-month usage summary. Another path applies when free AS numbers are below two months of need. These are quantitative triggers. Quantitative triggers are auditable only if the evidence, timestamp and calculation are preserved.

The public registry does not need to publish every network operator's request behind the RIR's numbers. It should publish enough top-level evidence to prove that the RIR request belonged to the stated eligibility class. That could mean a request identifier, a class label, a date received, a date validated, a before-and-after pool measure expressed at a safe level, the block assigned, and a signature by the responsible operator. The final AS-number range table is the end of the event, not the event itself.

The consequence of weak evidence can be practical. If a later dispute arises about whether an RIR exhausted a range, whether a range boundary changed, or whether a special-purpose reservation was respected, operators need more than memory. They need a history that can be cited, reproduced and verified. That is the difference between a trusted institution and a trusted record.

Request evidence should not vanish into correspondence

IANA's public number-resource request procedure is unusually clear about what RIRs must provide. It identifies conditions for IPv4 recovered-pool triggering, IPv6 allocation requests, AS-number allocation requests and changes in named registrant. It even names the relevant request mailboxes and says that current and new registrants are contacted to confirm or reject a named-registrant change before the registration is updated.

That is enough to show that allocation decisions are not arbitrary. They are tied to thresholds, summaries, templates and confirmations. But the public record does not expose a full event trail from request to registry update. It does not show a public receipt timestamp, a validation state, an approval signature, a digest of evidence, a publication timestamp, or a public note when a request is rejected, withdrawn, corrected or replaced.

Some of that absence is defensible. RIR requests may include nonpublic planning details. A change in named registrant may involve contact validation that should not reveal personal data or security practice. Security-sensitive communications should not be made public merely to satisfy curiosity. The point is not to publish everything. The point is to publish public proof of the decision while protecting sensitive details.

A simple design would separate evidence from proof. The private evidence package stays with the parties. The public proof record states the request class, the policy version, the validation result, the before-and-after registry state, the publication time, and a cryptographic commitment to the private evidence package. If a serious challenge later arises, an authorized reviewer can compare the private evidence to the public commitment without asking the world to trust an after-the-fact assertion.

This is common sense in other record systems. A public land register may not expose every supporting document in full, but it preserves instrument numbers, dates and prior states. A securities depository may not show every customer file, but settlement events leave records. Internet number resources do not need to copy those fields exactly. They need the same idea: public finality backed by verifiable history.

Last-updated dates are too coarse

The "Last Updated" line on IANA registry pages is useful because it tells readers how current the page is. It is not enough because it is page-level, not event-level. A registry may be republished for a small change, a formatting correction, a reference update, a status change or an allocation. A single date cannot tell which event occurred. It also cannot tell whether several events occurred between public captures.

External reconstruction currently depends heavily on comparison. If a researcher saved yesterday's CSV and today's CSV, the difference reveals a change. If no one saved the prior file, the public may rely on web archives, private mirrors or institutional memory. That is an avoidable weakness. The authoritative registry operator should publish the version history, not force the public to assemble it from chance captures.

Event-level dates would also help distinguish several important moments. Request received is not the same as request complete. Complete is not the same as approved. Approved is not the same as public table updated. Public table updated is not the same as all downstream RIR references aligned. If a dispute concerns delay, each moment matters. If a dispute concerns accuracy, before-and-after states matter. If a dispute concerns authority, signer identity and policy version matter.

The public does not need an overwhelming event feed. Top-level number-resource events are relatively few. That makes a better audit trail more practical, not less. A small number of important events can be documented carefully without creating a burdensome publication layer. The scarcity of events is an argument for precision.

The 2011 exhaustion lesson

The exhaustion of the IANA IPv4 free pool in 2011 is often remembered as a ceremony and a scarcity milestone. It should also be remembered as an audit lesson. The final allocation of IPv4 /8 blocks to the five RIRs was globally visible, policy-driven and institutionally significant. It moved IANA from ordinary fresh IPv4 allocation to a world of recovered space, transfers, regional scarcity and downstream markets.

For that kind of event, public proof matters. The question is not only who received the last blocks. It is which policy governed the distribution, what the pool state was immediately before the event, when the event was executed, how the final entries were recorded, and what evidence would let a later reader rebuild the transition. If the only durable evidence is a table and a press account, the record is weaker than the event deserves.

This is not because 2011 is suspicious. It is because 2011 is foundational. Foundation events should be exceptionally well documented. They become reference points for later policy, finance, litigation and institutional legitimacy. If future recovered-pool events, allocation corrections or registry changes become controversial, the public will look back to the standard set at major transitions. A ceremonial record is not a substitute for an auditable event chain.

The same reasoning applies to future IPv6 and AS-number milestones. IPv6 supply is far larger, but allocation rules still determine when and how large blocks move to regional registries. AS-number exhaustion pressure is different, but request thresholds and range boundaries still matter. The fact that the system works quietly today should be used to strengthen the record before a stress event, not after.

What an externally reconstructable allocation would contain

An externally reconstructable allocation does not need to publish every private message. It needs enough public data for an informed outsider to rebuild the authorized state. The record should start with an event identifier. It should state the resource type: IPv4 recovered pool, IPv6 global unicast, AS-number range, registrant-name change, correction, return or reservation. It should state the applicable policy or review path and the version in force.

The record should show the date and time the request was received, the date and time it became complete, and the date and time of approval. It should identify the requesting RIR or authorized party. It should show the prior registry state and the new registry state. It should record the status change, if any. It should include the public reason category, such as threshold allocation, scheduled recovered-pool distribution, correction, returned space, IETF Review assignment or named-registrant confirmation.

The record should then include proof. At minimum, IANA could publish signed registry snapshots and hashes of each downloadable format. It could publish a change log with before-and-after rows. It could include a hash commitment to the request evidence package, without exposing sensitive material. It could include RIR acknowledgment receipts. It could preserve superseded snapshots in an archive that is easy to navigate.

The final registry table should link back to the relevant event records. A reader viewing an IPv6 prefix or AS-number range would not need to guess from a date column. They could click the event history and see how the entry was created or changed. This is the difference between a registry that states authority and a registry that proves it.

Signing is not a cure by itself

Cryptographic signatures can help, but they do not solve the whole problem. A signed bad record is still bad. A signed current table proves that the table was issued by the signer, not that the allocation was eligible, timely or correctly classified. Signatures must be attached to a richer event record.

The right role for signing is integrity and non-repudiation. It should prove that a given snapshot existed at a given time, that it has not been altered, and that the operator responsible for the registry issued it. Hashes should let outsiders compare downloaded CSV, XML, HTML and text formats and confirm that they represent the same state. Time-stamping should prevent a later reconstruction from quietly changing the order of events.

But human governance facts still matter. Which policy applied? Which RIR requested the allocation? Which evidence threshold was met? Was an entry corrected because of a clerical error or because a prior allocation was reversed? Did an event supersede a prior event? A signature cannot answer these questions unless the signed material contains them.

This is why the audit trail should be designed as an evidentiary record, not a security decoration. It should be understandable by operators, courts, auditors, registry staff, researchers and affected communities. The proof should make the human decision visible, not hide it behind a technical seal.

The RIR link must be part of the chain

IANA is only the top of the hierarchy. An allocation becomes operationally meaningful when the receiving RIR records and administers it. A reconstructable top-level trail should therefore link IANA events to RIR acknowledgments and downstream public references. The aim is not to make IANA responsible for every RIR assignment. It is to show that the handoff occurred and that the two public records agree at the boundary.

The IANA tables already include WHOIS and RDAP references for many entries. That is valuable. A stronger audit trail would record the handoff event: IANA allocated or updated the top-level entry; the RIR acknowledged receipt; the RIR public service reflected the range; any known lag or correction was noted. If later records diverge, the boundary event tells readers where to start.

This matters in failure scenarios. If an RIR faces governance stress, litigation, sanctions pressure, technical outage or continuity risk, operators may need to prove the top-level origin of a resource while regional services are impaired. A signed IANA event chain would not replace the RIR. It would provide a stable anchor for continuity, migration, escrow, receiver action or temporary service arrangements.

It also matters in ordinary finance. IPv4 transfer diligence, lending files, lease reviews, cloud bring-your-own-address checks and public-sector procurement may all ask whether a resource's registry path is clean. The IANA top-level record is usually only one layer, but a weak first layer weakens every later certificate of comfort. An auditable IANA trail would reduce the premium paid for uncertainty.

Corrections are as important as allocations

Allocation events attract attention because they move resources into a regional pool. Corrections are quieter and sometimes more important. A correction may adjust a date, status, designation, contact reference, RDAP endpoint, note or prior entry relationship. Some corrections are harmless formatting repairs. Others can affect how a third party understands authority, continuity, legacy status or available review paths.

The public registry should distinguish correction types. A spelling repair is not the same as a status change. A new RDAP endpoint is not the same as a change in the responsible registry. A note that incorporates a prior allocation is not the same as a new allocation. If all corrections appear only as a new final table, readers cannot determine whether a change altered substance or presentation.

Correction transparency also protects the registry operator. If a mistake is found and fixed, the best answer is not silence. It is a visible correction event with the old value, new value, reason category and date. That record shows that the registry can repair errors without pretending the error never existed. It also lets downstream users update their own records accurately. In a global coordination function, quiet correction may create more suspicion than the original error.

Returns need the same treatment. If a block or range returns to a pool, the event should show who returned it, under what rule, when the registry state changed, whether the returned resource entered a recovered pool or reserved state, and what later event moved it again. Returned resources can carry reputation, route history, geolocation memory and commercial expectation. The top-level record should not imply that a returned prefix is history-free.

This is especially important for IPv4. Scarcity gives every recovered or reclassified block economic weight. A returned block may later be allocated under a global policy. A buyer, lender, public agency or network operator may ask whether the block's path is clean. The answer should not depend on reconstructing old web captures. It should be visible from the authoritative event trail.

Public formats should carry identical proof

IANA's provision of CSV, XML, HTML and plain-text formats is a major strength. Different users need different formats. A researcher may prefer CSV, a tool may prefer XML, a human reader may use HTML, and an operator may archive text. The proof layer should treat these formats as different expressions of the same authoritative state.

That means each published version should carry or be accompanied by a digest set. The public should be able to verify that the CSV, XML and text downloads all represent the same registry version. If one format is regenerated later for formatting reasons, the event record should say whether the registry state changed. This avoids a common ambiguity in public data systems: did the file change because a record changed, or because the presentation changed?

A version identifier would help. Instead of relying only on a last-updated date, each registry could have a monotonically increasing version. Each event would identify the prior version and the new version. Snapshots would be preserved. Users could cite "IPv6 global unicast registry version X" rather than a downloaded file with no durable event identity. Courts, auditors and operators would have a cleaner reference.

The same proof should be available for notes and references. If an RFC reference changes, if a global-policy link is updated, or if an RIR's RDAP URL changes, that may not be an allocation event. It is still part of the public registry. A versioned note history would prevent reference maintenance from being confused with resource movement.

Web archives are not a governance system

In practice, researchers often reconstruct registry history through saved files, mirrors and public web archives. Those tools are useful, but they should not be the primary audit mechanism for a global identifier ledger. They are incomplete by design. They capture at intervals chosen by third parties. They may miss short-lived states. They may preserve a page after a presentation change but not after a data change, or the reverse. They may be blocked, delayed or unavailable.

An authoritative registry should not outsource its memory to chance. If the public depends on private mirrors to know what the registry said last month, the registry has underproduced evidence. If a dispute depends on whether a web archive captured the right moment, the public record is too weak. A global coordination function should preserve its own history in a way that is deliberate, durable and easy to cite.

This is not a criticism of independent archiving. Independent archives are valuable checks on official history. They can prove that a public record existed, reveal later edits, and preserve material after institutional failures. But their value is greatest when they can be compared with an official version chain. The official record should say what the registry intended to publish. Independent captures can then verify that publication occurred and was not later rewritten.

The difference is subtle but important. Without an official event trail, outside archives become the main evidence. With an official event trail, outside archives become corroboration. A mature system should want corroboration, not dependence.

Audit trails reduce institutional politics

Some people hear "audit trail" and assume a demand for political oversight. In number resources, the opposite is true. A stronger evidentiary record can reduce politics because it narrows the facts. When the record clearly shows the policy version, request class, timestamps, prior state, new state and responsible parties, fewer disputes need to be fought through institutional reputation.

This is especially important when institutions are under stress. If an RIR is challenged in court, placed under unusual governance pressure, affected by sanctions or criticized by members, every ambiguous record can become a political symbol. A clean IANA event trail gives all sides a shared baseline. It does not decide the regional dispute. It says what the top-level record did and did not do.

The same is true for future competition or portability proposals. If registry services become more portable or if new service providers seek recognition by evidence rather than patronage, the global ledger must distinguish duplicate allocation from service migration. That distinction requires history. A current-state table can show that a range is administered by a registry. It cannot by itself prove the sequence of notices, acknowledgments and state transitions that made a migration safe. An event trail could.

Audit trails also protect IANA and PTI. When a decision is questioned, the operator can point to the public event record instead of relying on general confidence. The more the record proves, the less the operator must argue. That is a healthy posture for a narrow technical coordination role.

Courts, auditors and operators ask different questions

A court may ask whether a particular entry existed on a particular date. An auditor may ask whether a registry change followed an approved control. An operator may ask whether a prefix's responsible registry is clear enough for routing-security, reverse-DNS or abuse-contact reliance. A lender may ask whether a resource's chain is clean enough to support a covenant or collateral analysis. A public-sector buyer may ask whether the supplier's addressing plan rests on stable registry evidence.

These questions are related but not identical. A current IANA table helps all of them, but it answers none completely. The court needs time-specific evidence. The auditor needs control evidence. The operator needs boundary clarity. The lender needs defect history. The public buyer needs continuity proof. A rich event trail serves all these audiences without making any one of them the center of the system.

The benefit is cumulative. Once the top-level event trail exists, RIRs can point to it in their own records. Operators can cite it in diligence files. Researchers can use it to separate top-level allocation events from downstream registration behavior. Policy reviewers can see how often certain request classes arise. Future accountability reviews can measure correction rates and publication timing without asking staff to reconstruct history manually.

The result is a more usable public record. Not a larger bureaucracy, not a politicized allocation desk, and not a public release of sensitive request files. Just a registry that lets its own history be inspected.

Accountability without operational overload

One concern is that a richer audit trail could slow a service that has been reliable precisely because it is simple. That risk should be taken seriously. IANA should not be forced into a heavy approval ritual for every publication. The design should match the size and frequency of top-level events. Because direct top-level number-resource allocations are relatively limited, a stronger record can be generated as part of the normal publication act.

The most efficient path is automation plus review. When an authorized change is approved, the registry publication system can create a before-and-after record, hash the downloadable formats, timestamp the event, attach the policy reference and preserve the superseded snapshot. Staff would not write a long narrative each time. They would verify the event type and reason code. Sensitive supporting material would remain protected while its hash commitment is recorded.

A second concern is that public proof could create new attack surfaces. The answer is selective disclosure. The public does not need credentials, private contact details, security controls or confidential request documents. It needs the public facts of authority and state change. A well-designed proof record can reveal less private information than ad hoc later disclosure because it separates safe event facts from protected evidence.

A third concern is that too much precision could invite litigation over harmless timing differences. That is possible, but opacity is worse. When important records lack timestamps, disputes become broader and more speculative. A precise audit trail narrows disputes. It tells parties what happened and when. If a delay was harmless, the record can show that too.

Source limits and conservative claims

The sources reviewed for this article show the structure of the registry system, the public IANA registry pages, request procedures, last-updated dates and global-policy references. They do not provide a hidden history of every allocation. They do not establish that a particular current entry is wrong. They do not prove that IANA has lost evidence or that any RIR received an improper allocation. The critique is about verifiability, not a claim of known misconduct.

The public sources also do not reveal every private request, eligibility calculation, confirmation or correction. That absence may reflect appropriate confidentiality, ordinary operational practice, or simply the public format chosen for the registries. The article therefore avoids exact statistics about undisclosed requests, rejection rates, correction counts or time-to-publication. Where the public record gives exact last-updated dates or stated procedures, those are used. Where the public record does not provide a denominator, no denominator is invented.

The source limit strengthens the central point. If an outsider cannot reconstruct the event chain from public materials, the system should not answer by asking the outsider to trust that everything is fine. It should answer by publishing a better event chain.

Conclusion

IANA's number-resource registries are valuable because they are public, structured and globally recognized. They are not enough because public current state is not the same as reconstructable history. The stronger standard is simple: every global pool change should leave a public proof record showing what changed, when it changed, why it was authorized and how the before-and-after states can be verified.

That standard would not turn IANA into a political authority. It would do the opposite. It would keep IANA's role narrow by making the narrow role provable. A global uniqueness ledger should not depend on reputation when it can publish proof.

Sources reviewed