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/db-wg@ripe.net/
[db-wg] Draft Minutes from RIPE65
- Previous message (by thread): [db-wg] Draft Minutes from RIPE65
- Next message (by thread): [db-wg] Draft Minutes from RIPE65
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Heather Schiller
heather.skanks at gmail.com
Wed Sep 26 14:50:51 CEST 2012
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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: </ripe/mail/archives/db-wg/attachments/20120926/e93057f3/attachment.html>
- Previous message (by thread): [db-wg] Draft Minutes from RIPE65
- Next message (by thread): [db-wg] Draft Minutes from RIPE65
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]