From alexb at ripe.net Thu May 1 12:14:13 2014 From: alexb at ripe.net (Alex Band) Date: Thu, 1 May 2014 12:14:13 +0200 Subject: [ncc-services-wg] Two-Step Verification for RIPE NCC Access Message-ID: Dear colleagues, We are pleased to launch two-step verification for RIPE NCC Access, our single sign-on service. This is an optional but highly recommended security feature that adds an extra layer of protection to your RIPE NCC Access account. Once enabled, you will be required to enter a six-digit security code in addition to your password whenever you sign in. To start using this feature, simply sign into your RIPE NCC Access account and follow the wizard on the profile page: https://access.ripe.net If you would like to know more, there is an FAQ available: https://www.ripe.net/s/cM3O All RIPE NCC Access account holders will be informed of this new feature. If you have any questions or comments, please let me know. Kind regards, Alex Band Product Manager RIPE NCC From ripe at liopen.fr Sat May 10 10:54:18 2014 From: ripe at liopen.fr (Denis Fondras - Liopen) Date: Sat, 10 May 2014 10:54:18 +0200 Subject: [ncc-services-wg] RPKI Validator over IPv6 Message-ID: <536DE93A.6020806@liopen.fr> Hello all, (First of all, sorry if I am not posting on the right mailing-list) I'm trying to connect to the testbed RPKI validators listed in [1] from an IPv6-only router but can't get to it. It seems the one hosted by Kaia Global Networks has no IPv6 and the one hosted by RIPE NCC is IPv6-enabled but it seems ports 323 and 8282 are not responding. Is there any testbed RPKI validator IPv6-reachable ? Thank you in advance. Regards, Denis [1] http://www.ripe.net/lir-services/resource-management/certification/tools-and-resources -- Denis Fondras / Liopen T?l: +33.473.242.720 Mob: +33.761.029.186 M?l: contact at liopen.fr JID: denis at liopen.fr PGP: 0xF7D4828559706135 From alexb at ripe.net Sat May 10 11:33:38 2014 From: alexb at ripe.net (Alex Band) Date: Sat, 10 May 2014 11:33:38 +0200 Subject: [ncc-services-wg] RPKI Validator over IPv6 In-Reply-To: <536DE93A.6020806@liopen.fr> References: <536DE93A.6020806@liopen.fr> Message-ID: Hi Denis, I?ll will report the IPv6 reachability issue for localcert.ripe.net to our IT department. I have to note that we?re just providing these services as a best-effort so you can see what the RPKI Validator works like and for example if your ROAs are showing up properly. But when using RPKI data, you should be running the validator application locally, within your own network. The reason for signing the certificates and ROAs in the first place is so that you can do cryptographic validation yourself, to verify that the information has not been tampered with. Setting it up is really easy, all you need is a UNIX-like system with Java and rsync available. Just download, unpack and run? Kind regards, Alex Band Product Manager RIPE NCC On 10 May 2014, at 10:54, Denis Fondras - Liopen wrote: > Hello all, > > (First of all, sorry if I am not posting on the right mailing-list) > > I'm trying to connect to the testbed RPKI validators listed in [1] from > an IPv6-only router but can't get to it. > > It seems the one hosted by Kaia Global Networks has no IPv6 and the one > hosted by RIPE NCC is IPv6-enabled but it seems ports 323 and 8282 are > not responding. > > Is there any testbed RPKI validator IPv6-reachable ? > > Thank you in advance. > > Regards, > Denis > > > [1] > http://www.ripe.net/lir-services/resource-management/certification/tools-and-resources > > > -- > Denis Fondras / Liopen > T?l: +33.473.242.720 > Mob: +33.761.029.186 > M?l: contact at liopen.fr > JID: denis at liopen.fr > PGP: 0xF7D4828559706135 > > From training at ripe.net Mon May 12 14:47:06 2014 From: training at ripe.net (Training Services) Date: Mon, 12 May 2014 14:47:06 +0200 Subject: [ncc-services-wg] [training] RIPE NCC Training Courses July-September 2014 Message-ID: <5370C2CA.4090708@ripe.net> Dear Colleagues, Our training team travels the RIPE NCC service region to deliver training courses to our members without any additional cost. Over the next few months, we'll be in Valencia, Tirana, Vilnius, Budapest, Tel Aviv, Samara, D?sseldorf, Stockholm, Belfast, Amsterdam, Ankara. Visit the following page to register and to check which training courses we are giving in your area: https://lirportal.ripe.net/training/courses The RIPE NCC delivers the following training courses: - LIR Training Course - Database Training Course - Basic IPv6 Training Course - Routing Security Training Course - 2 day Advanced Training Course - DNSSEC Training Course - Measurements Tools workshop For more information visit: http://www.ripe.net/lir-services/training/courses With kind regards, Rumy Spratley-Kanis Training Services Manager From training at ripe.net Mon May 19 10:59:05 2014 From: training at ripe.net (Training Services) Date: Mon, 19 May 2014 10:59:05 +0200 Subject: [ncc-services-wg] [training] RIPE NCC Webinars - new dates Message-ID: <5379C7D9.2010907@ripe.net> Dear colleagues, We are pleased to announce the launch of new dates for our Webinars. The RIPE NCC Webinars are live and take only one hour. You can interact with our trainers without leaving your desk. We focus on the topics and issues most important for LIRs. Register now at https://www.ripe.net/lir-services/training/e-learning/webinars Participation is limited to 20 people, so don't hesitate if you want to take part! If you have questions, please email . We look forward to seeing you online. Kind regards, RIPE NCC Training Services From jahlen at ripe.net Mon May 19 16:32:20 2014 From: jahlen at ripe.net (=?windows-1252?Q?Johan_=C5hl=E9n?=) Date: Mon, 19 May 2014 16:32:20 +0200 Subject: [ncc-services-wg] RIPE Database Release 1.73.1 Available in the Release Candidate Environment Message-ID: <7876BA61-B705-4F9F-91A0-09AEC707B775@ripe.net> Dear colleagues, Based on feedback from users testing RIPE Database release 1.73 in the Release Candidate (RC) environment, the RIPE NCC Database Group have made some software improvements that we?ve decided to incorporate into the next deployment. We will not deploy version 1.73 to production. Instead, we will deploy the improved version, 1.73.1, to the RC environment today, 19 May, and to production on 27 May 2014. The main concern with RIPE Database release 1.73 was related to user-automated assignment generation in the RIPE Database for legacy address space. With release 1.73, if a legacy object was updated with an incorrect "status:" attribute value, then the update would fail. With version 1.73.1, the database software will accept the update, regardless of any value supplied by the user, but will show a warning if the ?status:? attribute value is incorrect. For more information about this release and how it might affect your operations, please see the release notes: https://www.ripe.net/data-tools/db/release-notes/ripe-database-release-1.73.1 We look forward to any questions or comments you might have. Kind regards, Johan ?hl?n Assistant Manager Database RIPE NCC From alexb at ripe.net Tue May 20 17:11:09 2014 From: alexb at ripe.net (Alex Band) Date: Tue, 20 May 2014 17:11:09 +0200 Subject: [ncc-services-wg] Introducing the IPv6 Analyser Message-ID: Dear colleagues, At RIPE 68 in Warsaw we were proud to introduce the IPv6 Analyser, a toolset that offers our members a visual insight into all the allocations, aggregations and assignments they have made. This is the first toolset that seamlessly integrates with the RIPE Database, allowing you to create new objects with an easy-to-use wizard that guides you through the process, searching for available space, and pre-filling known information. Our goal is to unify resource management in the LIR Portal by extending these design principles to organisation, routing and Reverse DNS management. Now that the core design is available, we very much look forward to your feedback on how we can make the IPv4 and IPv6 Analyser as useful as possible. Please visit the LIR Portal and try out object creation using the IPv6 Analyser: https://www.ripe.net/s/qJhE Kind regards, Alex Band Product Manager RIPE NCC From denis at ripe.net Tue May 27 12:51:02 2014 From: denis at ripe.net (Denis Walker) Date: Tue, 27 May 2014 12:51:02 +0200 Subject: [ncc-services-wg] Blocking Access to Personal Data Objects in the RIPE Database Message-ID: <53846E16.9000302@ripe.net> Dear colleagues, At RIPE 68, we again raised the issue of how the blocking mechanism works in the RIPE Database. Currently it is all or nothing ? if a user queries for too much personal data, we block their access to everything. We often find that this causes issues for legitimate users of the database. This is a recent example of the requests our Customer Services department receives: "This is the outgoing NAT IP for a vast shared hosting cluster. We can't control the type of queries our customers run, there are over 250,000 websites, a tiny fraction might use RIPE but those customers are using RIPE database for a good reason and need to be able to query it. This is why I'm asking for a blanket allow.? Clearly we cannot whitelist any IP address for unlimited access to personal data. However, the option to only block access to personal data objects when the limit is reached would be a great help in these situations. No decision has been made on this issue. We are hoping that it can be further discussed by the community to see if a consensus can be reached. Regards Denis Walker Business Analyst RIPE NCC Database Team From zsako at iszt.hu Tue May 27 13:46:30 2014 From: zsako at iszt.hu (Janos Zsako) Date: Tue, 27 May 2014 13:46:30 +0200 Subject: [ncc-services-wg] [db-wg] Blocking Access to Personal Data Objects in the RIPE Database In-Reply-To: <53846E16.9000302@ripe.net> References: <53846E16.9000302@ripe.net> Message-ID: <53847B16.5070808@iszt.hu> Dear all, In short, yes, I support the proposal. My slightly modified suggestion is: When a given IP address, due to the large number of personal data queries reaches the limit where the NCC would now deny access to any objects, I think it would make sense to fully limit the access to personal data (i.e deny access to it), however, limit the access to other data as if they had been using the --no-personal flag so far. As long as there is no other kind of limitations than the one based on the number of personal data retrieved[*], this boils down to the suggestion below. If at some point other limitations are put in place, like number of queries within a time frame (to mitigate DoS attacks), then this would mean that they are still eligible for limitation if their query rate is too high (this time not due to the personal data involved). Best regards, Janos [*] See RIPE DB AUP (http://www.ripe.net/data-tools/support/documentation/aup). > At RIPE 68, we again raised the issue of how the blocking mechanism works in the RIPE Database. Currently it is all or nothing ? if a user queries for too much personal data, we block their access to everything. > > We often find that this causes issues for legitimate users of the database. This is a recent example of the requests our Customer Services department receives: > > "This is the outgoing NAT IP for a vast shared hosting cluster. We can't control the type of queries our customers run, there are over 250,000 websites, a tiny fraction might use RIPE but those customers are using RIPE database for a good reason and need to be able to query it. This is why I'm asking for a blanket allow.? > > Clearly we cannot whitelist any IP address for unlimited access to personal data. However, the option to only block access to personal data objects when the limit is reached would be a great help in these situations. > > No decision has been made on this issue. We are hoping that it can be further discussed by the community to see if a consensus can be reached. > > Regards > > Denis Walker > Business Analyst > RIPE NCC Database Team > > > From sander at steffann.nl Tue May 27 14:18:08 2014 From: sander at steffann.nl (Sander Steffann) Date: Tue, 27 May 2014 14:18:08 +0200 Subject: [ncc-services-wg] Blocking Access to Personal Data Objects in the RIPE Database In-Reply-To: <53846E16.9000302@ripe.net> References: <53846E16.9000302@ripe.net> Message-ID: <22BB61AE-4135-443F-B028-93E535E69BB1@steffann.nl> Hi Denis, > At RIPE 68, we again raised the issue of how the blocking mechanism works in the RIPE Database. Currently it is all or nothing ? if a user queries for too much personal data, we block their access to everything. > We often find that this causes issues for legitimate users of the database. This is a recent example of the requests our Customer Services department receives: > > "This is the outgoing NAT IP for a vast shared hosting cluster. We can't control the type of queries our customers run, there are over 250,000 websites, a tiny fraction might use RIPE but those customers are using RIPE database for a good reason and need to be able to query it. This is why I'm asking for a blanket allow.? > > Clearly we cannot whitelist any IP address for unlimited access to personal data. However, the option to only block access to personal data objects when the limit is reached would be a great help in these situations. Sounds like a logical plan. If people ask for too much personal data, stop giving them personal data :) No reason to let them continue to ask for things that wouldn't have affected the rate limiter anyway. Rate limiters should only apply limits to whatever they are measuring the rate of :) Cheers, Sander From Piotr.Strzyzewski at polsl.pl Tue May 27 14:25:52 2014 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Tue, 27 May 2014 14:25:52 +0200 Subject: [ncc-services-wg] [db-wg] Blocking Access to Personal Data Objects in the RIPE Database In-Reply-To: <53847B16.5070808@iszt.hu> References: <53846E16.9000302@ripe.net> <53847B16.5070808@iszt.hu> Message-ID: <20140527122552.GF20117@hydra.ck.polsl.pl> On Tue, May 27, 2014 at 01:46:30PM +0200, Janos Zsako wrote: Dear Janos, Denis and All > In short, yes, I support the proposal. > > My slightly modified suggestion is: > > When a given IP address, due to the large number of personal data queries > reaches the limit where the NCC would now deny access to any objects, I think > it would make sense to fully limit the access to personal data (i.e deny > access to it), however, limit the access to other data as if they had been > using the --no-personal flag so far. > > As long as there is no other kind of limitations than the one based on > the number of personal data retrieved[*], this boils down to the suggestion below. > If at some point other limitations are put in place, like number of queries > within a time frame (to mitigate DoS attacks), then this would mean that they > are still eligible for limitation if their query rate is too high (this time > not due to the personal data involved). I strongly support this idea. Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From Woeber at CC.UniVie.ac.at Tue May 27 14:33:18 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Tue, 27 May 2014 14:33:18 +0200 Subject: [ncc-services-wg] [db-wg] Blocking Access to Personal Data Objects in the RIPE Database In-Reply-To: <53847B16.5070808@iszt.hu> References: <53846E16.9000302@ripe.net> <53847B16.5070808@iszt.hu> Message-ID: <5384860E.80107@CC.UniVie.ac.at> Janos Zsako wrote: > Dear all, > > In short, yes, I support the proposal. Same here. I also, in principle, like the more general idea as outlined below. Although I'd leave it to the NCC to think about and to apply DoS protection. :-) Wilfried. > My slightly modified suggestion is: > > When a given IP address, due to the large number of personal data queries > reaches the limit where the NCC would now deny access to any objects, I > think > it would make sense to fully limit the access to personal data (i.e deny > access to it), however, limit the access to other data as if they had been > using the --no-personal flag so far. > > As long as there is no other kind of limitations than the one based on > the number of personal data retrieved[*], this boils down to the > suggestion below. > If at some point other limitations are put in place, like number of queries > within a time frame (to mitigate DoS attacks), then this would mean that > they > are still eligible for limitation if their query rate is too high (this > time > not due to the personal data involved). > > Best regards, > Janos > > [*] See RIPE DB AUP > (http://www.ripe.net/data-tools/support/documentation/aup). > >> At RIPE 68, we again raised the issue of how the blocking mechanism >> works in the RIPE Database. Currently it is all or nothing ? if a user >> queries for too much personal data, we block their access to everything. >> >> We often find that this causes issues for legitimate users of the >> database. This is a recent example of the requests our Customer >> Services department receives: >> >> "This is the outgoing NAT IP for a vast shared hosting cluster. We >> can't control the type of queries our customers run, there are over >> 250,000 websites, a tiny fraction might use RIPE but those customers >> are using RIPE database for a good reason and need to be able to query >> it. This is why I'm asking for a blanket allow.? >> >> Clearly we cannot whitelist any IP address for unlimited access to >> personal data. However, the option to only block access to personal >> data objects when the limit is reached would be a great help in these >> situations. >> >> No decision has been made on this issue. We are hoping that it can be >> further discussed by the community to see if a consensus can be reached. >> >> Regards >> >> Denis Walker >> Business Analyst >> RIPE NCC Database Team >> >> >> > From brian.nisbet at heanet.ie Tue May 27 15:50:58 2014 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Tue, 27 May 2014 14:50:58 +0100 Subject: [ncc-services-wg] [db-wg] Blocking Access to Personal Data Objects in the RIPE Database In-Reply-To: <22BB61AE-4135-443F-B028-93E535E69BB1@steffann.nl> References: <53846E16.9000302@ripe.net> <22BB61AE-4135-443F-B028-93E535E69BB1@steffann.nl> Message-ID: <53849842.6070106@heanet.ie> Sander Steffann wrote the following on 27/05/2014 13:18: > Hi Denis, > >> At RIPE 68, we again raised the issue of how the blocking mechanism works in the RIPE Database. Currently it is all or nothing ? if a user queries for too much personal data, we block their access to everything. >> We often find that this causes issues for legitimate users of the database. This is a recent example of the requests our Customer Services department receives: >> >> "This is the outgoing NAT IP for a vast shared hosting cluster. We can't control the type of queries our customers run, there are over 250,000 websites, a tiny fraction might use RIPE but those customers are using RIPE database for a good reason and need to be able to query it. This is why I'm asking for a blanket allow.? >> >> Clearly we cannot whitelist any IP address for unlimited access to personal data. However, the option to only block access to personal data objects when the limit is reached would be a great help in these situations. > > Sounds like a logical plan. If people ask for too much personal data, stop giving them personal data :) No reason to let them continue to ask for things that wouldn't have affected the rate limiter anyway. > > Rate limiters should only apply limits to whatever they are measuring the rate of :) Just what things should a rate limit limit if a rate limit could limit things? Doesn't really work, however I think the right approach has been outlined here. What we're interested in is restricting access to personal data, not to the database. Brian From denis at ripe.net Tue May 27 16:24:45 2014 From: denis at ripe.net (Denis Walker) Date: Tue, 27 May 2014 16:24:45 +0200 Subject: [ncc-services-wg] [db-wg] RIPE Database Release 1.73.1 deployed In-Reply-To: <7876BA61-B705-4F9F-91A0-09AEC707B775@ripe.net> References: <7876BA61-B705-4F9F-91A0-09AEC707B775@ripe.net> Message-ID: <5384A02D.1090704@ripe.net> Dear colleagues, RIPE Database software release 1.73.1 has now been deployed into production. The RIPE NCC has modified all AUT-NUM objects to add the mandatory "status:" attribute. We have also modified all legacy INETNUM objects and set the "status:" to 'LEGACY'. Regards Denis Walker Business Analyst RIPE NCC Database Team On 19/05/2014 16:32, Johan ?hl?n wrote: > Dear colleagues, > > Based on feedback from users testing RIPE Database release 1.73 in the Release Candidate (RC) environment, the RIPE NCC Database Group have made some software improvements that we?ve decided to incorporate into the next deployment. We will not deploy version 1.73 to production. Instead, we will deploy the improved version, 1.73.1, to the RC environment today, 19 May, and to production on 27 May 2014. > > The main concern with RIPE Database release 1.73 was related to user-automated assignment generation in the RIPE Database for legacy address space. With release 1.73, if a legacy object was updated with an incorrect "status:" attribute value, then the update would fail. With version 1.73.1, the database software will accept the update, regardless of any value supplied by the user, but will show a warning if the ?status:? attribute value is incorrect. > > For more information about this release and how it might affect your operations, please see the release notes: > https://www.ripe.net/data-tools/db/release-notes/ripe-database-release-1.73.1 > > We look forward to any questions or comments you might have. > > Kind regards, > > Johan ?hl?n > Assistant Manager Database > RIPE NCC > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Tue May 27 16:28:22 2014 From: sander at steffann.nl (Sander Steffann) Date: Tue, 27 May 2014 16:28:22 +0200 Subject: [ncc-services-wg] [db-wg] RIPE Database Release 1.73.1 deployed In-Reply-To: <5384A02D.1090704@ripe.net> References: <7876BA61-B705-4F9F-91A0-09AEC707B775@ripe.net> <5384A02D.1090704@ripe.net> Message-ID: <8D9F62C9-4FFC-4450-82A0-4D830DC57DF1@steffann.nl> Hi Denis, > RIPE Database software release 1.73.1 has now been deployed into production. > > The RIPE NCC has modified all AUT-NUM objects to add the mandatory "status:" attribute. We have also modified all legacy INETNUM objects and set the "status:" to 'LEGACY'. And all the others to "status: ASSIGNED" it seems :) Thanks! Sander From rhe at nosc.ja.net Tue May 27 16:38:28 2014 From: rhe at nosc.ja.net (Rob Evans) Date: Tue, 27 May 2014 15:38:28 +0100 Subject: [ncc-services-wg] [db-wg] RIPE Database Release 1.73.1 deployed In-Reply-To: <8D9F62C9-4FFC-4450-82A0-4D830DC57DF1@steffann.nl> References: <7876BA61-B705-4F9F-91A0-09AEC707B775@ripe.net> <5384A02D.1090704@ripe.net> <8D9F62C9-4FFC-4450-82A0-4D830DC57DF1@steffann.nl> Message-ID: >> The RIPE NCC has modified all AUT-NUM objects to add the mandatory "status:" attribute. We have also modified all legacy INETNUM objects and set the "status:" to 'LEGACY'. > > And all the others to "status: ASSIGNED" it seems :) ...with the odd 'status: OTHER' for objects that are neither legacy nor assigned by the NCC. Cheers, Rob From andreas.larsen at ip-only.se Tue May 27 17:59:15 2014 From: andreas.larsen at ip-only.se (Andreas Larsen) Date: Tue, 27 May 2014 15:59:15 +0000 Subject: [ncc-services-wg] [db-wg] Blocking Access to Personal Data Objects in the RIPE Database In-Reply-To: <53849842.6070106@heanet.ie> References: <53846E16.9000302@ripe.net> <22BB61AE-4135-443F-B028-93E535E69BB1@steffann.nl> <53849842.6070106@heanet.ie> Message-ID: I agree implement this like Dennis recommendation below. // Andreas Andreas Larsen IP-Only AB | Postadress: 753 81 UPPSALA | Bes?ksadress Uppsala: S:t Persg 6 Bes?ksadress Stockholm: N Stationsg 69 | Vxl: +46 18 843 10 00 | Mobil +46 70 843 10 56 www.ip-only.se 27 maj 2014 kl. 15:50 skrev Brian Nisbet : > Sander Steffann wrote the following on 27/05/2014 13:18: >> Hi Denis, >> >>> At RIPE 68, we again raised the issue of how the blocking mechanism works in the RIPE Database. Currently it is all or nothing ? if a user queries for too much personal data, we block their access to everything. >>> We often find that this causes issues for legitimate users of the database. This is a recent example of the requests our Customer Services department receives: >>> >>> "This is the outgoing NAT IP for a vast shared hosting cluster. We can't control the type of queries our customers run, there are over 250,000 websites, a tiny fraction might use RIPE but those customers are using RIPE database for a good reason and need to be able to query it. This is why I'm asking for a blanket allow.? >>> >>> Clearly we cannot whitelist any IP address for unlimited access to personal data. However, the option to only block access to personal data objects when the limit is reached would be a great help in these situations. >> >> Sounds like a logical plan. If people ask for too much personal data, stop giving them personal data :) No reason to let them continue to ask for things that wouldn't have affected the rate limiter anyway. >> >> Rate limiters should only apply limits to whatever they are measuring the rate of :) > > Just what things should a rate limit limit if a rate limit could limit things? > > Doesn't really work, however I think the right approach has been outlined here. What we're interested in is restricting access to personal data, not to the database. > > Brian > From joao at bondis.org Wed May 28 11:01:23 2014 From: joao at bondis.org (=?iso-8859-1?Q?Jo=E3o_Damas?=) Date: Wed, 28 May 2014 11:01:23 +0200 Subject: [ncc-services-wg] [db-wg] Blocking Access to Personal Data Objects in the RIPE Database In-Reply-To: <5384860E.80107@CC.UniVie.ac.at> References: <53846E16.9000302@ripe.net> <53847B16.5070808@iszt.hu> <5384860E.80107@CC.UniVie.ac.at> Message-ID: <1EFACBA8-E189-4984-94A4-04419470C830@bondis.org> On 27 May 2014, at 14:33, Wilfried Woeber wrote: > Janos Zsako wrote: > >> Dear all, >> >> In short, yes, I support the proposal. > > Same here. I also, in principle, like the more general idea as outlined below. > Although I'd leave it to the NCC to think about and to apply DoS protection. :-) > I am in full agreement with Wilfried?s comment, supporting the modified limitation to personal data access, and let the operator deal with operational issues Joao > Wilfried. > >> My slightly modified suggestion is: >> >> When a given IP address, due to the large number of personal data queries >> reaches the limit where the NCC would now deny access to any objects, I >> think >> it would make sense to fully limit the access to personal data (i.e deny >> access to it), however, limit the access to other data as if they had been >> using the --no-personal flag so far. >> >> As long as there is no other kind of limitations than the one based on >> the number of personal data retrieved[*], this boils down to the >> suggestion below. >> If at some point other limitations are put in place, like number of queries >> within a time frame (to mitigate DoS attacks), then this would mean that >> they >> are still eligible for limitation if their query rate is too high (this >> time >> not due to the personal data involved). >> >> Best regards, >> Janos >> >> [*] See RIPE DB AUP >> (http://www.ripe.net/data-tools/support/documentation/aup). >> >>> At RIPE 68, we again raised the issue of how the blocking mechanism >>> works in the RIPE Database. Currently it is all or nothing ? if a user >>> queries for too much personal data, we block their access to everything. >>> >>> We often find that this causes issues for legitimate users of the >>> database. This is a recent example of the requests our Customer >>> Services department receives: >>> >>> "This is the outgoing NAT IP for a vast shared hosting cluster. We >>> can't control the type of queries our customers run, there are over >>> 250,000 websites, a tiny fraction might use RIPE but those customers >>> are using RIPE database for a good reason and need to be able to query >>> it. This is why I'm asking for a blanket allow.? >>> >>> Clearly we cannot whitelist any IP address for unlimited access to >>> personal data. However, the option to only block access to personal >>> data objects when the limit is reached would be a great help in these >>> situations. >>> >>> No decision has been made on this issue. We are hoping that it can be >>> further discussed by the community to see if a consensus can be reached. >>> >>> Regards >>> >>> Denis Walker >>> Business Analyst >>> RIPE NCC Database Team >>> >>> >>> >> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: