From tim at haitabu.net Tue Dec 4 15:42:52 2012 From: tim at haitabu.net (Tim Kleefass) Date: Tue, 04 Dec 2012 15:42:52 +0100 Subject: [anti-abuse-wg] [db-wg] RIPE NCC's proposed implementation of Abuse Contact Management in the RIPE Database In-Reply-To: References: <20121116160307.GA18018@bongo.bofh.it> Message-ID: <50BE0BEC.9070902@haitabu.net> Hi Kaveh, et.al, I'm trying to figure out what I need to do to benefit from the abuse-c initiative with minimal impact to our documentation and processes. On 19.11.2012 10:38 AM, Kaveh Ranjbar wrote: > Yes, in the data entry side a little bit more effort is required, but > as we have mentioned at > (https://labs.ripe.net/Members/kranjbar/implementation-details-of-policy-2011-06), > there are two main reasons for that: > > a) This models the reality, in almost every case we know of, abuse > handling is a role within an organisation. On he other hand attaching > an email address to a resource is creating an arbitrary link. > > b) Operationally it is a lot more feasible for our members and users > to enter data and more importantly to maintain this data over time if > it is centralised in an entity modelled after their real work setup. While rolling out IPv6 we (must) document the assignments. This can (as far as I known) either be done by a covering inet6num object with an "assignment-size" and an internal documentation or by having an inet6num object for every assignment. With the later we can have an "abuse-mailbox" in a role object linking to "tech-c" (and "admin-c") of the inet6num object. So this is what we are doing today (create a role-object with abuse-mailbox etc. per role/customer/participant and link to it from admin-c and tech-c in the inet[6]num objects). With this new schema we need to create an additional organisation object just to link from the inet[6]num object (through "org" and the organisation object) to the (already existing) role object. In the additional organisation object we copy the address and e-mail information from the role object, because these two fields are mandatory in both objects. So we need to keep track of this information in two objects. Please see an example scheme here with the mandatory fields: inet6num: 2001:db8:1337::/48 ~~~~~~~~~ netname: blubb-net1 descr: network of blubb country: DE admin-c: >--------------------+ tech-c: >--------------------+ status: ASSIGNED | mnt-by, changed, source: ... | (org): >------------------+ | | | | | organisation: ORG-BLUBB-RIPE <---+ | ~~~~~~~~~~~~~ | abuse-c: >------------------+ | org-name: blubb | | org-type: OTHER | | address: | | mnt-ref: ... | | mnt-by, changed, source: ... | | | | | | role: blubb | | ~~~~~ | | address: fantasialand | | nic-hdl: blubb-RIPE <------+-+ e-mail: role-email at example.com admin-c: >-----------------------> person: tech-c: >-----------------------> person(s): mnt-by, changed, source: ... abuse-mailbox: abuse at example.com Did I miss something? Can I do this easier? Or is it mandatory/best practice to create an organisation object for each customer/party anyway ? If not, I would be happy to link directly from an "abuse-c" in the inet[6]num object to the role account (in parallel to tech-c and admin-c). Many thanks for help, Tim From denis at ripe.net Tue Dec 4 17:11:28 2012 From: denis at ripe.net (Denis Walker) Date: Tue, 04 Dec 2012 17:11:28 +0100 Subject: [anti-abuse-wg] [db-wg] RIPE NCC's proposed implementation of Abuse Contact Management in the RIPE Database In-Reply-To: <50BE0BEC.9070902@haitabu.net> References: <20121116160307.GA18018@bongo.bofh.it> <50BE0BEC.9070902@haitabu.net> Message-ID: <50BE20B0.8050302@ripe.net> Dear Tim, Lets start at the beginning. You mentioned there are two ways of creating your INET6NUM objects in the RIPE Database. Either you aggregate them in groups of customers with the same size of address space assignments or you list them individually. If your customers are simply end users who will not be managing the address space, routing, abuse handling themselves then you might choose to aggregate them. In this case you will be handling the abuse complaints and you can use your own ORGANISATION object to reference the abuse handling ROLE object. So all you need to do is create one additional ROLE object and everything is set up. If each of your customers is a separate business (even if it is an individual) who will be doing much of the management themselves, including handling any abuse complaints for their assigned address space, then you need a bit more setup. As we said in the implementation plan we are trying to move the RIPE Database in the direction of modelling the real world setup. This may require a little more initial setup, but in the end will be easier for everyone to understand and follow. So if each of your customers is an organisation handling it's own abuse, creating an ORGANISATION object for them as a reference point with an abuse ROLE object, shows they manage resources or have some role within this management. We will provide tools to assist in the setting up of this data. This will simplify your workload and avoid the need for you to enter information twice. Regards Denis Walker Business Analyst RIPE NCC Database Group On 04/12/2012 15:42, Tim Kleefass wrote: > Hi Kaveh, et.al, > > I'm trying to figure out what I need to do to benefit from the abuse-c > initiative with minimal impact to our documentation and processes. > > On 19.11.2012 10:38 AM, Kaveh Ranjbar wrote: >> Yes, in the data entry side a little bit more effort is required, but >> as we have mentioned at >> (https://labs.ripe.net/Members/kranjbar/implementation-details-of-policy-2011-06), >> there are two main reasons for that: >> >> a) This models the reality, in almost every case we know of, abuse >> handling is a role within an organisation. On he other hand attaching >> an email address to a resource is creating an arbitrary link. >> >> b) Operationally it is a lot more feasible for our members and users >> to enter data and more importantly to maintain this data over time if >> it is centralised in an entity modelled after their real work setup. > > While rolling out IPv6 we (must) document the assignments. This can (as > far as I known) either be done by a covering inet6num object with an > "assignment-size" and an internal documentation or by having an inet6num > object for every assignment. > > With the later we can have an "abuse-mailbox" in a role object linking > to "tech-c" (and "admin-c") of the inet6num object. > > So this is what we are doing today (create a role-object with > abuse-mailbox etc. per role/customer/participant and link to it from > admin-c and tech-c in the inet[6]num objects). > > With this new schema we need to create an additional organisation object > just to link from the inet[6]num object (through "org" and the > organisation object) to the (already existing) role object. In the > additional organisation object we copy the address and e-mail > information from the role object, because these two fields are mandatory > in both objects. So we need to keep track of this information in two > objects. > > Please see an example scheme here with the mandatory fields: > > > inet6num: 2001:db8:1337::/48 > ~~~~~~~~~ > netname: blubb-net1 > descr: network of blubb > country: DE > admin-c: >--------------------+ > tech-c: >--------------------+ > status: ASSIGNED | > mnt-by, changed, source: ... | > (org): >------------------+ | > | | > | | > organisation: ORG-BLUBB-RIPE <---+ | > ~~~~~~~~~~~~~ | > abuse-c: >------------------+ | > org-name: blubb | | > org-type: OTHER | | > address: e-mail: role object> | | > mnt-ref: ... | | > mnt-by, changed, source: ... | | > | | > | | > role: blubb | | > ~~~~~ | | > address: fantasialand | | > nic-hdl: blubb-RIPE <------+-+ > e-mail: role-email at example.com > admin-c: >-----------------------> person: > tech-c: >-----------------------> person(s): > mnt-by, changed, source: ... > abuse-mailbox: abuse at example.com > > > Did I miss something? Can I do this easier? > Or is it mandatory/best practice to create an organisation object for > each customer/party anyway ? > > If not, I would be happy to link directly from an "abuse-c" in the > inet[6]num object to the role account (in parallel to tech-c and admin-c). > > > Many thanks for help, > Tim > > From vesely at tana.it Wed Dec 5 09:59:01 2012 From: vesely at tana.it (Alessandro Vesely) Date: Wed, 05 Dec 2012 09:59:01 +0100 Subject: [anti-abuse-wg] [db-wg] RIPE NCC's proposed implementation of Abuse Contact Management in the RIPE Database In-Reply-To: <50BE20B0.8050302@ripe.net> References: <20121116160307.GA18018@bongo.bofh.it> <50BE0BEC.9070902@haitabu.net> <50BE20B0.8050302@ripe.net> Message-ID: <50BF0CD5.9070107@tana.it> On Tue 04/Dec/2012 17:11:28 +0100 Denis Walker wrote: > > If each of your customers is a separate business (even if it is an > individual) who will be doing much of the management themselves, > including handling any abuse complaints for their assigned address > space, then you need a bit more setup. I think that the general case is that some customers just want to get connected while some others want to manage abuse. Customers may change their mind after some time, of course. Wasn't the design supposed to ease overriding the abuse handling object at will? From denis at ripe.net Wed Dec 5 11:10:09 2012 From: denis at ripe.net (Denis Walker) Date: Wed, 05 Dec 2012 11:10:09 +0100 Subject: [anti-abuse-wg] [db-wg] RIPE NCC's proposed implementation of Abuse Contact Management in the RIPE Database In-Reply-To: <50BF0CD5.9070107@tana.it> References: <20121116160307.GA18018@bongo.bofh.it> <50BE0BEC.9070902@haitabu.net> <50BE20B0.8050302@ripe.net> <50BF0CD5.9070107@tana.it> Message-ID: <50BF1D81.2040408@ripe.net> Dear Alessandro, The design does ease the fine tuning of abuse handling. By default the LIR's ORGANISATION object will reference the LIR's abuse handling ROLE. This is the root for all abuse handling for the resources allocated to an LIR. If at some point a customer chooses to do their own management of abuse handling for their assigned address space you simply create the ORGANISATION and abuse ROLE objects for this customer and add the "org:" reference to this customers assignment. The RIPE NCC will provide a tool for doing this in a single step. If the customer changes their mind again and no longer wishes to handle the abuse themselves, you simply remove the "org:" reference from their assignment. Abuse handling returns to the LIR by default. The ORGANISATION and ROLE object will be deleted by the RIPE Database's automated cleanup process, after a short time, if no longer referenced anywhere else. Regards Denis Walker Business Analyst RIPE NCC Database Group On 05/12/2012 09:59, Alessandro Vesely wrote: > On Tue 04/Dec/2012 17:11:28 +0100 Denis Walker wrote: >> >> If each of your customers is a separate business (even if it is an >> individual) who will be doing much of the management themselves, >> including handling any abuse complaints for their assigned address >> space, then you need a bit more setup. > > I think that the general case is that some customers just want to get > connected while some others want to manage abuse. Customers may > change their mind after some time, of course. Wasn't the design > supposed to ease overriding the abuse handling object at will? > > From brian.nisbet at heanet.ie Wed Dec 5 18:14:14 2012 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Wed, 05 Dec 2012 17:14:14 +0000 Subject: [anti-abuse-wg] Implementation of 2011-06 Message-ID: <50BF80E6.3060908@heanet.ie> Colleagues, Hopefully by now you have all read the mail from the NCC Database Group regarding the implementation plan for Policy 2011-06 sent on the 15th of November 2012. The Co-Chairs of the Anti-Abuse and Database WGs have conferred and we feel that while there have been a few questions regarding this plan, these have been answered and there were no objections so consensus has been reached in this regard. With this support from the community in mind, the Co-Chairs have asked the NCC to begin work on this implementation and to keep both WGs updated on their progress. As always, if you have any questions, please do raise them on the mailing lists. Brian, On behalf of the Co-Chairs of the AA-WG & DB-WG From tim at haitabu.net Fri Dec 7 10:24:14 2012 From: tim at haitabu.net (Tim Kleefass) Date: Fri, 07 Dec 2012 10:24:14 +0100 Subject: [anti-abuse-wg] [db-wg] RIPE NCC's proposed implementation of Abuse Contact Management in the RIPE Database In-Reply-To: <50BE20B0.8050302@ripe.net> References: <20121116160307.GA18018@bongo.bofh.it> <50BE0BEC.9070902@haitabu.net> <50BE20B0.8050302@ripe.net> Message-ID: <50C1B5BE.4020505@haitabu.net> Hi Denis, On 04.12.2012 5:11 PM, Denis Walker wrote: > If each of your customers is a separate business (even if it is an > individual) who will be doing much of the management themselves, > including handling any abuse complaints for their assigned address > space, then you need a bit more setup. > > As we said in the implementation plan we are trying to move the RIPE > Database in the direction of modelling the real world setup. This may > require a little more initial setup, but in the end will be easier for > everyone to understand and follow. So if each of your customers is an > organisation handling it's own abuse, creating an ORGANISATION object > for them as a reference point with an abuse ROLE object, shows they > manage resources or have some role within this management. We will > provide tools to assist in the setting up of this data. This will > simplify your workload and avoid the need for you to enter information > twice. Thank you for your explanation. My "mileage" would prefer a smaller setup without an organisation object, but if this (more) general solution fits more people lets go. Cheers, Tim From gert at space.net Mon Dec 10 14:42:33 2012 From: gert at space.net (Gert Doering) Date: Mon, 10 Dec 2012 14:42:33 +0100 Subject: [anti-abuse-wg] [db-wg] RIPE NCC's proposed implementation of Abuse Contact Management in the RIPE Database In-Reply-To: <50BF1D81.2040408@ripe.net> References: <20121116160307.GA18018@bongo.bofh.it> <50BE0BEC.9070902@haitabu.net> <50BE20B0.8050302@ripe.net> <50BF0CD5.9070107@tana.it> <50BF1D81.2040408@ripe.net> Message-ID: <20121210134233.GH88969@Space.Net> Hi, On Wed, Dec 05, 2012 at 11:10:09AM +0100, Denis Walker wrote: > If at some point a customer chooses to do their own management of abuse > handling for their assigned address space you simply create the > ORGANISATION and abuse ROLE objects for this customer and add the "org:" > reference to this customers assignment. I'm not sure if I find this "simple", to be honest. Being able to specify an abuse-c: in the ASSIGNED inet(6)num: object, and having the RIPE DB software honour that on queries - that is: not go to the allocation's org->abuse-c - would require less objects to be created, and thus, less effort and less opportunity for confusion. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From denis at ripe.net Tue Dec 11 12:21:46 2012 From: denis at ripe.net (Denis Walker) Date: Tue, 11 Dec 2012 12:21:46 +0100 Subject: [anti-abuse-wg] [db-wg] RIPE NCC's proposed implementation of Abuse Contact Management in the RIPE Database In-Reply-To: <20121210134233.GH88969@Space.Net> References: <20121116160307.GA18018@bongo.bofh.it> <50BE0BEC.9070902@haitabu.net> <50BE20B0.8050302@ripe.net> <50BF0CD5.9070107@tana.it> <50BF1D81.2040408@ripe.net> <20121210134233.GH88969@Space.Net> Message-ID: <50C7174A.6020100@ripe.net> Dear Gert and other colleagues, After some off list clarification we see the point you are concerned with. The simplest case where an organisation manages all the abuse for all customers is easy to understand. In the real world this organisation has one or more internet resources and within the organisation there is a function (or role) that handles abuse complaints. So a real world picture is clear. Taking a member organisation as an example: member organisation / \ / \ internet abuse resources role This maps exactly to the new RIPE Database model: member ORGANISATION object / \ / \ INET(6)NUM member abuse objects ROLE object It is easy to see how to find the abuse handling role for any of these internet resources. The problem appears to be with the vision of what happens lower down in a network. After years of modifications the data model of the RIPE Database no longer reflects the real world. The relationships between objects are less than optimal. If you try to think of anything in terms of RIPE Database objects and relationships, it is not always obvious or clear. The implementation of the abuse-c proposal takes one small step to bringing the RIPE Database model closer to reflecting the real world, as outlined in the Database Groups presentation at RIPE 65. When a customer wants to handle abuse for their part of a network, they are taking over part of the management of that internet resource. In reality the customer's situation is the same as the member's. member ORGANISATION object / \ / \ INET(6)NUM abuse objects ROLE object / \ / \ / \ customer ORGANISATION object / \ / \ / \ / \ other INET(6)NUM customer abuse customers object ROLE object INET(6)NUM objects By including the customers ORGANISATION object the same structure is modelled at any level. This is the basic structure of any organisation that manages internet resources. So now it is easy to see how to find this customers abuse handling role and also how to find the abuse handling role for any of the other customers. This structure can be repeated as many times as necessary at any point in a network. We don't have abuse contacts hanging off different object types. The principle of finding the abuse contact is always the same. That is what makes the model simple in all cases. Internet resources includes AUT-NUM objects as well, and an organisation can have multiple top level INET(6)NUM objects, but to keep the diagram simple I ignored them. I hope this helps to explain the reasoning behind this model. To help with practical administration the RIPE NCC will provide some easy to use tools initially so a customers details only need to be entered once and appropriate objects will be created and the references made. To remove this setup for a specific customer just delete the reference to the ORGANISATION object. The extended garbage cleanup process will delete any cluster of ORGANISATION, MNTNER, ROLE, PERSON objects that are unused. We will also provide more extensive tools for managing changes to contact data at any level across multiple objects. Regards, Denis Walker Business Analyst RIPE NCC Database Group On 10/12/2012 14:42, Gert Doering wrote: > Hi, > > On Wed, Dec 05, 2012 at 11:10:09AM +0100, Denis Walker wrote: >> If at some point a customer chooses to do their own management of abuse >> handling for their assigned address space you simply create the >> ORGANISATION and abuse ROLE objects for this customer and add the "org:" >> reference to this customers assignment. > > I'm not sure if I find this "simple", to be honest. > > Being able to specify an abuse-c: in the ASSIGNED inet(6)num: object, > and having the RIPE DB software honour that on queries - that is: not > go to the allocation's org->abuse-c - would require less objects to be > created, and thus, less effort and less opportunity for confusion. > > Gert Doering > -- NetMaster > From gilles.massen at restena.lu Thu Dec 13 10:54:49 2012 From: gilles.massen at restena.lu (Gilles Massen) Date: Thu, 13 Dec 2012 10:54:49 +0100 Subject: [anti-abuse-wg] [db-wg] RIPE NCC's proposed implementation of Abuse Contact Management in the RIPE Database In-Reply-To: <50C7174A.6020100@ripe.net> References: <20121116160307.GA18018@bongo.bofh.it> <50BE0BEC.9070902@haitabu.net> <50BE20B0.8050302@ripe.net> <50BF0CD5.9070107@tana.it> <50BF1D81.2040408@ripe.net> <20121210134233.GH88969@Space.Net> <50C7174A.6020100@ripe.net> Message-ID: <50C9A5E9.3070700@restena.lu> Dear Denis, On 12/11/2012 12:21 PM, Denis Walker wrote: > When a customer wants to handle abuse for their part of a network, they > are taking over part of the management of that internet resource. In > reality the customer's situation is the same as the member's. > > member ORGANISATION object > / \ > / \ > INET(6)NUM abuse > objects ROLE object > / \ > / \ > / \ customer ORGANISATION object > / \ / \ > / \ / \ > other INET(6)NUM customer abuse > customers object ROLE object > INET(6)NUM > objects There is one thing that worries me with the setup: if I understood you correctly the appropriate (only?) way to remove a specific customer abuse object (and let the parent LIR handle abuses) is to remove the customer organisation object. However this would create a strong dependency between the org and the abuse object: if another object would be created that relies on the org object (like abuse-c does), you would link its existence to the presence of an abuse-c - appropriate/wanted or not. You could circumvent this limitation by adapting the logic so that not each org object needs an abuse-c, but somewhere up the tree you need an abuse-c, even if the 'closest' org hasn't one. Parsing wouldn't get easier, though. Best regards, Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473 From denis at ripe.net Thu Dec 13 11:35:34 2012 From: denis at ripe.net (Denis Walker) Date: Thu, 13 Dec 2012 11:35:34 +0100 Subject: [anti-abuse-wg] [db-wg] RIPE NCC's proposed implementation of Abuse Contact Management in the RIPE Database In-Reply-To: <50C9A5E9.3070700@restena.lu> References: <20121116160307.GA18018@bongo.bofh.it> <50BE0BEC.9070902@haitabu.net> <50BE20B0.8050302@ripe.net> <50BF0CD5.9070107@tana.it> <50BF1D81.2040408@ripe.net> <20121210134233.GH88969@Space.Net> <50C7174A.6020100@ripe.net> <50C9A5E9.3070700@restena.lu> Message-ID: <50C9AF76.3010202@ripe.net> Dear Gilles, Yes you are absolutely correct. I was outlining a simplistic example where the only part of resource management the customer handled was abuse. In this case, if they no longer handled their own abuse there would perhaps be no need for any of these objects. In which case the easiest way to clean up would be to remove the reference to the ORGANISATION object and the database garbage collector would remove the unreferenced objects. But of course there may be other reasons why a customer needs an ORGANISATION object. In these ORGANISATION objects with "org-type: OTHER" the "abuse-c:" reference is optional. So when looking for the most appropriate abuse handler, the database logic will work up the hierarchy looking for the first ORGANISATION object with an abuse contact referenced. Thanks for pointing this out. Regards Denis Walker Business Analyst RIPE NCC Database Group On 13/12/2012 10:54, Gilles Massen wrote: > Dear Denis, > > On 12/11/2012 12:21 PM, Denis Walker wrote: >> When a customer wants to handle abuse for their part of a network, they >> are taking over part of the management of that internet resource. In >> reality the customer's situation is the same as the member's. >> >> member ORGANISATION object >> / \ >> / \ >> INET(6)NUM abuse >> objects ROLE object >> / \ >> / \ >> / \ customer ORGANISATION object >> / \ / \ >> / \ / \ >> other INET(6)NUM customer abuse >> customers object ROLE object >> INET(6)NUM >> objects > > There is one thing that worries me with the setup: if I understood you > correctly the appropriate (only?) way to remove a specific customer > abuse object (and let the parent LIR handle abuses) is to remove the > customer organisation object. However this would create a strong > dependency between the org and the abuse object: if another object would > be created that relies on the org object (like abuse-c does), you would > link its existence to the presence of an abuse-c - appropriate/wanted or > not. > > You could circumvent this limitation by adapting the logic so that not > each org object needs an abuse-c, but somewhere up the tree you need an > abuse-c, even if the 'closest' org hasn't one. Parsing wouldn't get > easier, though. > > Best regards, > Gilles > > From ops.lists at gmail.com Mon Dec 31 16:51:45 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 31 Dec 2012 21:21:45 +0530 Subject: [anti-abuse-wg] Fwd: GeekTools Whois Proxy and RIPE/RIPE-NCC In-Reply-To: <71BEAB45-2AC4-4573-BF20-35B6BAB1B119@centergate.com> References: <71BEAB45-2AC4-4573-BF20-35B6BAB1B119@centergate.com> Message-ID: Bad move. I find geektools very useful for abuse mitigation and it is my hope that this is reconsidered Happy New Year --srs (htc one x) ---------- Forwarded message ---------- From: "Rodney Joffe" Date: 31-Dec-2012 9:15 PM Subject: GeekTools Whois Proxy and RIPE/RIPE-NCC To: Cc: NANOG and ARIN Friends, 14 Years ago, at the suggestion of Jon Postel and some of the early participants in NANOG, we developed the GeekTools Whois proxy to make it easier for *us* - network security and abuse techs - to deal with the expanding number of gtlds and registrars and the varied whois servers that were appearing. The service had both a CLI and web interface. The service also led directly to the creation of whois-servers.net, which now seems to be part of a number of *nix distributions. The service has been up for 14 years, and over that time we have fulfilled the requirements of all of the whois server operators in regards to minimizing and stopping abuse of the GT whois proxy by domain scrapers, spammers, etc, while enabling the security folks to do their jobs. In some cases we have even written code to pass the ip address of the requestor to the whois server registry operator when they wanted to manage quota's directly. We think we have a really good relationship with all of the whois server operators, and I think we provide a useful service to the community, and is widely used. And in 14 years we have never been tarred as an enabler of abuse of "the whois" system. There has obviously never been any kind of charge or fee for using the proxy, or any of the other tools on GeekTools. In about 2002 we started placing a banner ad on the web interface page to offset some of the costs for the bandwidth that the proxy consumes. An average of about $70 a month for over the last 10 years. Actual bandwidth costs are higher than that of course, but it was a thought in 2002 that we had frankly forgotten about until recently. Two weeks ago RIPE-NCC, who provide the whois data for IP addresses in the RIPE region, informed us that based on decisions by their members, as of January 1st 2013, tomorrow, they would no longer provide whois proxy query response services to GeekTools unless we ponied up $1,800 a year for RIPE membership. I don't work very well above layer 7. It is what it is. So I wanted to let you know that as of midnight tonight, apparently, you won't be able to use GeekTools for RIPE related queries. If you have automated scripts, and you are one of the users who has expanded access to GeekTools, you'll need to find an alternative for RIPE queries *today*. My guess is that you will be able to query RIPE directly, once you have worked out that the address space is within RIPE's assignments. I think its wrong to have to pay for whois data that is part of a community resource . So I won't do it. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 210 bytes Desc: not available URL: