[db-wg] Geolocation data prototype in the RIPE Database

The simple truth is that geolocation data for IP addresses is already available in some form, but there is no authoritative method of mapping an IP address to a location or a language. This causes location and language based web services to be error prone. Some of you have said that this inaccuracy and obscurity is a good thing, but others just want a more reliable system and reduce end user frustration and complaints.

For example, IP address space which was returned to the RIPE NCC and redistributed to another LIR is often subject to location or language related problems for their end users: content providers present them with the wrong language, or access to location restricted content (such as BBC iPlayer) is blocked. For some countries such as Belgium and Switzerland, there is no way at all to know or specify in which language content should be presented. 

With this in mind, what better way than to hand the power to authoritatively specify the usage location and language of an IP address block to its legitimate holder. We can leave it up to third parties to create databases based on fancy data mining, but this is proven to be problematic as illustrated earlier. The reliance on this kind of data is only increasing, and with IPv6 in the mix data quality is certainly not improving.

I would like to emphasise that the Database department did not launch the geolocation prototype on a whim and the usage is completely optional. I am sure that you can come up with various examples where entering this information in the current prototype doesn't cover a particular use case; in fact you already have. Of course there are quite a number of things we should add and change to the functionality before thinking about rolling this into the production database. 

As far as privacy goes, third parties will always attempt to geolocate an IP address as close to the user as possible. It's up to you if you enter anything in the RIPE Database at all and if you do, the granularity is completely in your hands.

The implementation and maintenance complexity for our larger members will of course be higher but I doubt that should mean we don't offer it to anyone, even if it's easy for others to enter and maintain and it solves their problems. The current implementation is a starting point for discussion and it would be great if we could talk about how the prototype could be developed and evolved to make it as easy, useful and accurate as possible for everyone interested, and alleviates the concerns that were raised.

Regards,

Alex Band