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@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.