RIPE Database Release 1.67.4
Expected Date of Deployment
Test Database: 18 July 2013
Production Database: 8 August 2013
New and Improved Features
Diff of Object Revisions
For history queries, this release enables users to see in detail what changes were made between two versions of an object in the RIPE Database. For updates, we have re-introduced the feature that previously existed in the legacy code. The implementation is more general and now applies to all updates by default, without the need for any specified keywords. There will be a change to the emailed notifications for updates that modify an object. These will now show the changes followed by the complete new object. Currently, they show the complete old object, followed by the new object.
To read more about the diff functionality, please see the RIPE Labs article.
IMPORTANT! This feature has an impact on existing functionality. Notifications will now include a diff showing what changed and the new object instead of the old and new objects.
GRS and --resource
We have improved the way the GRS data is imported. We will compare all resources from the RIRs with their published extended delegated stats files and only import those resources. This also applies to the RIPE GRS Database, which is therefore different to the RIPE Database.
A new query option "--resource" has been introduced as a shortcut to getting basic information on any global Internet resource.
For more information on this, see the RIPE Labs article.
This feature is not possible to test on the TEST Database as the GRS service is only available via the production database service.
IMPORTANT! This feature has an impact on GRS functionality. Only operational data is loaded into each GRS database, but not placeholders or administrative data objects.
With this release we've also made improvements to the REST API. We have reimplemented the service and merged it into the main code base. This will change some of the API calls slightly. Generally, it is not good to change an API once it is fully in production. But this was released as a beta service and this is the first full review since the original development. With experience and feedback from users, what we are now going to deploy will be a stable, full production service. As there are some changes, the new implementation will be deployed and running in parallel to the old one up until the next release. This allows time to verify your software against the new release.
The current implementation of the REST API service will not change in this release and will still be available at the existing url: apps.db.ripe.net/whois/
Important! The old beta service and the url apps.db.ripe.net/whois will be dropped with the subsequent release (1.68.x). From then, the REST API service will only be available at rest.db.ripe.net.
The main changes include:
- CRUD commands /(create|update|modify|delete) do not require a source parameter
- CRUD services are only available with https:// - using http:// will result in 404
- lookup commands /(lookup|search) still require a source parameter
- lookup commands /(version|versions) do not require a source parameter
- /grs-search and /grs-lookup have been dropped; use /search and /lookup instead
- /search supports filtering by tags
- long query option flags are supported in /search
- any unknown URL will return a 404 error (prev: redirect to www.ripe.net)
- JSON is handled in both response and request
The new service is accessed by these new URLs:
- http(s)://rest.db.ripe.net/ is the base URL for the live database for both queries and updates
- http(s)://rest-test.db.ripe.net/ is the base URL for TEST DB for both queries and updates
Documentation is available on both TEST DB and live services and is accessed from the base URLs. This is mostly generated by the software and will always match the release.
IMPORTANT! Moving from beta service to stable production service has resulted in some functionality changes. Please verify that your implementation still works.
IPv6 Index Clean-up
Previous bugs in the software meant it was possible to create objects where the address did not match the prefix. This causes operational problems. We will clean up all these inet6num and route6 objects with the next release. For example, fdf8:f53b:82e4::/32 will be converted to fdf8:f53b::/32.
IMPORTANT! If you rely on a specific textual representation of the INET6NUM or ROUTE6 primary keys, you should adjust your scripts.
This feature will allow you to test your updates with the live database. For a single object update, all business rule, syntax and authentication checks will be performed, but NO change will be made to the database.
Pending Route Authorisation
This is an alternative and simplified way of authorising route object creation. Two separate updates for a single route/route6 object are treated as one create request.