This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[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 ]