RIPE Database

There is an extensive project underway to make our services easier to use and work together seamlessly, so that they provide the most value to you. Over the last couple of months we have been working very hard on the RIPE Database. We have made some fundamental changes to the web interface, which we are pleased to introduce to you.

At the RIPE 69 meeting, the use of the RIPE Database as an Internet Routing Registry (IRR) and it's relationship with other IRRs was raised. But there hasn't been much discussion on options for the way forward since. Based on what was said at RIPE 69 and the few comments made on the mailing list, I feel that some issues might need further clarification and discussion.

The RIPE Database Working Group requested the RIPE NCC to replace the “changed:” attribute in the RIPE Database with “created:” and “last-modified:”. Following discussions at RIPE 69, the RIPE NCC has met with the working group chairs and finalised an implementation plan consisting of three phases: 1) introduce the new attributes “created:” and “last-modified:”, 2) make the "changed:" attribute optional, 3) deprecate the "changed:" attribute. Please find the details in this article.

The RIPE NCC is currently revising the RIPE Database documentation as requested by the community at recent RIPE Meetings. The goal is to produce one complete and accurate set of documentation that fully describes all aspects of the RIPE Database. The documentation will be a collection of small documents that will be published as soon as they become available. Over the coming months, you can expect to see a steady supply of these new documents. The current documentation will be available until the new set is complete.

The IPv6 Analyser is a toolset that offers our members a visual insight into all the allocations, aggregations and assignments they have made. It was announced a few weeks ago and we're seeing LIRs starting to use it. Please find below some more details about this tool.

The aim of the policy Abuse Contact Management in the RIPE Database (RIPE document ripe-563), was to make available an abuse contact for all resources maintained by the RIPE NCC. The RIPE NCC proposed an implementation plan that was accepted. During the deployment there has been some feedback on the practicalities of the implementation. At RIPE 67 the RIPE NCC agreed to think about this feedback and present some further options.

The recently accepted RIPE Policy Proposal 2012-07, “RIPE NCC Services to Legacy Internet Resource Holders” defines a framework for the RIPE NCC to offer registry services to legacy Internet resource holders. This article details how we propose to implement this framework.

This article describes the implementation of policy 2012-07 as it relates to the RIPE Database.

The recently accepted policy proposal 2012-08, "Publication of Sponsoring LIR for Independent Resources", requires the RIPE NCC to publish an identifying link between each independent Internet number resource in the RIPE Database and the sponsoring organisation (where such a link exists). This article outlines how we propose to implement this, and asks for your feedback.

Availability of 16-bit AS Numbers is getting low. We have many in reserve that have been returned but they need 'cleaning'. You can help with this.

Creating route objects just got a whole lot easier! Forget about hassle across organisations. Now you can submit the object with the passwords you have, and if it needs more, we will sort it out. The software will decide who else needs to authorise it and contact them. When they send in their passwords, we will match them up and create the object. Then we let everyone know the result – whether it’s a success or failure. Can it get any easier than this?

Have you ever wanted to test an update to the RIPE Database, without actually changing anything in the database? Well now you can "dry-run" it - see what will happen without changing anything.

The RIPE Database operates as an open, public database for routing information. This information is not restricted to the RIPE NCC service region or to resources administered by the RIPE NCC.

The RIPE NCC has changed the way data is imported for this service. This allows us to present a more complete Global Resource Service (GRS) for all Internet resources. This article outlines the GRS service including the recent changes. None of these changes have any impact on the standard RIPE Database query service.

Users often like to see the difference between two versions of an object. Some objects can be long and complex. It is not easy to look at two text versions and see what changed. We are proposing to implement a 'diff' function for the RIPE Database.

The RIPE NCC proposes improvements to the algorithm used for removing personal data from the bulk provisioning of RIPE Database data.

We often get asked about the status of our different services and projects, and while we frequently publish updates on RIPE Labs, we now have a new tool that makes it easier to stay informed. We're happy to announce the RIPE NCC Roadmap, where you can get an overview of all the latest developments and future plans for these services in one place. This prototype, which is hosted on RIPE Labs, will be further developed as we receive your feedback, so please let us know what you think!

This is an automated process to replace the manual intervention frequently asked of the RIPE NCC to overcome the short comings of the authentication system with regard to proper management of resources by the registered resource holders.

In addition to the actual data presented in a RIPE Database object, there is additional data, not directly related to the information contained within an object but still valuable from an operational point of view. The RIPE NCC is proposing a method to optionally display this metadata alongside the actual object. This will make maintenance of objects easier and will improve the overall quality of data in the RIPE Database.

Objects are created in the RIPE Database and are updated regularly by their maintainers. However, at the moment there is no mechanism to see the history of changes to an object. There are many cases where RIPE Databases users want to investigate the history of changes to an object. We would like to propose building this functionality in the RIPE Database.