What about restricting based on need/use? Requiring users to explain why they need the data and limiting the number of queries. I also don't understand the logic of trusting members over non-members as I am sure one could find examples of bad actors in both. Trust comes down to the user requesting the data and it should be easy enough to bind them to the same restrictive terms of use for the data regardless of whether they are an lir- or is there some consequence to lir's resources for violating trust/terms of service?<div> </div><div>---heather <div> </div><div>On Wednesday, September 26, 2012, Vesna Manojlovic wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Dear DB working group, On 9/26/12 10:49 AM, Nigel Titley wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Please find the minutes of the RIPE 65 DB-WG meeting attached. </blockquote> (Thank you, Nigel, for producing draft minutes so quickly!) my apologies for very poorly presenting "History view of DB objects", the new feature that we have in RIPEstat, this morning . As an answer to several concerns that were expressed after my introduction, I want to stress a few important points that I forgot to mention. For example: > Heather Schiller noted that this facility was effectively available > through the bulk whois mechanism but that this makes it much easier. > This remark was corrected by the RIPE NCC who pointed out that bulk > whois is cleansed of personal data. 1) the "Object Browser" does not expose personal contact information, in neither of the two modes: general-public AND members-only. The only details shown in person, role & organisation objects are names, nic-handles and mnt-names. There is no email-address, postal address, phone or fax number information. 2) We have implemented rate-limiting, in order to prevent "bulk access", even of these stripped-down objects. Rate limiting is implemented per user account: 1000/user/day. The browser widget makes two queries each time it is used. So you can use or reload this widget 500 times per day. Furthermore, this is only available to users that are contacts for LIRs (RIPE NCC members). It is possible that someone would be able to go around this restriction mechanism: LIRs can create multiple users account, but we would be able to notice this and contact them. This information is also included in the RIPE Labs article: <a href="https://labs.ripe.net/Members/dfk/registration-history-for-members-a-demo" target="_blank">https://labs.ripe.net/Members/dfk/registration-history-for-members-a-demo</a> I am sorry that I failed to mention these facts. As a reply to other concerns: data-protection issues will be looked into by our legal counsel, and membership-only service will be mentioned in ncc-services working group later on. Regards, Vesna </blockquote></div></div>