Dear all, In short, yes, I support the proposal. My slightly modified suggestion is: When a given IP address, due to the large number of personal data queries reaches the limit where the NCC would now deny access to any objects, I think it would make sense to fully limit the access to personal data (i.e deny access to it), however, limit the access to other data as if they had been using the --no-personal flag so far. As long as there is no other kind of limitations than the one based on the number of personal data retrieved[*], this boils down to the suggestion below. If at some point other limitations are put in place, like number of queries within a time frame (to mitigate DoS attacks), then this would mean that they are still eligible for limitation if their query rate is too high (this time not due to the personal data involved). Best regards, Janos [*] See RIPE DB AUP (http://www.ripe.net/data-tools/support/documentation/aup).
At RIPE 68, we again raised the issue of how the blocking mechanism works in the RIPE Database. Currently it is all or nothing — if a user queries for too much personal data, we block their access to everything.
We often find that this causes issues for legitimate users of the database. This is a recent example of the requests our Customer Services department receives:
"This is the outgoing NAT IP for a vast shared hosting cluster. We can't control the type of queries our customers run, there are over 250,000 websites, a tiny fraction might use RIPE but those customers are using RIPE database for a good reason and need to be able to query it. This is why I'm asking for a blanket allow.”
Clearly we cannot whitelist any IP address for unlimited access to personal data. However, the option to only block access to personal data objects when the limit is reached would be a great help in these situations.
No decision has been made on this issue. We are hoping that it can be further discussed by the community to see if a consensus can be reached.
Regards
Denis Walker Business Analyst RIPE NCC Database Team