Summary

  • RIPE-81 made policy-to-configuration translation explicit; a 1993 report documents a limited prototype, not broad adoption.
  • The 1994 agreement separated router description from configuration; the 1995 Informational RFC did not prove universal enforcement.

RIPE-81 began with a practical problem: Europe had no single coordinated routing core, and networks expressed their transit policies in different ways. The February 1993 proposal was to represent those policies as structured objects in the RIPE database. The representation should be clear, general, checkable and applicable. It should also translate in both directions between policy and router configuration files.

Translation was a design goal, not remote control. A database could store a declared policy; a program could turn it into Cisco or gated access-list syntax; an operator could review and load the output. The configuration actually on a router, BGP announcements, and traffic observations would then be separate evidence. An entry could not prove that any later state matched it.

Tony Bates’s message of 22 February 1993 gives a rare implementation detail. He said ripe-81 was still awaiting ratification. A basic prototype generated Cisco and gated access lists, while a “very small” NCC pilot used a pseudo-database. He also mentioned early trace and configurator tools. This supports the existence of a prototype and a limited trial, not broad deployment. It would be wrong to claim that no generation existed; it would also be wrong to turn this pilot into an adoption census.

RIPE 18’s meeting record places the work beside the Merit Routing Registry, route servers and the NSFNET transition. It lists four AS numbers in the Merit registry and a beta Routing Policy Server. That is a meeting snapshot, not a count of networks using the system or proof that a registry controlled the transition.

Routing policy describes relationships: which neighbors carry traffic, which destinations are preferred, and under what conditions. A shared format makes declarations easier to exchange and compare. The operator still knows its contracts, devices and failure costs. Common syntax can reduce coordination work without transferring local decisions to whoever maintains the database.

The boundary became explicit in discussion of the inet-rtr object. It was meant to describe router interfaces and peering relationships for tools such as PRIDE. September 1994 minutes record agreement that this object should not configure routers. That rule concerned the descriptive router object; it did not erase the earlier report that other policy data could generate access lists. Generation and application are different acts.

RIPE-181 revised the earlier representation. RFC 1786, published in March 1995, described aut-num and route objects, incorporated RIPE and Merit contributions, and discussed tools to compare recorded policy with observed routing. The RFC was Informational. Its statement that undescribed routes should never be routed is a design norm, not proof of universal enforcement. A route object is not a BGP announcement; a generated file is not a loaded configuration; and a loaded configuration alone does not show what packets did.

RIPE’s current database history retrospectively dates the Internet Routing Registry to 1995 and describes its later separation from address-allocation records. That chronology cannot fill the gap between a prototype and common practice. The historical point is narrower: RIPE made policy more portable and gave tools structured inputs, while its working group marked a boundary around device configuration. Heng Lu’s “The Policy Mirror” is an interpretive lens for asking what a record represents and what it can compel; it is not evidence about RIPE. The records could help draft a filter. Operators still decided whether to apply it.

Sources