Summary

  • RIPE NCC’s 2001 changeover separated the old RIPE-181 update path from the new RPSL path in stages. The transition began on 23 April, changed its default update channel on 14 May and ended on 15 October, according to contemporaneous notices and the organization’s annual report.
  • Public records connect Andrei Robachevsky to the work as RIPE NCC Database Group Manager: an August 2000 message invited users to assess new query behavior, and a signed April 2001 notice described the first completed migration phase.
  • Converting a registry object changes how the database represents and accepts it. It does not, on its own, establish ownership of an address block, prove that a route is being announced or show where packets travel.

A cutover with two doors

The May notice is unusually concrete. From 14 May, auto-dbm would accept RPSL only. The auto-181 mail robot would still accept RIPE-181 and convert it, but that bridge had an announced closing date: 15 October. A third path, auto-rpsl, also accepted RPSL. The message applied the same distinction to the test database.

For an operator, the practical question was therefore not simply “Has the database migrated?” It was which update format a particular sender could use at a particular address, and how long a compatibility path would remain. A script that kept submitting a legacy object to the old endpoint faced a different rule from one deliberately routed through the conversion service. The notice does not tell us how many scripts needed repair, or whether every user experienced disruption. It does show that the institution made the migration legible as a set of dated interfaces rather than an invisible database replacement.

A message from 23 April records the first phase already in operation: the new database version was running and the existing objects had been automatically converted to RPSL and loaded. Yet “converted” did not mean “all paths changed.” The auto-dbm service temporarily accepted RIPE-181 with restrictions: empty and misspelled attributes were disallowed, PGP authentication was not supported on that path, and RPSL authorization rules still applied. auto-rpsl accepted RPSL directly. The boundary between old syntax and new policy was operational, not merely cosmetic.

Query design is part of the migration

Robachevsky’s August 2000 message as Database Group Manager described changes to the v3 query interface and asked the database community for feedback. The examples mattered because they distinguished questions that can look similar in a terminal. An exact-match query returned an object matching the supplied range; a less-specific query returned the smallest larger range that fully contained it. A primary-key-only option reduced the returned fields. A source query exposed database and mirroring information, including serial ranges. Inverse queries could find objects by contact attributes.

Those options do not certify that a record is true. They affect what a client asks and sees. A narrower response can be easier to process but may hide context unless the client asks for it. A less-specific result answers a different question from an exact match. Mirroring metadata says something about a source’s replication interface and available serials; it is not a measurement of the global routing table. A migration that changes query semantics can therefore alter monitoring and maintenance tools even when the underlying resource record appears familiar.

The draft minutes for RIPE 38 describe Robachevsky’s 20-minute migration presentation as asking who would be affected and listing query users, update users, scripts and near-real-time mirrors alongside RPSL, access control, database format and the mirroring protocol. The minutes are explicitly marked draft, so they establish what the draft record says about the meeting—not proof that every proposed date was met. The later announcements and annual report supply stronger evidence for the completed transition.

Compatibility has a cost and an owner

The six-month window distributed the adaptation burden. The registry operated conversion code and communicated dates; maintainers had to decide whether to revise their update generators; mirror operators needed to check the changed format and protocol; database clients had to distinguish exact from less-specific results. The public sources do not quantify those costs or name every affected implementation. They do, however, make the control points visible: accepted syntax, authorization checks, endpoint names and a deadline.

That visibility is a useful measure of stewardship. A registry that serves as a shared reference system owes users more than a successful data load. It must explain which representation is accepted, which authentication rule applies, what a query returns, how mirrors can keep up and when a fallback disappears. Those are service obligations. They do not confer ownership of the number resources described by the records or political authority over every organization that relies on them.

RFC 2622 is helpful precisely because it draws another boundary. It defines RPSL as a language for expressing routing policy and describes the maintainer object and authorization of database updates. Its listed authors are Alaettinoglu, Villamizar, Gerich, Kessens, Meyer, Bates, Karrenberg and Terpstra; Robachevsky is not among them. His documented part in the migration should not be turned into a claim that he invented RPSL or authored that RFC.

A registry object is not a live route

A registration database, an Internet Routing Registry policy object and a BGP observation answer different questions. A converted object can show what the RIPE Database stored after conversion. A routing-policy object expresses intended policy in a registry language. A route collector may show that a BGP announcement was observed at a particular vantage point and time. None substitutes for the others. A database record cannot by itself prove present reachability, packet delivery, legal title or that the stored policy is being followed by every router.

This distinction protects both users and the institution. If an old record remains after an organization changes, the remedy is a data-quality and authorization question. If a route disappears, that is a routing observation requiring its own sources. If a party disputes its authority to register or update an object, a format conversion does not resolve the dispute. The migration’s significance is more modest and more durable: it made the registry’s interfaces and obligations visible while keeping the record system separate from the underlying resource and network.

What can be attributed to Robachevsky

The public record supports a bounded profile. In August 2000 Robachevsky signed a database working-group message with the title Database Group Manager and laid out v3 query changes. In April 2001 he signed a notice describing the first phase as complete, including the automatic conversion and the restricted RIPE-181 update route. The draft RIPE 38 minutes identify him as the presenter for a planned migration overview. These sources show a manager communicating a transition and engaging users; they do not prove that he personally wrote the conversion software, decided every policy detail or reviewed each record.

That limit is part of the story. Operating the infrastructure that stores a public record creates responsibility for predictable access and accountable changes. It does not make the operator the owner of what is recorded. In the RIPE Database migration, the evidence is strongest where dates, interfaces and rules were published—and stops where the archive does not show individual costs, universal adoption or the current state of any route.

Sources