RIPE Database Acceptable Use Policy
Definitions
In the Acceptable Use Policy (AUP), the following terms shall be understood to have the meanings assigned to them below:
RIPE NCC – Réseaux IP Européens Network Coordination Centre. A membership association under Dutch law operating its registered office in Amsterdam, the Netherlands.
Update – submitting information for entry into or removal from the RIPE Database
Query – requesting information from the RIPE Database
Access – Update and Query the RIPE Database
RIPE Database – the publicly available data collection of Internet Number Registry (INR) and Internet Routing Registry (IRR) data published by the RIPE NCC. It contains all the primary and secondary objects. There is also some non-public data required for the operation of the RIPE Database and the registries, but this non-public data does not form part of the RIPE Database.
User – anyone who Accesses the RIPE Database or causes Access to be made. This includes Registrants and Maintainers, as defined in the RIPE Database Terms and Conditions.
Abuse-c – an attribute referencing a role object holding abuse contact information, to be included in inetnum, inet6num and aut-num objects, intended for receiving automatic and manual reports about abusive behaviour originating in resource holder's networks.
SSO Account – the RIPE NCC access (Single Sign-On) account Users can access RIPE NCC services through.
Introduction
The following principles define the purpose of this policy. Without prejudice to the applicability of the RIPE Database Terms and Conditions, this policy is to ensure that:
- The usage of the RIPE Database is in line with the purpose of the RIPE Database as defined in the RIPE Database Terms and Conditions.
- No copy of a significant part of the RIPE Database is made without the consent of the RIPE NCC.
- We protect the personal data held within the RIPE Database.
- The RIPE Database service is only used as intended and defined in documents and manuals associated with the service.
- All Users comply with the limits set on their Access to the RIPE Database services.
- We do not put the RIPE Database services at risk.
- Our general policies (e.g., on pricing, fees, privacy, data protection and Access) are not compromised.
- Users do not act in a way that disrupts the RIPE Database services for other Users.
The RIPE Database Terms and Conditions permit the RIPE NCC to block Access to the RIPE Database services by any User for abuse, or suspend Access for suspected abuse.
Please note that we have a standard clause on anti-avoidance and connected persons that forms part of this policy (see below).
We may reject queries originated by Users who have exceeded their limit or who are subject to sanctions for abuse without regard to their limit.
Limits
These are the limits currently set by the RIPE NCC for using the RIPE Database service.
Query service:
- Number of queries from an IP address – Unlimited [1]
- Number of queries passed by a proxy – Unlimited [1]
- Number of personal data sets returned in queries from an IP address – 1,000 per 24 hours [3][4]
- Number of personal data sets returned in queries from a proxy IP address – 20,000 per 24 hours [3][4]
- Number of personal data sets returned in queries from an SSO Account – 1,000 per 24 hours [3][4]
Update service:
- Number of update e-mails sent to [email protected] – Unlimited [1]
- Number of updates submitted through the syncupdates interface – Unlimited [1]
- Number of updates submitted through the webupdates interface – Unlimited [1]
- Number of objects contained in a single update message – 5,000
- Size of a single update message – 500Kb
- Number of queued e-mail update messages from any one e-mail address – 100
General:
Number of simultaneous connections to the RIPE Database server – 3 [2]
Anti-avoidance and Connected Persons
One way that the principles of this policy can be compromised is if Users try to give the impression that they are separate, or claim to be separate, when in fact they are acting together to pool their limits, for example. If the RIPE NCC believes Users are acting in a coordinated way to bypass the above limits, we will consider the situation and act on a case-by-case basis.
References
[1] Where no limits are set, or a limit is set as Unlimited, we work on the basis of reasonable use. This means that we expect Users not to do anything that could abuse or damage the RIPE Database service or cause service disruption for other Users. If we detect any User causing problems we may, at our sole discretion, slow down or temporarily or permanently block Access to the RIPE Database services for that User.
[2] Queries can be sent to the RIPE Database without the need to wait for the previous query to return.
[3] If the number of personal data sets limit is exceeded, the User will be temporarily blocked from making any queries to the RIPE Database from the IP address, or SSO Account, submitting the queries for personal data. The number of queries accepted from the temporarily blocked IP address or SSO Account will recover exponentially over time. This will allow a slower query rate for some time. However, if a User is temporarily blocked several times, or continues to submit queries excessively even while blocked, they will be permanently blocked from querying the RIPE Database from that IP address or SSO Account, as the case may be. Despite the set limits for queries by the RIPE Database User, the email contacts which are included in the ”abuse-c” attribute are meant to be available with no restrictions to bulk access. Because this attribute can potentially be filled in with email addresses that could be considered to be personal, it is the maintainer's responsibility to inform the individual whose personal details will be referenced in the RIPE Database and obtain their consent for use of their data.
[4] Queries which are made to the RIPE Database by a User logged into their SSO Account will be accounted for separately from the IP address of that User. This means that if a User is logged in to their SSO Account, any query for objects containing personal data will be counted against their SSO Account and not their IP address. If a User is not logged into their SSO Account any queries for objects containing personal data will be counted against their IP address.