[db-wg] RIPE Database Access Control
- Previous message (by thread): [db-wg] RIPE Database Access Control
- Next message (by thread): [db-wg] RIPE Database Access Control
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Nick Hilliard
nick at inex.ie
Wed Mar 7 22:52:48 CET 2012
On 06/03/2012 15:32, Denis Walker wrote: > 1/ Should we change the default query behaviour so personal data must be > explicitly requested? No. > 2/ Should we block access to personal data only and still allow access > to operational data? What is the scale of the problem here? I.e. how many blocks per day are instituted? > 3/ Should there be more transparency of limits with some user options? would be useful, yes. > 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. Uhhh, I think POLA[*] applies here, in bucketloads. The query results that are returned are what should be accounted for, not other objects which are filtered out in-between. Nick [*] http://en.wikipedia.org/wiki/Principle_of_least_astonishment
- Previous message (by thread): [db-wg] RIPE Database Access Control
- Next message (by thread): [db-wg] RIPE Database Access Control
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]