Summary

  • LACNIC’s public debtor-resource table contains 32 unique records published on 7 September 2026: 15 IPv4 blocks and 17 IPv6 blocks, each showing 6 December as the revocation date.
  • Those 32 rows are not a published count of organizations, invoices, notices or recovery cases. A privacy-safe case identifier would make the process auditable without naming a holder or exposing a bill.

At first glance, the new entry in LACNIC’s recovery table looks like a large, clean number: 32 resources entered together on 7 September, and all 32 point to 6 December. The symmetry invites a quick conclusion. Thirty-two rows, perhaps, means thirty-two debtors.

The table does not say that.

Its columns are narrower: type of resource, resource, date of publication and date of revocation. The September cohort contains 15 IPv4 blocks and 17 IPv6 blocks. It contains no organization column, no invoice identifier and no recovery-case number. One organization may hold one resource or several. One invoice may cover one resource set or a different one. None of those groupings can be recovered from the public rows alone.

That is not a complaint about withheld identities. A public debt register should not become a directory of private billing files. It is a question about the unit being counted. LACNIC’s surrounding page calls the section “Organizations currently undergoing the resource recovery process”; the embedded table records resources. Both can be useful, but they are not interchangeable populations.

One visible clock, several hidden states

LACNIC’s payment page provides a simple schedule for non-payment. Resources enter the recovery process 35 days after an invoice due date and are revoked 125 days after it. The difference is 90 days. The September table also places 90 days between 7 September and 6 December.

The policy is broader than a billing calendar. Section 7 of the current Policy Manual lists possible grounds including non-payment, unused or unannounced resources where announcement is mandatory, missing reverse-resolution records, stale registration information, unauthorized transfers, repeated policy breaches, document fraud, and organizations that have disappeared or stopped responding. LACNIC’s recovery page directs holders to billing for membership-payment failures and to hostmaster for breaches of resource-use policy.

The public table therefore shows a deadline, not the private path that produced it. It does not reveal the invoice date, the evidence class, the attempts to make contact or the decision that moved a particular resource into publication. Nor should readers infer those facts from a prefix.

The date is not yet a completed revocation. LACNIC says the holder can rectify the situation while the resource is published. The policy says that, in all other cases, authoritative-name-server records are removed after two months; if the problem remains unresolved after three months, the resource is recovered and holder records are removed. It also allows the Board, after staff assessment, to extend the period for essential strategic infrastructure or exceptional conditions such as natural disaster or political instability. A separate public table records resources after recovery.

These are different states: published for possible recovery, cured, extended, withdrawn, recovered and later corrected. The four-column list exposes the first state and a scheduled date. It does not preserve the rest as a visible history.

The missing join

A small privacy-safe addition would solve most of the accounting problem. Each recovery matter could receive an opaque public identifier. That identifier would bind the affected resource set to the publication date, the applicable rule or broad cause class, the current clock state and a short outcome such as open, rectified, extended, withdrawn or recovered. A correction would append a new event rather than silently rewriting the old one.

The identifier need not expose an organization name, contact attempt, invoice number, amount, document, allegation or security-sensitive reason. Its purpose is more modest: to let a reader count cases as cases and resources as resources.

That distinction matters in both directions. Treating 32 resources as 32 cases can exaggerate the number of organizations affected. Treating one visible date cohort as one case can understate it. Prefix size does not repair the ambiguity: an IPv4 /20 and an IPv6 /48 are different resource units, not weights for organizational or financial severity.

LACNIC’s list already provides the hard part—a public, dated warning attached to exact number resources. A case-level join would make the warning easier to interpret without making it more intrusive. Until then, the defensible headline is the one the table can support: 32 resources are listed. The number of cases is not published.

Sources