Summary

  • LACNIC’s 2 November cumulative transfer file has 1,922 rows. Exactly one IPv4 RESOURCE_TRANSFER row has null for both the start and end of the original and transferred ranges: a 7 January 2026 entry from UNIVERSIDAD AUTONOMA DE SAN LUIS POTOSI to DIGY NETWORKS.
  • The row first appears in the 9 January snapshot and remains blank 297 calendar days later. LACNIC’s current policy says its public transfer log records the transferred addresses; this feed names the parties and date but omits the resource that would make the entry independently checkable.

A transfer record with no address is like a deed that names the seller and buyer but leaves the property line empty. LACNIC’s 2 November cumulative JSON offers 1,922 transfer rows. One of them says UNIVERSIDAD AUTONOMA DE SAN LUIS POTOSI transferred a resource to DIGY NETWORKS on 7 January 2026. Both parties are coded MX; both registry fields say LACNIC; the type is RESOURCE_TRANSFER. Then the central field goes quiet. In the ip4nets array, original_set and transfer_set each contain a start address and an end address, both null. The asns and ip6nets arrays are empty. The row identifies no number resource at all.

This is an exact count, not an impression left by a large file. I checked every IPv4 transferred range in the 1,922 rows: this is the only row with a null bound in the current export. It was absent from LACNIC’s 7 January file and 8 January file. It appears in the 9 January file with the same four null address bounds. The 1 November file still has them. The distance from 9 January to 2 November is 297 calendar days. Time has added 333 rows to the file; it has added no address to this one.

The comparison also shows that blank entries are not an inevitable feature of the format. The 9 January file had two null-range rows. One, dated 30 December 2025 with coded organization labels, no longer appears under that source, recipient and date in the 2 November file. The university-to-DIGY row persists. Those snapshots do not disclose why the older row disappeared, so they cannot supply a missing explanation for the surviving one. They do show that the export is capable of changing historical content while leaving this particular gap in place.

LACNIC’s Policy Manual v2.21 gives the public transfer log a specific job. Section 2.3.2.18.4 says it records the transaction date, originating and receiving organizations, transferred addresses and, where relevant, both RIRs. Section 2.3.2.18.1 sets a /24 minimum, and §2.3.2.18.6 forbids a further transfer of the same addresses for one year. The row gives enough to identify the named organizations and date, then withholds the one field needed to test the size or look for a later move of the same block. A prefix query in RDAP needs a prefix; this record offers none.

The absence has a practical cost. A researcher cannot count the transferred addresses. An operator cannot use the log row to check the current holder of the resource. A later transfer of an unknown prefix cannot be matched to this event to test the one-year clock. The public record may be missing a value that exists in LACNIC’s internal case file; a corrected export or a linked case record naming the range would change this finding. Until then, the public file presents a completed transfer with an empty object.