Available Databases

An update is the submission of information for entry into, or removal from, a database. As the database records are RPSL objects, these updates create, modify or delete one or more objects.

There are several databases that can be updated and a number of ways in which you can submit an update. Each of the databases described below have a fully operating software system built around them. This includes the core database software as well as the external interfaces, for example email service, Webupdates, Syncupdates and RESTful API.

5.1 RIPE Database

The RIPE Database is the authoritative database and is sometimes referred to as the ‘live' or ‘production' database or service. This holds all the current data for all the existing RPSL objects. It also holds historical data for deleted objects and previous versions of the current objects. Most operational services and tools are built around this database.

5.2 TEST Database

This database is provided as an operational service to all users. It allows anyone to try out updates or changes to their data. New users can set up any data they like and practise making updates and doing queries.

The TEST Database works in exactly the same way as the production service, for most of its operations. Some rules are relaxed and some mntner objects have the password included in a “remarks:” attribute. This allows users to create objects in this TEST Database that only the RIPE NCC can create in the production database. If you want to copy your allocation and build a copy of your network you can do this in the TEST Database.

Each evening, at midnight (Amsterdam time) the whole contents of this database are deleted. It is then reset with a standard, basic set of objects. This prevents anyone from creating large objects and blocking off huge pieces of the address space. So if you are testing anything that will take you more than a day to complete, you need to build your objects in a text file that you can either paste into a syncupdates web page or submit as an email update. Make sure you order them in the text file to match how you actually created them. If you get the order wrong, some may fail when you re-submit them. You can add to the text file as you create or change data in the database. Then the next day, you can recreate the whole set of objects to the point you reached previously and continue with your tests.

5.3 Release Candidate Database (RC)

The release procedure for new software requires the new system to be available in a test environment for a period of time. This test environment is built around the RC Database. This is a fully functioning service where all your client software can be tested against the new software release. The RC database is dummified to remove personal data. Also all mntner object authorisation tokens are set to a password using the mntner object name. This allows more flexibility, as you can create objects that are only created by the RIPE NCC in the production version, Other than that, it is an exact copy of the production database, with the copy made at some point in time close to the software release date.

5.4 Experimental Databases

There are times when some features need to be deployed in a proof of concept mode. It may be an idea that some community users have suggested but does not yet have widespread support. A proof of concept software release can be made and a temporary database, similar to the RC Database, set up to demonstrate the feature. That database will be a full copy of the production database with dummified personal data and modified mntner object credentials.

Similar projects may be set up when a major data migration project is proposed. A test run may be carried out on a database copy and this may be made available to the community to review what their data looks like after the change.

This documentation is in draft status.
Please send any feedback or feature requests to ripe-dbm@ripe.net.