Skip to main content

Frequent Update Request

This policy proposal has been withdrawn
Publication date
Draft document
DRAFT: Frequent Database Update Request
  • Tobias Knecht []
Proposal Version
1.0 - 09 Nov 2010
All Versions
30 Nov 2010
State Discription
The proposer decided to withdraw the proposal based on the feedback received at RIPE 61. A task force will be organised to solve the implementation issues pointed out by the proposal discussion.
Working Group
Anti-Abuse Working Group
Proposal type
  • New
Policy term

This proposal suggests to have the minimum assignment size for PI assignments to be a /24 when routing is a major issue for a multihoming End User.

Summary of Proposal:

This is a proposal for the RIPE NCC to regularly contact all current RIPE Database object holders with resources in the RIPE Database to ask them to actively check that all their details are up-to-date.

To actively check details, the object owner has to log into the LIR Portal and acknowledge the accuracy of data in their object(s) or update all existing objects if needed. The update date will be shown in the "changed:" attribute of every single object.

Summary of current problem

RIPE whois database data accuracy has been a big issue for years now. There have been several approaches to get better data accuracy within whois information all over the world.

There are two main reasons for data inaccuracy:

  1. Wrong data is published to camouflage illegal actions.
  2. Outdated data is published because maintainers forget to update it as changes occur within their organisation (staff changes, etc.)

A secondary problem is data incompleteness:

  • Sometimes, there are changes to the structure of whois data, such as additional mandatory objects or attributes (for example, the irt object). Object owners usually do not immediately make these changes to the objects they are responsible for. So there is always data missing in the RIPE Database.

Situation in other RIRs

ARIN conducts an annual POC (point of contact) validation process:

APNIC is currently discussing a similar approach:

If the current APNIC and RIPE NCC proposals are successful, the author plans to submit a similar proposal for the AfriNIC and LACNIC regions.

The proposal mentions a webform to report invalid database information. As an example, see the APNIC webform:

A link to the webform shall be linked in all RIPE Database output for reporting invalid contact information.


a. Arguments supporting the proposal

  • A frequent reminder and the need to actively verify will solve the problem of forgetting to update objects.
  • All objects will follow the latest requirements for registration in the RIPE Database. For example, if there is a mandatory field added within X months every object will be updated.
  • More people will use the LIR Portal.

b. Arguments opposing the proposal

  • No disadvantages are foreseen