Summary

  • RIPE NCC's 20:00 UTC transfer-table update added three 2 November IPv4 rows, 2,304 addresses in all, from INTERNATIONAL HOSTING SOLUTIONS LLP to Iryna Oliinyk.
  • The exact current RDAP objects date their registration to 14:29:10–11 UTC. A complete transfer-table capture at 16:41 lacked all three rows, exposing the gap between a registry event clock and its public table.

The addresses were in the registry's records; the transfer table needed another edition. RIPE NCC's current within-region allocation transfer file lists three 2 November POLICY transfers from INTERNATIONAL HOSTING SOLUTIONS LLP to Iryna Oliinyk: 185.248.192.0/22, 194.15.112.0/22 and 194.26.18.0/24. Two blocks of 1,024 addresses and one of 256 make 2,304. All three rows say PERMANENT and carry the same source and recipient.

An earlier complete capture of that very file, made at 16:41 UTC, contained 43,852 rows and none of these three. Its SHA-256 is ed0104f4cc2a424832e2a85403464bb81ec5ff436f18db59db6415b2bda9a6a4. The version last modified by RIPE NCC at 20:00:03 UTC contained 43,855 rows, SHA-256 d07266b3d0d36337ad85747a7661ad83ffcf63a537f237a368859a9d63032257. A row-by-row comparison finds precisely those three additions and no deletions. The table did not quietly revise the older rows to produce the difference.

The three exact current RDAP objects supply the earlier clock. 185.248.192.0/22 and 194.15.112.0/22 both carry registration and last-changed events at 14:29:10 UTC. 194.26.18.0/24 says 14:29:11. Each exact range is active and references ORG-IO80-RIPE as a registrant, matching the transfer table's recipient. The event timestamp is the record's clock; the later file modification is the table's clock. At 16:41, the public table was still three lines short.

RIPE's separate ASN table records two numbers moving between the same named parties on 2 November. That ASN name-versus-holder issue has its own Theo March report. The IPv4 question is different: how much can a reader infer from a transfer table between its refreshes? On this date, an answer based solely on the 16:41 edition would have missed three ranges and 2,304 addresses that the 20:00 edition later included.

The transfer file gives a date, not a per-row publication time. A row-level publication timestamp or change log would pin down when each line first became visible. Until then, the defensible sequence is exact: RDAP records carry 14:29 events, the complete 16:41 transfer snapshot lacks the rows, and the file modified at 20:00 includes them.