You are here: Home > Participate > RIPE Community > Task Forces > The RIPE Database Requirements Task Force > Database Requirements Task Force Recommendations

Database Requirements Task Force Recommendations

In November 2021, the RIPE Database Requirements Task Force published its final report. In the report were requirement and recommendations, highlighting things that the RIPE community might want to examine and consider whether further action was needed. In June 2022, the RIPE NCC published a preliminary impact analysis based on these recommendations. 

This page is intended to document the RIPE community's work as it considers these recommendations and record any actions or decisions that are taken as a result. It is important to note that the task force viewed these recommendations as things for the community to look at in more detail - it did not necessarily expect that all of them would result in action.


Pending:  Completed: 



Requirement/Other Consideration


Working Group


Providing authoritative and accurate registration of Internet number resources Baseline requirements for registration information of Internet number resources

1. The task force believes that the following baseline requirements are sufficient to ensure uniqueness and to provide accurate registration as defined in RFC 7020:

  • Full legal name of resource holder
  • Contact information for administrative and technical matters
  • Country Code of where the resource holder is legally based

The task force did not recognise the full postal address of resource holders as a baseline requirement for registration information of Internet number resources. Therefore, the task force recommends that information about the postal address be made optional and not compulsory. In the long term, the task force recommends taking this information out of the database. If the community accepts this recommendation, the relevant supporting documents should be updated accordingly.


   IPv4 PA assignments

2.1. The task force recommends that as resource holders have full responsibility over the registration of their IPv4 PA assignment(s), they are free to make assignments or not. If the community accepts this recommendation, the relevant RIPE Policies should be updated accordingly, and documenting IPv4 PA assignment(s) will stop being a policy requirement.

Please note that the task force does NOT recommend that these assignments be deleted but that resource holders can choose to document this information in the RIPE Database.

However, if a resource holder wants to sub-allocate or partition part of their IPv4 resources to another entity, the task force strongly recommends documenting this sub-allocation or assignment in the RIPE Database.

2.2. Following the data consistency principle, the task force also recommends resource registration requirements be applied consistently to all Internet number resources, regardless of their type or status.

To ensure that the information published in the RIPE Database is correctly updated by resource holders, the task force recommends that the RIPE NCC continue to use ARCs (Assisted Registry Checks) to verify this data.

Address Policy

  Using the RIPE Database as an IPAM solution

3. The task force recommends limiting and discouraging the use of the RIPE Database as an enterprise IPAM solution.


  Historical data and personal data filtering

4.1. The task force recognises historical data as a requirement of the RIPE Database. However, access to this data should be limited to what is necessary for the most common type of use cases. Regarding research usage, the task force recommends that the RIPE NCC grants access to a wider set of historical data to researchers who need it on a case-by-case basis and according to specific criteria. These criteria should be discussed and defined by the RIPE community.

4.2. There is no easy way to track the chain of ownership for address blocks that have been split or merged. The community should consider adding this functionality to historical data.


Publishing routing policies by network operators (RIPE IRR)  Routing information


  • 5.1. The RIPE Database will provide routing information for:
    • Internet number resources delegated by the RIPE NCC.
    • Internet number resources which fall under the terms of the "RIPE NCC Services to Legacy Internet Resource Holders" policy.
    • Other Internet number resources that already have routing information in the RIPE Database.
  • 5.2. Routing information should be maintained by the holders of these resources.
  • 5.3. The holders of these resources should be authenticated by the RIPE NCC or by the holders of parent resources, and only the holders will be authorised to manage routing information for the resources that they hold.
  • 5.4. Routing information for resources delegated to holders that have not been authenticated by the RIPE NCC should be labelled as non-authoritative. This should apply to both non-RIPE NCC resources and legacy resources with no formal relationship with the RIPE NCC.
  • 5.5.The RIPE community should aim to create policies to delete stale and inaccurate non-authoritative routing information.
  • 5.6. It should not be possible to add new routing information to the RIPE Database for address resources delegated by other Regional Internet Registries.


  Maintaining accurate routing origin information


  • 6.1. Routing origin information should be published via ROUTE:/ROUTE6: objects in the RIPE Database.
  • 6.2. ROAs should be created in RPKI to represent routing origin information.


  Routing Policy Specification Language (RPSL)

7. RPSL is not a requirement for the RIPE Database. As such, the RIPE Routing working group should look at formally deprecating RPSL, with the cooperation of the RIPE Database Working Group. The specific recommendation is to consider what routing information is useful to operators and design a model to represent that.

Until RPSL is re-evaluated, the RIPE Database must continue to support it.


   RPKI Database

8. The task force recommends that RIPE NCC members and the RIPE community consider whether the RPKI Database should be treated as a community resource (like the RIPE Database) with policies and rules set by the community or should continue to be treated as a RIPE NCC service.


Facilitating Internet operations and coordination Operational Contact Information (PERSON and ROLE Objects)

9. The task force recommends to promote ROLE objects instead of PERSON objects but to still make it possible for users to create PERSON objects if/where necessary. However, the task force is aware that users could also add personal data to ROLE objects. This is why stricter checks and measures should be implemented to prevent users from involuntarily entering personal data in both object types. This will also allow users to progressively move away from PERSON objects.

Implementation details should be discussed in the RIPE Database Working Group in collaboration with the RIPE NCC.


  Publishing the legal address of resource holders

10. After weighing the pros and cons and listening to community feedback, the task force decided not to go ahead with this recommendation, as there was no clear consensus.

However, the task force recognises the LEAs’ need to access this information in a timely manner to be able to quickly respond to criminal activity on the Internet. Therefore, the task force’s recommendation for legal address is that the community explore alternative solutions. The task force recommends that this work be carried out by the relevant working groups.