From BSanghani at relianceglobalcom.com Fri Oct 2 14:41:03 2009 From: BSanghani at relianceglobalcom.com (Sanghani, Bijal) Date: Fri, 2 Oct 2009 13:41:03 +0100 Subject: [ncc-services-wg] RE: RIPE NCC Services Working Group - Draft Agenda - Updated Message-ID: <894E33C514C87642AE1B768DE35570EC034AB0@LON-EX2K3.RGCOM.COM> Please see below Updated Draft Agenda for the NCC Services Working Group - A. Administrative Matters * Welcome * Select a scribe * Jabber Monitor * Microphone Etiquette * Approve Minutes from RIPE 58 * Finalise agenda B. RIPE NCC Update - Axel Pawlik, RIPE NCC (30 minutes) C. Contractual Relationship Requirement for End Users - Andrea Cima, RIPE NCC (15 minutes) D. Certification Update, Alex Band, RIPE NCC E. Discussion about inet(6)num and aut-num objects to reference sponsoring LIR - Piotr Strzyzewski (10 mins) F. Recovering resources assigned to non-existing entities - Uwe Manuel Rasmussen (10 mins) G. Open Microphone Session Z. A.O.B. Regards, Bijal The information contained in this e-mail message is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you should return it to the sender immediately. Please note that while we scan all e-mails for viruses we cannot guarantee that any e-mail is virus-free and accept no liability for any damage caused by any virus transmitted by this email. The information contained in this e-mail message is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you should return it to the sender immediately. Please note that while we scan all e-mails for viruses we cannot guarantee that any e-mail is virus-free and accept no liability for any damage caused by any virus transmitted by this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From unread at ripe.net Fri Oct 2 15:18:51 2009 From: unread at ripe.net (Axel Pawlik) Date: Fri, 02 Oct 2009 15:18:51 +0200 Subject: [ncc-services-wg] IPv6 Assignment to RIPE NCC Message-ID: <4AC5FDBB.1010609@ripe.net> Dear Colleagues, Following the approval of Policy Proposal 2009-02, "Allocating/Assigning Resources to the RIPE NCC", the RIPE NCC requested that an IPv6 PI assignment be assigned to it for RIPE Meetings. The RIPE NCC pool of arbiters decided, based on RIPE Policy Document ripe-476, ?Allocating/Assigning Resources to the RIPE NCC", that the request met the criteria for the assignment of PI IPv6. For more information on the RIPE NCC's initial request to the arbiters, and details of the arbiters' decision, see: http://www.ripe.net/info/ncc/ipv6-pi-request-to-arbiters.pdf For more information on the arbiters, see: http://www.ripe.net/membership/arbitration.html Best regards, The Arbitration panel and Axel Pawlik Managing Director RIPE NCC From BSanghani at relianceglobalcom.com Tue Oct 6 19:28:26 2009 From: BSanghani at relianceglobalcom.com (Sanghani, Bijal) Date: Tue, 6 Oct 2009 18:28:26 +0100 Subject: [ncc-services-wg] RE: RIPE NCC Services Working Group - Draft Agenda - Updated Message-ID: <894E33C514C87642AE1B768DE35570EC034AD2@LON-EX2K3.RGCOM.COM> Please see below Updated Draft Agenda for the NCC Services Working Group - A. Administrative Matters * Welcome * Select a scribe * Jabber Monitor * Microphone Etiquette * Approve Minutes from RIPE 58 * Finalise agenda B. RIPE NCC Update - Axel Pawlik, RIPE NCC C. Contractual Relationship Requirement for End Users - Andrea Cima, RIPE NCC D. Certification Update, Alex Band, RIPE NCC E. Discussion about inet(6)num and aut-num objects to reference sponsoring LIR - Piotr Strzyzewski F. 2007-01 implementation survey. Discussion - Piotr Strzyzewski G. Recovering resources assigned to non-existing entities - Uwe Manuel Rasmussen I. Registration Data Quality Update - Robert Kisteleki H. Open Microphone Session Z. A.O.B. Regards, Bijal The information contained in this e-mail message is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you should return it to the sender immediately. Please note that while we scan all e-mails for viruses we cannot guarantee that any e-mail is virus-free and accept no liability for any damage caused by any virus transmitted by this email. The information contained in this e-mail message is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you should return it to the sender immediately. Please note that while we scan all e-mails for viruses we cannot guarantee that any e-mail is virus-free and accept no liability for any damage caused by any virus transmitted by this email. The information contained in this e-mail message is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you should return it to the sender immediately. Please note that while we scan all e-mails for viruses we cannot guarantee that any e-mail is virus-free and accept no liability for any damage caused by any virus transmitted by this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncc at ripe.net Thu Oct 8 09:42:59 2009 From: ncc at ripe.net (Nathalie Trenaman) Date: Thu, 08 Oct 2009 09:42:59 +0200 Subject: [ncc-services-wg] Proposal to Remove Routing Requirements from the IPv6 Address Allocation Policy Implemented Message-ID: <4ACD9803.9030301@ripe.net> Dear Colleagues, We are pleased to announce that policy proposal 2000-06,"Removing Routing Requirements from the IPv6 Address Allocation Policy", has been implemented. The RIPE NCC is now ready to accept requests for IPv6 address space under the new policy. This proposal can be found at: http://www.ripe.net/ripe/policies/proposals/2009-06.html The updated "IPv6 Address Allocation and Assignment Policy" document is available at: http://www.ripe.net/ripe/docs/ripe-481.html The following FAQ has also been updated to reflect this policy implementation: http://www.ripe.net/info/faq/rs/ipv6.html Regards, Nathalie Trenaman Registration Services RIPE NCC From denis at ripe.net Thu Oct 22 15:30:27 2009 From: denis at ripe.net (Denis Walker) Date: Thu, 22 Oct 2009 15:30:27 +0200 Subject: [ncc-services-wg] New rules for reverse domain object creation in the RIPE Database Message-ID: <4AE05E73.7000903@ripe.net> Dear Colleagues, [Apologies for duplicate emails] A proposal has just been sent to the DNS Working Group (DNS WG) mailing list about additional checks on creating reverse delegation DOMAIN objects. If you wish to comment, please do so on the DNS WG mailing list. This will keep any discussion concentrated in a single thread. Regards, Denis Walker Business Analyst, Database Group RIPE NCC From vegard at monsternett.no Tue Oct 27 14:17:46 2009 From: vegard at monsternett.no (Vegard Svanberg) Date: Tue, 27 Oct 2009 14:17:46 +0100 Subject: [ncc-services-wg] IP geolocation services Message-ID: <20091027131746.GZ2582@svanberg.no> We've recently experienced a storm of customer complaints after starting to use IP addresses from a new allocation/assignment. The IP block was earlier in use by a German company. The result is that services like Google and Yahoo assume users are from Germany and presents content accordingly. Some users have also reported that they are excluded from certain services. A quick web search reveals that this is a pretty common problem. While not blaming RIPE or the other RIRs, we believe this problem should be addressed, and that the initiative has to come from the RIRs. I would like to propose that RIPE NCC works together with other RIRs to see if it's possible to implement procedures/routines to notify providers and users of IP geolocation services of new, relocated and deleted allocations. Also, one should probably consider if it's a need for a (distributed?) database with more fine-grained location data than the whois database currently provides (also, I've been told that licensing issues prohibits geolocation providers from using the RIR DBs directly, but I've not been able to verify this). Apologies in advance if this has been discussed before -- I searched the archive, but got no hits. -- -o) Vegard Svanberg, CTO - Monsternett (www.monsternett.no) /\\ Violgata 3A, N-1776 HALDEN, NORWAY _\_v Phone: (+47) 69701802 | Fax: (+47) 69701801 From Woeber at CC.UniVie.ac.at Tue Oct 27 17:18:41 2009 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 27 Oct 2009 16:18:41 +0000 Subject: [ncc-services-wg] IP geolocation services In-Reply-To: <20091027131746.GZ2582@svanberg.no> References: <20091027131746.GZ2582@svanberg.no> Message-ID: <4AE71D61.3050100@CC.UniVie.ac.at> With my DB-WG Chair hat on: Trying to - with reasonable accuracy - deduct geo-location-info for a particular end-system using a particualr address, at a particular point in time, from a block registered in a particular RIR's DB as an assignment is very bad idea to begin with. At least for the RIPE-DB, there are no agreed or definend semantics for the interpretation of the country: attribute. The data is a hint, at best. Actually, the country codes entered could point to the home country of a particular LIR's administrative location, to the location of the responsible NOC (operating from abroad) or something altogether, completely, arbitrary. Also, there are the codes "ZZ" and "EU", neither of which is clearly defined regarding its meaning. Just to fill in some background: a while ago we had the discussion in the DB-WG proposing to completely remove the country attribute for the reasons given. However, we received input that requested the country data to be kept, but *purely* for statistical reasons! It was understood that the accuracy and quality of that sort of data is just good enough exclusively for *that* pupose - but not really for something else and least for basing operational decisions on! Now, taking off my DB-WG hat.... My personal feeling is that the RIRs' databases are definitely the wrong place to maintain such (volatile) data (in many cases for subranges of registry entries!) and the RIRs are the wrong organisatins to get involved with such a "service". And, to top it off, with mobile users and tunnels, the whole concept of managing access to data or services based on an IP address is going to brake more often than it does already ;-) Wilfried Vegard Svanberg wrote: > We've recently experienced a storm of customer complaints after starting > to use IP addresses from a new allocation/assignment. The IP block was > earlier in use by a German company. The result is that services like > Google and Yahoo assume users are from Germany and presents content > accordingly. Some users have also reported that they are excluded from > certain services. > > A quick web search reveals that this is a pretty common problem. > > While not blaming RIPE or the other RIRs, we believe this problem should > be addressed, and that the initiative has to come from the RIRs. > > I would like to propose that RIPE NCC works together with other RIRs to > see if it's possible to implement procedures/routines to notify > providers and users of IP geolocation services of new, relocated and > deleted allocations. > > Also, one should probably consider if it's a need for a (distributed?) > database with more fine-grained location data than the whois database > currently provides (also, I've been told that licensing issues prohibits > geolocation providers from using the RIR DBs directly, but I've not been > able to verify this). > > Apologies in advance if this has been discussed before -- I searched the > archive, but got no hits. > From pk at DENIC.DE Tue Oct 27 17:36:01 2009 From: pk at DENIC.DE (Peter Koch) Date: Tue, 27 Oct 2009 17:36:01 +0100 Subject: [ncc-services-wg] IP geolocation services In-Reply-To: <4AE71D61.3050100@CC.UniVie.ac.at> References: <20091027131746.GZ2582@svanberg.no> <4AE71D61.3050100@CC.UniVie.ac.at> Message-ID: <20091027163601.GG90910@unknown.office.denic.de> Wilfried, > particular end-system using a particualr address, at a particular point in > time, from a block registered in a particular RIR's DB as an assignment is > very bad idea to begin with. > > At least for the RIPE-DB, there are no agreed or definend semantics for > the interpretation of the country: attribute. The data is a hint, at best. agreed, but the problem in question is not necessarily related to the RIPE DB being used as source of the geolocation information. What seems to be desirable is some notification of changes when a certain address block is unassigned or, more importantly, reassigned. This doesn't have to provide the new location information, but should initiate a new run of the location magic for this address range, so the GeoLoc provider knows when to update/refresh which information. Of course, we know similar demands from the domain business and these requests aren't all free of concern, but the situation might be different here in the addressing world. -Peter From vegard at monsternett.no Tue Oct 27 18:36:46 2009 From: vegard at monsternett.no (Vegard Svanberg) Date: Tue, 27 Oct 2009 18:36:46 +0100 Subject: [ncc-services-wg] IP geolocation services In-Reply-To: <4AE71D61.3050100@CC.UniVie.ac.at> References: <20091027131746.GZ2582@svanberg.no> <4AE71D61.3050100@CC.UniVie.ac.at> Message-ID: <20091027173646.GC2582@svanberg.no> * Wilfried Woeber, UniVie/ACOnet [2009-10-27 17:18]: > My personal feeling is that the RIRs' databases are definitely the wrong > place to maintain such (volatile) data (in many cases for subranges of > registry entries!) and the RIRs are the wrong organisatins to get involved > with such a "service". While I would probably agree that the RIRs databases would be the wrong place to maintain the data, and that the RIRs probably shouldn't provide this service directly, I do think it's important that the RIRs try to establish some standards regarding notifications and updates. This seems to be a pretty common problem today, and most probably even more so in the future, as the usage of geo-location services for sure will increase, and the number of ISPs/organizations who will either have to renumber and/or receive additional IP blocks previously allocated to someone else, will increase. -- -o) Vegard Svanberg, CTO - Monsternett (www.monsternett.no) /\\ Violgata 3A, N-1776 HALDEN, NORWAY _\_v Phone: (+47) 69701802 | Fax: (+47) 69701801 From jim at rfc1035.com Tue Oct 27 19:07:49 2009 From: jim at rfc1035.com (Jim Reid) Date: Tue, 27 Oct 2009 18:07:49 +0000 Subject: [ncc-services-wg] IP geolocation services In-Reply-To: <20091027163601.GG90910@unknown.office.denic.de> References: <20091027131746.GZ2582@svanberg.no> <4AE71D61.3050100@CC.UniVie.ac.at> <20091027163601.GG90910@unknown.office.denic.de> Message-ID: <1450DF57-8934-4612-89BF-DD0C309AD5D7@rfc1035.com> On 27 Oct 2009, at 16:36, Peter Koch wrote: > What seems > to be desirable is some notification of changes when a certain address > block is unassigned or, more importantly, reassigned. This doesn't > have to provide the new location information, but should initiate a > new > run of the location magic for this address range, so the GeoLoc > provider > knows when to update/refresh which information. This presumes that GeoLoc providers will always take the trouble to check for these changes and act on them, neither of which seems likely. From Woeber at CC.UniVie.ac.at Tue Oct 27 20:06:40 2009 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 27 Oct 2009 19:06:40 +0000 Subject: [ncc-services-wg] IP geolocation services In-Reply-To: <20091027163601.GG90910@unknown.office.denic.de> References: <20091027131746.GZ2582@svanberg.no> <4AE71D61.3050100@CC.UniVie.ac.at> <20091027163601.GG90910@unknown.office.denic.de> Message-ID: <4AE744C0.10207@CC.UniVie.ac.at> Hi Peter! Peter Koch wrote: > Wilfried, > > >>particular end-system using a particualr address, at a particular point in >>time, from a block registered in a particular RIR's DB as an assignment is >>very bad idea to begin with. >> >>At least for the RIPE-DB, there are no agreed or definend semantics for >>the interpretation of the country: attribute. The data is a hint, at best. > > > agreed, but the problem in question is not necessarily related to the > RIPE DB being used as source of the geolocation information. What seems > to be desirable is some notification of changes when a certain address > block is unassigned or, more importantly, reassigned. Well, we actually do have that mechanism in place: the registry database. It offers a granularity of (legacy, plus) allocations to LIRs and the assignments from within the PA blocks. In principle, this data should be reasonably accurate and should be maintained regularly. I presume at least the allocations, being maintained by the RIR should be pretty reliable? >From within the blocks, that's a different story maybe... But it should remain a scan and pull-technology by those who want to read and consume the data. I am not convinced that a notification service for everyone and her dog would be scalable? > This doesn't > have to provide the new location information, but should initiate a new > run of the location magic for this address range, so the GeoLoc provider > knows when to update/refresh which information. For some situations this could be a couple of times per hour, for mobile devices ;-) Other than that I'd suggest a frequency of once per day to pick up the new information. > Of course, we know similar demands from the domain business and these > requests aren't all free of concern, but the situation might be different > here in the addressing world. Yep, I think the discussion is useful, at least to start to understand what the expectations, the reality and the boundary conditions are! I always get back to see that resource distribution for the IP-world, for the Internet was never taking (volatile) national boundaries into account, neither on the administrative nor on the operational level. Maybe the parties trying to use geo-location to control access to information and (licensed) services should also start to accept that fact for their business model? > -Peter Wilfried. From vegard at monsternett.no Tue Oct 27 23:07:48 2009 From: vegard at monsternett.no (Vegard Svanberg) Date: Tue, 27 Oct 2009 23:07:48 +0100 Subject: [ncc-services-wg] IP geolocation services In-Reply-To: References: Message-ID: <20091027220748.GF22393@svanberg.no> * Arkley, Patrick [2009-10-27 21:57]: > I think this should be addressed to the companies using Geolocation > technics. Not the the RIR's nor the LIR's. Well, of course. And note that noone are blaming the RIRs. But as you've experienced yourself, it's not easy being an ISP or LIR and discussing this directly. Most of the time, at least from my experience, you won't even get a decent answer. The RIRs should consider establishing communication channels with at least the major GeoIP service providers, but preferably also to major service providers relying on geo-location, like Google, Yahoo etc. It should be in their own interest that this info is as accurate as possible, so I believe they will listen if the party bringing this up is big enough and have suggestions on how this can be done efficiently. I'm having difficulties seeing who else than the RIRs would be best suited to coordinate this work. If this becomes wild west (well, it is already), ISP A's business in, say, Britain could be seriously impacted because the RIR allocated an IP block perviously used in Italy to the LIR. ISP A lose customers to ISP B and gets a lot of negative headlines because the customers can access from ISP B, but not from ISP A. The customers and journalists don't care who's to blame, and ISP A has no tool to control the situation, and in worst case it won't be fixed it in a long time. In my opinion, this is a very serious matter and must be treated accordingly. -- -o) Vegard Svanberg, CTO - Monsternett (www.monsternett.no) /\\ Violgata 3A, N-1776 HALDEN, NORWAY _\_v Phone: (+47) 69701802 | Fax: (+47) 69701801 From patrick.arkley at se.verizonbusiness.com Tue Oct 27 21:57:42 2009 From: patrick.arkley at se.verizonbusiness.com (Arkley, Patrick) Date: Tue, 27 Oct 2009 21:57:42 +0100 Subject: [ncc-services-wg] IP geolocation services Message-ID: Hi. I think this should be addressed to the companies using Geolocation technics. Not the the RIR's nor the LIR's. We have had these issues with Google and has seeked answers from them on numerous occasions on how they do their Geolocation stuff. No respons what so ever. We tried to accomodate the customer wishes by changing the country of the Inetnum (violating our internal policies on how an Inetnum should be set up) but it didn't work of course. As long as they are not interested in discussing this I don't think the RIR's should do anything in their db's or change how they work the db. The users suffering should turn to Google, Yahoo or whatever the company using geolocation and complain. Not to the LIR nor to the RIR. Rgds Patrick Arkley European Hostmaster Verizon ** sent from mobile device ** ----- Original Message ----- From: ncc-services-wg-admin at ripe.net To: Vegard Svanberg Cc: ncc-services-wg at ripe.net Sent: Tue Oct 27 17:18:41 2009 Subject: Re: [ncc-services-wg] IP geolocation services With my DB-WG Chair hat on: Trying to - with reasonable accuracy - deduct geo-location-info for a particular end-system using a particualr address, at a particular point in time, from a block registered in a particular RIR's DB as an assignment is very bad idea to begin with. At least for the RIPE-DB, there are no agreed or definend semantics for the interpretation of the country: attribute. The data is a hint, at best. Actually, the country codes entered could point to the home country of a particular LIR's administrative location, to the location of the responsible NOC (operating from abroad) or something altogether, completely, arbitrary. Also, there are the codes "ZZ" and "EU", neither of which is clearly defined regarding its meaning. Just to fill in some background: a while ago we had the discussion in the DB-WG proposing to completely remove the country attribute for the reasons given. However, we received input that requested the country data to be kept, but *purely* for statistical reasons! It was understood that the accuracy and quality of that sort of data is just good enough exclusively for *that* pupose - but not really for something else and least for basing operational decisions on! Now, taking off my DB-WG hat.... My personal feeling is that the RIRs' databases are definitely the wrong place to maintain such (volatile) data (in many cases for subranges of registry entries!) and the RIRs are the wrong organisatins to get involved with such a "service". And, to top it off, with mobile users and tunnels, the whole concept of managing access to data or services based on an IP address is going to brake more often than it does already ;-) Wilfried Vegard Svanberg wrote: > We've recently experienced a storm of customer complaints after starting > to use IP addresses from a new allocation/assignment. The IP block was > earlier in use by a German company. The result is that services like > Google and Yahoo assume users are from Germany and presents content > accordingly. Some users have also reported that they are excluded from > certain services. > > A quick web search reveals that this is a pretty common problem. > > While not blaming RIPE or the other RIRs, we believe this problem should > be addressed, and that the initiative has to come from the RIRs. > > I would like to propose that RIPE NCC works together with other RIRs to > see if it's possible to implement procedures/routines to notify > providers and users of IP geolocation services of new, relocated and > deleted allocations. > > Also, one should probably consider if it's a need for a (distributed?) > database with more fine-grained location data than the whois database > currently provides (also, I've been told that licensing issues prohibits > geolocation providers from using the RIR DBs directly, but I've not been > able to verify this). > > Apologies in advance if this has been discussed before -- I searched the > archive, but got no hits. > Verizon Sweden AB - registrerat i Sverige med organisationsnummer 556489-1009? huvudkontorets adress: Arm?gatan 38, Box 4127, 171 04 Solna, Sverige -------------- next part -------------- An HTML attachment was scrubbed... URL: From ip-office at kpn.com Wed Oct 28 08:39:45 2009 From: ip-office at kpn.com (IP-Office KPN) Date: Wed, 28 Oct 2009 08:39:45 +0100 Subject: [ncc-services-wg] IP geolocation services In-Reply-To: References: Message-ID: I could not agree more. With kind regards, Andries Hettema IP-Office KPN Internet +31 (0)70 45 13398 ip-office at kpn.com Hi. I think this should be addressed to the companies using Geolocation technics. Not the the RIR's nor the LIR's. We have had these issues with Google and has seeked answers from them on numerous occasions on how they do their Geolocation stuff. No respons what so ever. We tried to accomodate the customer wishes by changing the country of the Inetnum (violating our internal policies on how an Inetnum should be set up) but it didn't work of course. As long as they are not interested in discussing this I don't think the RIR's should do anything in their db's or change how they work the db. The users suffering should turn to Google, Yahoo or whatever the company using geolocation and complain. Not to the LIR nor to the RIR. Rgds Patrick Arkley European Hostmaster Verizon ** sent from mobile device ** ----- Original Message ----- From: ncc-services-wg-admin at ripe.net To: Vegard Svanberg Cc: ncc-services-wg at ripe.net Sent: Tue Oct 27 17:18:41 2009 Subject: Re: [ncc-services-wg] IP geolocation services With my DB-WG Chair hat on: Trying to - with reasonable accuracy - deduct geo-location-info for a particular end-system using a particualr address, at a particular point in time, from a block registered in a particular RIR's DB as an assignment is very bad idea to begin with. At least for the RIPE-DB, there are no agreed or definend semantics for the interpretation of the country: attribute. The data is a hint, at best. Actually, the country codes entered could point to the home country of a particular LIR's administrative location, to the location of the responsible NOC (operating from abroad) or something altogether, completely, arbitrary. Also, there are the codes "ZZ" and "EU", neither of which is clearly defined regarding its meaning. Just to fill in some background: a while ago we had the discussion in the DB-WG proposing to completely remove the country attribute for the reasons given. However, we received input that requested the country data to be kept, but *purely* for statistical reasons! It was understood that the accuracy and quality of that sort of data is just good enough exclusively for *that* pupose - but not really for something else and least for basing operational decisions on! Now, taking off my DB-WG hat.... My personal feeling is that the RIRs' databases are definitely the wrong place to maintain such (volatile) data (in many cases for subranges of registry entries!) and the RIRs are the wrong organisatins to get involved with such a "service". And, to top it off, with mobile users and tunnels, the whole concept of managing access to data or services based on an IP address is going to brake more often than it does already ;-) Wilfried Vegard Svanberg wrote: > We've recently experienced a storm of customer complaints after starting > to use IP addresses from a new allocation/assignment. The IP block was > earlier in use by a German company. The result is that services like > Google and Yahoo assume users are from Germany and presents content > accordingly. Some users have also reported that they are excluded from > certain services. > > A quick web search reveals that this is a pretty common problem. > > While not blaming RIPE or the other RIRs, we believe this problem should > be addressed, and that the initiative has to come from the RIRs. > > I would like to propose that RIPE NCC works together with other RIRs to > see if it's possible to implement procedures/routines to notify > providers and users of IP geolocation services of new, relocated and > deleted allocations. > > Also, one should probably consider if it's a need for a (distributed?) > database with more fine-grained location data than the whois database > currently provides (also, I've been told that licensing issues prohibits > geolocation providers from using the RIR DBs directly, but I've not been > able to verify this). > > Apologies in advance if this has been discussed before -- I searched the > archive, but got no hits. > Verizon Sweden AB - registrerat i Sverige med organisationsnummer 556489-1009- huvudkontorets adress: Arm?gatan 38, Box 4127, 171 04 Solna, Sverige -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidm at futureinquestion.net Wed Oct 28 08:55:15 2009 From: davidm at futureinquestion.net (David Monosov) Date: Wed, 28 Oct 2009 08:55:15 +0100 Subject: [ncc-services-wg] IP geolocation services In-Reply-To: <20091027131746.GZ2582@svanberg.no> References: <20091027131746.GZ2582@svanberg.no> Message-ID: <4AE7F8E3.9060108@futureinquestion.net> Dear Vegard, Vegard Svanberg wrote: > > I would like to propose that RIPE NCC works together with other RIRs to > see if it's possible to implement procedures/routines to notify > providers and users of IP geolocation services of new, relocated and > deleted allocations. > The RIPE NCC whois database is available as a daily dump over FTP in a format suitable for bulk text processing. This should serve as a sufficient "notification mechanism" that meets your requirements, and I would expect that any organization that makes it its business to provide GeoIP information to paying customers would be aware of its existence and actively utilizing it to this end. One of the GeoIP providers (MaxMind) provides a free low-resolution GeoIP database called CeoLiteCountry which happens to also be packaged by many *nix distributions due to its liberal license. Being free, it is much more widely used by content providers than commercial offerings. Unfortunately, being a static database rather than a service, the accuracy of the information contained in it depends on a fairly long chain of custody which includes MaxMind (that presently updates it once a month, vs. their commercial offering which is updated weekly), the various distribution packagers (the geoip-database package in the current Ubuntu release, for example, contains data which dates to March 2002), and individual system administrators which make use of it. A problem no notification mechanism can address. > > Apologies in advance if this has been discussed before -- I searched the > archive, but got no hits. > I'm not sure if this is something the RIPE NCC or this work group should, or even could, solve. -- Respectfully yours, David Monosov From marcoh at marcoh.net Wed Oct 28 09:29:30 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 28 Oct 2009 09:29:30 +0100 Subject: [ncc-services-wg] IP geolocation services In-Reply-To: <20091027163601.GG90910@unknown.office.denic.de> References: <20091027131746.GZ2582@svanberg.no> <4AE71D61.3050100@CC.UniVie.ac.at> <20091027163601.GG90910@unknown.office.denic.de> Message-ID: On Oct 27, 2009, at 5:36 PM, Peter Koch wrote: > Wilfried, > >> particular end-system using a particualr address, at a particular >> point in >> time, from a block registered in a particular RIR's DB as an >> assignment is >> very bad idea to begin with. >> >> At least for the RIPE-DB, there are no agreed or definend semantics >> for >> the interpretation of the country: attribute. The data is a hint, >> at best. > > agreed, but the problem in question is not necessarily related to the > RIPE DB being used as source of the geolocation information. What > seems > to be desirable is some notification of changes when a certain address > block is unassigned or, more importantly, reassigned. This doesn't > have to provide the new location information, but should initiate a > new > run of the location magic for this address range, so the GeoLoc > provider > knows when to update/refresh which information. > > Of course, we know similar demands from the domain business and these > requests aren't all free of concern, but the situation might be > different > here in the addressing world. Address blocks are quarantined for a while when they are returned, so I guess that anybody who regularly checks the database should notice they went missing and this could be a nice hint that those addresses aren't in use anymore and any data associated with it should be removed. Or are you proposing more of a push system in which the RIR tries to find and notify those people who collect these data to notify them there have been changes. A third solution would be to publish a sort of BOGON list which contains all unallocated blocks in s machine parseable format, this might even be usefull for other purposes as well, but I can aleady think of two problems: First of all there is a risk that people built filters based on this list and those might not get updated again, so we try and debogonize space forever instead just once when the /8 comes down from IANA, secondly if people are starting to use this list as a way to generate filters we again create some form of 'off button' for the internet and that might give people the wrng idea that the NCC in fact can do something about abuse or other "illegal" activities (I use quotes here because it's hard to define the term in an international situation, what may be illegal in your eyes migth be perfectly legal in other parts of the world). I can think of option 1 happening, in fact that mechanism is there, option 2 (push) is almost impossible to achieve and I don't like option 3 at all. Grtx, Marco From konradpl at zt.piotrkow.tpsa.pl Wed Oct 28 09:57:09 2009 From: konradpl at zt.piotrkow.tpsa.pl (konradpl at zt.piotrkow.tpsa.pl) Date: Wed, 28 Oct 2009 09:57:09 +0100 (CET) Subject: [ncc-services-wg] IP geolocation services In-Reply-To: References: Message-ID: Hi, Because of the reasons stated below LIR's databases seems not to be perfect place to store geolocalization information. First of all IP block may be distibuted among different countries. Secondly information in database isn't updated along with network topology changes - in real cooperation with growing CDN solutions it should be updated along with every network topology change (even along with links failures). It seems that BGP is the only answer for the problem. Within my network I use geographic communities to feed CDN network with information about current network topology. Why not to use this idea in global scale: We could propose new RFC and agree that there is reserved community ASN:xxyy ASN advertising ASN number xx is global comunity number for geolocalization yy is countrycode The only problem is to have global acceptance for xx as reserved community number and time needed for deployment in majority of networks. Konrad Plich On Tue, 27 Oct 2009, Arkley, Patrick wrote: > Hi. > > I think this should be addressed to the companies using Geolocation technics. Not the the RIR's nor the LIR's. > We have had these issues with Google and has seeked answers from them on numerous occasions on how they do their Geolocation stuff. No respons what so ever. > We tried to accomodate the customer wishes by changing the country of the Inetnum (violating our internal policies on how an Inetnum should be set up) but it didn't work of course. > > As long as they are not interested in discussing this I don't think the RIR's should do anything in their db's or change how they work the db. > > The users suffering should turn to Google, Yahoo or whatever the company using geolocation and complain. Not to the LIR nor to the RIR. > > Rgds > > Patrick Arkley > European Hostmaster > Verizon > ** sent from mobile device ** > > ----- Original Message ----- > From: ncc-services-wg-admin at ripe.net > To: Vegard Svanberg > Cc: ncc-services-wg at ripe.net > Sent: Tue Oct 27 17:18:41 2009 > Subject: Re: [ncc-services-wg] IP geolocation services > > With my DB-WG Chair hat on: > > Trying to - with reasonable accuracy - deduct geo-location-info for a > particular end-system using a particualr address, at a particular point in > time, from a block registered in a particular RIR's DB as an assignment is > very bad idea to begin with. > > At least for the RIPE-DB, there are no agreed or definend semantics for > the interpretation of the country: attribute. The data is a hint, at best. > > Actually, the country codes entered could point to the home country of a > particular LIR's administrative location, to the location of the responsible > NOC (operating from abroad) or something altogether, completely, arbitrary. > Also, there are the codes "ZZ" and "EU", neither of which is clearly defined > regarding its meaning. > > Just to fill in some background: a while ago we had the discussion in the > DB-WG proposing to completely remove the country attribute for the reasons > given. However, we received input that requested the country data to be > kept, but *purely* for statistical reasons! It was understood that the > accuracy and quality of that sort of data is just good enough exclusively > for *that* pupose - but not really for something else and least for basing > operational decisions on! > > Now, taking off my DB-WG hat.... > > My personal feeling is that the RIRs' databases are definitely the wrong > place to maintain such (volatile) data (in many cases for subranges of > registry entries!) and the RIRs are the wrong organisatins to get involved > with such a "service". > > And, to top it off, with mobile users and tunnels, the whole concept of > managing access to data or services based on an IP address is going to brake > more often than it does already ;-) > > Wilfried > > Vegard Svanberg wrote: > >> We've recently experienced a storm of customer complaints after starting >> to use IP addresses from a new allocation/assignment. The IP block was >> earlier in use by a German company. The result is that services like >> Google and Yahoo assume users are from Germany and presents content >> accordingly. Some users have also reported that they are excluded from >> certain services. >> >> A quick web search reveals that this is a pretty common problem. >> >> While not blaming RIPE or the other RIRs, we believe this problem should >> be addressed, and that the initiative has to come from the RIRs. >> >> I would like to propose that RIPE NCC works together with other RIRs to >> see if it's possible to implement procedures/routines to notify >> providers and users of IP geolocation services of new, relocated and >> deleted allocations. >> >> Also, one should probably consider if it's a need for a (distributed?) >> database with more fine-grained location data than the whois database >> currently provides (also, I've been told that licensing issues prohibits >> geolocation providers from using the RIR DBs directly, but I've not been >> able to verify this). >> >> Apologies in advance if this has been discussed before -- I searched the >> archive, but got no hits. >> > > > > > Verizon Sweden AB - registrerat i Sverige med organisationsnummer 556489-1009?? huvudkontorets adress: Arm?gatan 38, Box 4127, 171 04 Solna, Sverige > From jim at rfc1035.com Wed Oct 28 10:13:02 2009 From: jim at rfc1035.com (Jim Reid) Date: Wed, 28 Oct 2009 09:13:02 +0000 Subject: [ncc-services-wg] IP geolocation services In-Reply-To: References: Message-ID: On 28 Oct 2009, at 08:57, konradpl at zt.piotrkow.tpsa.pl wrote: > It seems that BGP is the only answer for the problem. Nope. Every IP address (or /24) could have a LOC record associated with it. That could work the same way as a reverse DNS lookup. That said, I think this WG could develop a "Geolocation info from RIR databases (or DNS) considered harmful" RIPE document. IMO there's no need for an RFC or cleverness with ASNs. From marcoh at marcoh.net Wed Oct 28 10:24:13 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 28 Oct 2009 10:24:13 +0100 Subject: [ncc-services-wg] IP geolocation services In-Reply-To: References: Message-ID: > That said, I think this WG could develop a "Geolocation info from > RIR databases (or DNS) considered harmful" RIPE document. IMO > there's no need for an RFC or cleverness with ASNs. I think you just wrote it :) Really there isn't much more to say unless you actually want to work on solving the problem, we might consider adding it to the database disclaimer or manual. Grtx, Marco From heldal at eml.cc Wed Oct 28 10:46:14 2009 From: heldal at eml.cc (Per Heldal) Date: Wed, 28 Oct 2009 10:46:14 +0100 Subject: [ncc-services-wg] IP geolocation services In-Reply-To: <20091027220748.GF22393@svanberg.no> References: <20091027220748.GF22393@svanberg.no> Message-ID: <4AE812E6.3020303@eml.cc> The importance of geolocation wrt many end-user-services is well understood, but you're missing the point. Geolocation is not an attribute in the RIRs DBs, nor can the RIRs be held responsible for 3rd parties use of the data for unintended purposes. The country-attribute may say something about the location of the LIRs administrative HQ, but nothing prevents a particular prefix from being used somewhere else, or even across many different countries world-wide. What you're asking for would require new policies that place specific requirements on LIRs to register and maintain inetnum-objects for subnets consistent with national borders. //per From konradpl at zt.piotrkow.tpsa.pl Wed Oct 28 10:57:39 2009 From: konradpl at zt.piotrkow.tpsa.pl (konradpl at zt.piotrkow.tpsa.pl) Date: Wed, 28 Oct 2009 10:57:39 +0100 (CET) Subject: [ncc-services-wg] IP geolocation services In-Reply-To: References: Message-ID: I do agree that we can put as many records to the database as we want. Problem is in usabilility (BGP feed is easier to deal with on CDN platforms) and first of all speed - with BGP you can follow automaticly every change in network topology while separate database needs manual intervention. Konrad Plich On Wed, 28 Oct 2009, Jim Reid wrote: > On 28 Oct 2009, at 08:57, konradpl at zt.piotrkow.tpsa.pl wrote: > >> It seems that BGP is the only answer for the problem. > > Nope. > > Every IP address (or /24) could have a LOC record associated with it. That > could work the same way as a reverse DNS lookup. > > That said, I think this WG could develop a "Geolocation info from RIR > databases (or DNS) considered harmful" RIPE document. IMO there's no need for > an RFC or cleverness with ASNs. > > From heldal at eml.cc Wed Oct 28 11:04:53 2009 From: heldal at eml.cc (Per Heldal) Date: Wed, 28 Oct 2009 11:04:53 +0100 Subject: [ncc-services-wg] IP geolocation services In-Reply-To: References: Message-ID: <4AE81745.1030300@eml.cc> On 10/28/2009 09:57 AM, konradpl at zt.piotrkow.tpsa.pl wrote: > Why not to use this idea in global scale: We could propose new RFC and > agree that there is reserved community ASN:xxyy > ASN advertising ASN number > xx is global comunity number for geolocalization > yy is countrycode > > The only problem is to have global acceptance for xx as reserved > community number and time needed for deployment in majority of networks. > aggregation? //per From konradpl at zt.piotrkow.tpsa.pl Wed Oct 28 11:22:23 2009 From: konradpl at zt.piotrkow.tpsa.pl (konradpl at zt.piotrkow.tpsa.pl) Date: Wed, 28 Oct 2009 11:22:23 +0100 (CET) Subject: [ncc-services-wg] IP geolocation services In-Reply-To: <4AE81745.1030300@eml.cc> References: <4AE81745.1030300@eml.cc> Message-ID: On Wed, 28 Oct 2009, Per Heldal wrote: > On 10/28/2009 09:57 AM, konradpl at zt.piotrkow.tpsa.pl wrote: >> Why not to use this idea in global scale: We could propose new RFC and >> agree that there is reserved community ASN:xxyy >> ASN advertising ASN number >> xx is global comunity number for geolocalization >> yy is countrycode >> >> The only problem is to have global acceptance for xx as reserved >> community number and time needed for deployment in majority of networks. >> > > aggregation? No change - if you today advertise prefix you will still advertise it with the same mask. The only change is that geocommunity will be added. If you today advertise more specific prefix from different country you will add different geocommunity to show to the world that origin country for the whole less specific from LIR database is not applicable to it. Konrad Plich From dave.wilson at heanet.ie Wed Oct 28 11:17:47 2009 From: dave.wilson at heanet.ie (Dave Wilson) Date: Wed, 28 Oct 2009 10:17:47 +0000 Subject: [ncc-services-wg] IP geolocation services In-Reply-To: <20091027173646.GC2582@svanberg.no> References: <20091027131746.GZ2582@svanberg.no> <4AE71D61.3050100@CC.UniVie.ac.at> <20091027173646.GC2582@svanberg.no> Message-ID: <4AE81A4B.7050809@heanet.ie> Vegard Svanberg wrote: > While I would probably agree that the RIRs databases would be the wrong > place to maintain the data, and that the RIRs probably shouldn't provide > this service directly, I do think it's important that the RIRs try to > establish some standards regarding notifications and updates. This is something which could be applied to any third party service that classifies IP addresses in some way - including, say, abuse blacklists. I assume that the problem will also ramp up in intensity after IPv4 depletion, if the address space does indeed fragment due to transfers. Acknowledging that the RIRs can't solve the problem and we need to stimulate third parties to take action, I think that if we can make this work then you have a very strong incentive to use RIR-approved transfer procedures instead of the black market. (In fact, it's a great example of the usefulness of RIRs as the authoritative source of this information.) If we really believe that the tools to do this already exist, perhaps we have a need for a BCP document on detecting updates? All the best, Dave -- Dave Wilson, Senior Network Engineer HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +353-1-660 9040 fax: +353-1-660 3666 web: http://www.heanet.ie/ H323 GDS:0035301101738 PGP: 1024D/C757ADA9 HEAnet National Networking Conference http://www.heanet.ie/conferences/2009/ From heldal at eml.cc Wed Oct 28 11:41:03 2009 From: heldal at eml.cc (Per Heldal) Date: Wed, 28 Oct 2009 11:41:03 +0100 Subject: [ncc-services-wg] IP geolocation services In-Reply-To: References: <4AE81745.1030300@eml.cc> Message-ID: <4AE81FBF.1090405@eml.cc> On 10/28/2009 11:22 AM, konradpl at zt.piotrkow.tpsa.pl wrote: >> aggregation? > > No change - if you today advertise prefix you will still advertise it > with the same mask. The only change is that geocommunity will be added. > > If you today advertise more specific prefix from different country you > will add different geocommunity to show to the world that origin country > for the whole less specific from LIR database is not applicable to it. > > Konrad Plich And how will those networks who only see my aggregate be able to know the exact location of all my specifics? What you're suggesting is just one more incomplete source of information from which geoloc services can try to collect some coherent information (along with dns and inetnum-db). I read this thread as a request to help provide guaranteed accurate geoloc info, and BGP isn't the place for that. //per From jim at rfc1035.com Wed Oct 28 11:42:27 2009 From: jim at rfc1035.com (Jim Reid) Date: Wed, 28 Oct 2009 10:42:27 +0000 Subject: [ncc-services-wg] IP geolocation services In-Reply-To: References: Message-ID: <64EFE57C-FBB8-44C1-AC46-C2C8E170AB56@rfc1035.com> On 28 Oct 2009, at 09:24, Marco Hogewoning wrote: > I think you just wrote it :) Cool! > Really there isn't much more to say unless you actually want to work > on solving the problem Well, I suppose this mythical "Geolocation info from RIR databases considered harmful" document could explain the main reasons why that's the case. From vegard at monsternett.no Wed Oct 28 12:53:21 2009 From: vegard at monsternett.no (Vegard Svanberg) Date: Wed, 28 Oct 2009 12:53:21 +0100 Subject: [ncc-services-wg] IP geolocation services In-Reply-To: <4AE812E6.3020303@eml.cc> References: <20091027220748.GF22393@svanberg.no> <4AE812E6.3020303@eml.cc> Message-ID: <20091028115321.GR22393@svanberg.no> * Per Heldal [2009-10-28 10:46]: > The importance of geolocation wrt many end-user-services is well > understood, but you're missing the point. Geolocation is not an > attribute in the RIRs DBs, nor can the RIRs be held responsible for > 3rd parties use of the data for unintended purposes. I've not said that. Please don't put words in my mouth. > What you're asking for would require new policies that place specific > requirements on LIRs to register and maintain inetnum-objects for > subnets consistent with national borders. I've not said or asked for that, either. -- -o) Vegard Svanberg, CTO - Monsternett (www.monsternett.no) /\\ Violgata 3A, N-1776 HALDEN, NORWAY _\_v Phone: (+47) 69701802 | Fax: (+47) 69701801 From michael.dillon at bt.com Wed Oct 28 14:40:15 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 28 Oct 2009 13:40:15 -0000 Subject: [ncc-services-wg] FW: [ipv6-wg] Publication of default assignment sizes for end-user network ? Message-ID: <28E139F46D45AF49A31950F88C49745803C8B0DC@E03MVZ2-UKDY.domain1.systemhost.net> You might want to have a look at this idea as a way to kill two birds with one stone. -----Original Message----- From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of michael.dillon at bt.com Sent: 28 October 2009 13:38 To: ipv6-wg at ripe.net Subject: RE: [ipv6-wg] Publication of default assignment sizes for end-user network ? > Now this does not forbid you to register individual assignments into > the public database, but doing so poses various problems. Not only the > sheer number of assignments can be a problem, but also keeping that > registration up-to-date will have serious impact on your day to day > operations and especially with residential users there might be > privacy issues as well. If we would have a distributed database protocol to extend the RIPE database into the LIRs, then this would not be an issue. I'm thinking of something like DNS. For instance, if I need to look up data on three /48s in fdb8:e914::/32 I would first send a lookup request to RIPE. The RIPE db would tell me that all data for fdb8:e914::/32 is in a server at fdb8:e914::dbdb. I would cache that information, and send my first lookup request to the distributed server. After getting my reply, I would prepare to send the second request for fdb8:e914:c20f::/48, notice that the /32 is already in my cache, and use the cached server instead. This is roughly the way DNS lookups work with the result that the detailed data does not have to be kept in one central location. I would like to see the RIPE db move in the same direction. At the same time, I would like to see the spec opened up a bit so that the distributed server operators would be free to add additional attributes to existing objects, and additional objects so that there is the possibility of using the same distributed lookup mechanism for geographic or language identifications as well. --Michael Dillon From konradpl at zt.piotrkow.tpsa.pl Wed Oct 28 14:56:19 2009 From: konradpl at zt.piotrkow.tpsa.pl (konradpl at zt.piotrkow.tpsa.pl) Date: Wed, 28 Oct 2009 14:56:19 +0100 (CET) Subject: [ncc-services-wg] IP geolocation services In-Reply-To: <4AE81FBF.1090405@eml.cc> References: <4AE81745.1030300@eml.cc> <4AE81FBF.1090405@eml.cc> Message-ID: On Wed, 28 Oct 2009, Per Heldal wrote: > On 10/28/2009 11:22 AM, konradpl at zt.piotrkow.tpsa.pl wrote: > >>> aggregation? >> >> No change - if you today advertise prefix you will still advertise it >> with the same mask. The only change is that geocommunity will be added. >> >> If you today advertise more specific prefix from different country you >> will add different geocommunity to show to the world that origin country >> for the whole less specific from LIR database is not applicable to it. >> >> Konrad Plich > > And how will those networks who only see my aggregate be able to know the > exact location of all my specifics? If you do not avertise somewhere your more specyfic mens that prfix do not need different treatment than your global less specyfic. I can't imagine situation when you want part of your network to be routed in the same way like the rest of the network and at the same time to have different CDN that will be feeding it because of geolocation. > > What you're suggesting is just one more incomplete source of information from > which geoloc services can try to collect some coherent information (along > with dns and inetnum-db). I read this thread as a request to help provide > guaranteed accurate geoloc info, and BGP isn't the place for that. > BGP is the most coherent protocol with real reason of dividing traffic: different location=different traffic flow. BGP shows traffic flow and links state change. That is the information CDNs deserve. Additionaly it can be altered, is fast and automatic. Konrad Plich From daniel.karrenberg at ripe.net Wed Oct 28 17:03:49 2009 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 28 Oct 2009 17:03:49 +0100 Subject: [ncc-services-wg] IP geolocation services In-Reply-To: References: <20091027131746.GZ2582@svanberg.no> <4AE71D61.3050100@CC.UniVie.ac.at> <20091027163601.GG90910@unknown.office.denic.de> Message-ID: <20091028160349.GM58385@reiftel.karrenberg.net> On 28.10 09:29, Marco Hogewoning wrote: ... > I can think of option 1 happening, in fact that mechanism is there, Vergard (and others) found out this is not happening. > option 2 (push) is almost impossible to achieve agree > and I don't like option 3 at all. The RIRs are currently discussing an extended 'stats' file format that will include the "unallocated" address space. This waay ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest and similar files from other RIRs would include the unallocated address space as well. This way we aim to publish once a day a onsistent view about *all* address space. Once implemented this couldbe used as option 3. If it was useful we could add a "quarantined" flag to help. What do people think? Daniel From joao at bondis.org Wed Oct 28 17:08:43 2009 From: joao at bondis.org (=?iso-8859-1?Q?Jo=E3o_Damas?=) Date: Wed, 28 Oct 2009 17:08:43 +0100 Subject: [ncc-services-wg] IP geolocation services In-Reply-To: <20091028160349.GM58385@reiftel.karrenberg.net> References: <20091027131746.GZ2582@svanberg.no> <4AE71D61.3050100@CC.UniVie.ac.at> <20091027163601.GG90910@unknown.office.denic.de> <20091028160349.GM58385@reiftel.karrenberg.net> Message-ID: <0230D959-16F9-400F-9AD5-69218A1ED533@bondis.org> On 28 Oct 2009, at 17:03, Daniel Karrenberg wrote: > > The RIRs are currently discussing an extended 'stats' file format > that will include the "unallocated" address space. This waay > ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest > and similar files from other RIRs would include the unallocated > address > space as well. This way we aim to publish once a day a onsistent view > about *all* address space. Once implemented this couldbe used as > option > 3. If it was useful we could add a "quarantined" flag to help. > > What do people think? that would be really user(tm), including the quarantine flag, or whatever name you end up giving it Joao From daniel.karrenberg at ripe.net Wed Oct 28 17:09:53 2009 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 28 Oct 2009 17:09:53 +0100 Subject: [ncc-services-wg] IP geolocation services In-Reply-To: <4AE7F8E3.9060108@futureinquestion.net> References: <20091027131746.GZ2582@svanberg.no> <4AE7F8E3.9060108@futureinquestion.net> Message-ID: <20091028160953.GN58385@reiftel.karrenberg.net> On 28.10 08:55, David Monosov wrote: > > One of the GeoIP providers (MaxMind) provides a free low-resolution GeoIP > database called CeoLiteCountry ... Acually MaxMind are also providing city. You can see this in REX when using the "Geolocation" tab. This tool provides a year of history too, so you can check what Maxmind thinks o any block you may be about to start using. http://labs.ripe.net/content/rex-resource-explainer Daniel From marcoh at marcoh.net Wed Oct 28 17:28:13 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 28 Oct 2009 17:28:13 +0100 Subject: [ncc-services-wg] IP geolocation services In-Reply-To: <20091028160349.GM58385@reiftel.karrenberg.net> References: <20091027131746.GZ2582@svanberg.no> <4AE71D61.3050100@CC.UniVie.ac.at> <20091027163601.GG90910@unknown.office.denic.de> <20091028160349.GM58385@reiftel.karrenberg.net> Message-ID: <2C1EAFE0-F4B3-424A-BFBA-3A08EC07D3C0@marcoh.net> On Oct 28, 2009, at 5:03 PM, Daniel Karrenberg wrote: >> I can think of option 1 happening, in fact that mechanism is there, > > Vergard (and others) found out this is not happening. I noticed this, but then there is always the case of getting it idiot proof and finding a bigger idiot. >> option 2 (push) is almost impossible to achieve > > agree > >> and I don't like option 3 at all. > > The RIRs are currently discussing an extended 'stats' file format > that will include the "unallocated" address space. This waay > ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest > and similar files from other RIRs would include the unallocated > address > space as well. This way we aim to publish once a day a onsistent view > about *all* address space. Once implemented this couldbe used as > option > 3. If it was useful we could add a "quarantined" flag to help. > > What do people think? I think I already gave most of my concern and that is that we end up with a new bogon list and might have to go to extensive efforts do debogonize address space at very small blocks. Now that's not that different from the current issues people are having with the GEO-ip so I wonder if this would really solve the problem. Marco From Woeber at CC.UniVie.ac.at Fri Oct 30 02:21:05 2009 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 30 Oct 2009 01:21:05 +0000 Subject: [ncc-services-wg] IP geolocation services In-Reply-To: <20091028160349.GM58385@reiftel.karrenberg.net> References: <20091027131746.GZ2582@svanberg.no> <4AE71D61.3050100@CC.UniVie.ac.at> <20091027163601.GG90910@unknown.office.denic.de> <20091028160349.GM58385@reiftel.karrenberg.net> Message-ID: <4AEA3F81.4060804@CC.UniVie.ac.at> Daniel Karrenberg wrote: > On 28.10 09:29, Marco Hogewoning wrote: > > ... > > >>I can think of option 1 happening, in fact that mechanism is there, > > > Vergard (and others) found out this is not happening. > > >>option 2 (push) is almost impossible to achieve > > > agree > > >>and I don't like option 3 at all. > > > The RIRs are currently discussing an extended 'stats' file format > that will include the "unallocated" address space. This waay > ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest > and similar files from other RIRs would include the unallocated address > space as well. This way we aim to publish once a day a onsistent view > about *all* address space. Once implemented this couldbe used as option > 3. If it was useful we could add a "quarantined" flag to help. > > What do people think? I think that is a very laudable goal to achieve - in itself! It would conribute to the vision of having a unique or coordinated source for information about the status of resources on a global level; by just consulting one source/file/feed/list/you name it at an arbitrary point in time. One of the problems that I perceive as fundamental in the curent way that the set of Registries manages the global resource pool is the "regional concept". This starts at whois and maybe ends at geolocation. Btw, I am not saying that this should be changed, quite to the contrary. But it adds complexity to the system and makes it difficult to understand for the uninitiated ;-) That said, this list would offer just another means for the GL service providers to try and provide a better (more accurate, more up-to-date) service. At the same time it would not help in getting around the facts (of differnet kinds) that the management, the operations and logistics of the Internet are agnostic - by design - of national or regional geographic boundaries or numbering trees. > Daniel Wilfried From pk at DENIC.DE Sat Oct 31 16:40:21 2009 From: pk at DENIC.DE (Peter Koch) Date: Sat, 31 Oct 2009 16:40:21 +0100 Subject: [ncc-services-wg] IP geolocation services In-Reply-To: References: <20091027131746.GZ2582@svanberg.no> <4AE71D61.3050100@CC.UniVie.ac.at> <20091027163601.GG90910@unknown.office.denic.de> Message-ID: <20091031154021.GA32351@x27.adm.denic.de> On Wed, Oct 28, 2009 at 09:29:30AM +0100, Marco Hogewoning wrote: > Address blocks are quarantined for a while when they are returned, so > I guess that anybody who regularly checks the database should notice > they went missing and this could be a nice hint that those addresses > aren't in use anymore and any data associated with it should be removed. would that affect intra LIR assignment changes or just returns to the RIR? > Or are you proposing more of a push system in which the RIR tries to > find and notify those people who collect these data to notify them > there have been changes. I'd not say that the RIR should actively approach every GeoLoc provider but the RIR, or the RIPE community, to pick on the difference, could try to engage into dialogue, which I believe has been started already. This is not to end up with the location information in the RIPE DB which is unlikely to happen due to both technical (granularity) and business ("our heuristics'r'us") limitations(*). But getting the words out how address-to-user-bindings change might be a worthwhile goal. If possible, this would be an interesting presentation+discussion at an EOF plenary. > I can think of option 1 happening, in fact that mechanism is there, > option 2 (push) is almost impossible to achieve and I don't like > option 3 at all. Well, yes, share your concerns re:the "off" button. -Peter (*) There are services that use the RIR DBs, though. See for example the perl IP::Country module, which is quite useful. It's not so much that _all_ uses of DB data were bad, but the application needs to carefully select and understand the GeoLoc service's properties. An update once a year is OK if you just want to map log file excerpts to some map.