[db-wg] RIPE Database Access Control

Dear Colleagues

As part of the redevelopment project for the RIPE Database, we
re-implemented the Access Control List (ACL) mechanism. We simplified
the process and have some questions to ask the community.

1/ Should we change the default query behaviour so personal data must be
explicitly requested?
2/ Should we block access to personal data only and still allow access
to operational data?
3/ Should there be more transparency of limits with some user options?

More details about the new ACL and these three questions are provided below.

As the RIPE NCC continues to progress with the redevelopment project, we
will have more of these questions. The wider the community feedback on
these questions, the easier it will be for us to build a RIPE Database
service that satisfies your needs.

Regards,

Denis Walker
Business Analyst
RIPE NCC Database Group


Overview of new ACL

To make it very easy to understand what is happening, we have redefined
the algorithm for blocking and unblocking. Now, when you hit a set limit
for accessing personal data sets within a day, you will be temporarily
blocked from accessing the RIPE Database. This temporary block will be
removed at midnight (UTC). If you are temporarily blocked 10 times in a
rolling 30 day period, you will be permanently blocked. A permanent
block can only be removed by contacting Customer Services at
<ripe-dbm at ripe.net> and discussing the situation.

This is, in principle, the same as the current behaviour but with
simplified time periods and reset points.

Background to questions

1/ The current default behaviour on any query is to always return
personal data referenced in any other data that is returned by the
query. This is one of the main causes for temporary blocking of access
to the RIPE Database. Personal data is often returned when it was not
needed. To prevent the personal data being accounted, a query must
include the '-r' option. Many users think an option like '-T INETNUM'
will only return the INETNUM objects and no personal data will be
involved. Unfortunately, '-T' is not a true query option. It is a
filter. So the personal data is still queried and then filtered out of
the results set. This causes the personal data to still be accounted for
as if you had received it.

We would like to suggest reversing the default query behaviour. This way
no personal data will be returned unless you include a new query flag
explicitly requesting it.

2/ The current blocking mechanism works on the basis of all or nothing.
If you are not blocked, you can successfully query for any data in the
RIPE Database. If you are blocked (either temporarily or permanently),
any query from you is rejected with a "Denied access" error message.

We would like to propose a middle road. Blocking can be set to only
apply to personal data. So, after being blocked, you can still query for
any operational data in the RIPE Database. But all personal data will be
filtered out of the results set, even if you explicitly request it.

If the community likes this idea, a further choice is possible. One
option is to apply this middle road to both temporary and permanent
blocks. Another is to only apply this to temporary blocks and keep a
permanent block as a complete "Denied access" error.

3/ A final question regards information about the limits. In the past,
details of limits and when they were reset were not clearly published in
any document. But it is not difficult to determine them with a little
trial and error. Perhaps the community would prefer complete
transparency on this. We can publish all the limits in a revised
Acceptable Use Policy (AUP) document and even provide a query option to
let a user know how much of their daily limit they have already used.