[db-wg] RIPE Database Access Control

Hi Denis & all,

> 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?

Actually changing default behavior should only be done if there is a real good reason
for that (think of all the poor scripts and the old guys out there who
never will be able to learn yet another new switch for the whois client etc.!).

I do see your argument why you would want to change it.
And i do see that there is seldom the need to return additional data
like person objects when querying other types.

-> I have no problem with the current situation and i perhaps would say it should NOT
   be changed, but in the end i wouldn't object if it solves more serious
   operational problems like the ACL issues for some. 
   I've never really encountered the problem myself though and don't know
   how serious the impact is for others at all.

> 2/ Should we block access to personal data only and still allow access
> to operational data?
[...]
> 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.


The question alone is misleading, but your comments below explain your intentions so 
i'm quoting both here :-)

That idea is a more focused solution if you ask me.
I guess i would support it. 

I haven't made up my mind about temp vs. perm 
block though since i never ran into this issue. 

> 3/ Should there be more transparency of limits with some user options?


Well that's a no-brainer (i think) - full transparency it is.

-- 
Mit freundlichen Grüßen / Kind Regards

Sascha Lenz [SLZ-RIPE]
Senior System- & Network Architect