Please find the minutes of the RIPE 65 DB-WG meeting attached. Comments to me Nigel
Dear DB working group, On 9/26/12 10:49 AM, Nigel Titley wrote:
Please find the minutes of the RIPE 65 DB-WG meeting attached. (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: https://labs.ripe.net/Members/dfk/registration-history-for-members-a-demo 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
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? ---heather On Wednesday, September 26, 2012, Vesna Manojlovic wrote:
Dear DB working group,
On 9/26/12 10:49 AM, Nigel Titley wrote:
Please find the minutes of the RIPE 65 DB-WG meeting attached.
(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: https://labs.ripe.net/Members/**dfk/registration-history-for-** members-a-demo<https://labs.ripe.net/Members/dfk/registration-history-for-members-a-demo>
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
On 2012.09.26. 14:50, Heather Schiller wrote:
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?
---heather
Hello, Manual filtering is an option, but by definition it requires manual work which makes it really expensive. In my personal opinion it also doesn't help, since people can always come up with reasons why they'd need the data, so at the end of the day the person deciding on whether that request is acceptable would only act as a bottleneck. The reason why limiting to members only is better than "any authorised user" is that it's very easy to create lots of untraceable accounts and abuse this service, whereas creating member users is not that easy and it's traceable to a member that we have business relation with. Regards, Robert
participants (4)
-
Heather Schiller -
Nigel Titley -
Robert Kisteleki -
Vesna Manojlovic