RIPE transfer to Tencom keeps ILBITTEL-MNT on exact /23

RIPE Changed the Holder. Ilbit Stayed on the Edit Lock.

Why it matters

A Russian /23 moved from Ilbit Telecom Ltd. to Tencom Ltd. on RIPE NCC's transfer ledger. The exact address card names Tencom, but its `mnt-by` still includes `ILBITTEL-MNT`. The new holder's organisation card uses a different maintainer. The receipt and the edit path are separate records.

Theo March3 November 2026Reading Time 2 minLast update: 3 November 2026

RIPE NCC records Tencom as the /23 recipient while the exact inetnum retains ILBITTEL-MNT as a named maintainer.

Summary

RIPE NCC's assigned-address transfer table dates the 512-address 91.233.188.0/23 move from Ilbit Telecom Ltd. to Tencom Ltd. to 3 November.
The exact ASSIGNED PI inetnum points to Tencom's organisation but still lists ILBITTEL-MNT and RIPE-NCC-END-MNT under mnt-by.

The name on the receipt changed; the lock on the address card kept an old name. RIPE's 3 November transfer row says Ilbit Telecom Ltd. sent 91.233.188.0/23, 512 IPv4 addresses, to Tencom Ltd. Both sides are marked RU; the transfer is POLICY and PERMANENT. The exact range object was created at 14:21:17 UTC that day. It is ASSIGNED PI, with org: ORG-TECN1-RIPE and two mnt-by entries: ILBITTEL-MNT and RIPE-NCC-END-MNT.

Tencom's organisation object confirms the recipient name. It was created the previous evening and uses vissado-mnt as its own maintainer. The network card and the holder card therefore advertise different maintenance paths. The separate ILBITTEL-MNT object dates to 2011, was last changed in June 2025 and still gives an ilbit.ru domain for its update-failure and notification addresses. No address from that mailbox needs to be printed to see the mismatch.

The distinction has a mechanical meaning. RIPE's authorisation rules say the maintainers listed in mnt-by protect changes to the object; where several are listed, a valid credential for any one can satisfy the authorisation check. Its notification guide says upd-to receives notice of failed authorisation attempts for protected objects. The public records identify the named routes for updates and alerts. They do not identify who presently holds the SSO credential behind ILBITTEL-MNT; an account-authority audit would settle that.