[db-wg] country codes in the RIPE Database (was: ORGANISATION country code)

HI Cynthia

On Thu, 2 Mar 2023 at 17:43, Cynthia Revström via db-wg <db-wg at ripe.net> wrote:
>
> Hi db-wg,
>
> I just want to start out by saying that I support efforts to try to better understand and document this.
> What I don't (currently) support is changing DB policy (policy in the form of RIPE documents or policy enforced by the RIPE DB software), especially before we really know much about the impact.
>
> I think it is rather obvious that some forms of country codes in the RIPE DB are very likely to have an impact on GeoIP data in some cases at least.

Yes, some of the country codes (cc) in the database are likely to have
an impact on GeoIP. Some people have entered cc to reflect GeoIP,
others have not. But we don't know which is which. So using any cc
from the database is as likely to be wrong as right.

> Additionally, as I think we all are painfully aware of, a lot of online services are restricted or change their behaviour based on GeoIP data.
> If I can use the country attribute in an inet(6)num or organisation object to potentially correct some invalid GeoIP data then I am probably going to want to use that. (Assuming I have no better options)

This approach simply won't work. (btw some of the approaches I have
suggested in this thread won't work either, but we are getting a
clearer picture as we discuss it.) You cannot correct invalid GeoIP
with more invalid data that was never intended to be used for GeoIP.
You are just moving a block of IP addresses from one wrong location to
a different wrong location.

>
> I have actually been casually experimenting a bit with this for almost 3 years now and I can say for sure that there are major online services that utilize the country attribute in inetnum objects for GeoIP data. (I don't know if they do it directly or if they get it from a third party, but that is not really relevant.)
> It's a bit of a tangent, but you can see one of the amusing effects of this in a post[1] on the r/Steam subreddit from when someone on there discovered that my network was supposedly the largest ISP in Antarctica according to Steam's statistics.

This example is exactly why maintaining uncertain data for unknown
reasons in the database is both wrong and misleading. The fact that
you can say for sure that 'major online services' use data in a way
that the RIPE NCC has spent 20+ years telling people not to do, is why
we do need to take some action.

>
> I agree that this is by no means an ideal situation we are in.
> However, we also shouldn't make life more difficult for the people working at ISPs who have IP space that is being misidentified by GeoIP databases.
> While large ISPs might be able to go to the GeoIP databases or content providers and tell them to fix their data, this doesn't really work for small ISPs (as far as I know).
> In the long term we will hopefully not have any need for these country attributes and everything that relies on GeoIP will just use geofeeds but currently that is not the case.
>
> I don't think that it is a good idea to focus on country codes in the database at the moment. I think that we instead need to look at GeoIP and the sources that are being used as a whole.
> It is a big and messy thing and it will not just be a quick NWI but I think it is what we have to do if we want to deal with this.

I agree we need to look in more detail if Geolocation using the RIPE
Database is best served with (and maybe only with) the new "geofeed:"
attribute or if a "geo-country:" attribute may be useful as well. But
I think the best and only solution to the misuse and misunderstanding
of the "country:" attribute in INET(6)NUM objects is to deprecate it.
As Leo pointed out, if we try to define it now after 20+ years the
message will not reach many users. To continue allowing it's
(confused) existence at a time when geo fencing is becoming a
politically and socially sensitive issue, is simply making the
situation worse than it has ever been. Maybe by deprecating it we will
achieve what you suggested above by focusing people's minds on what is
needed in the RIPE Database for geolocation rather than spending time
trying to fix the unfixable.

cheers
denis
co-chair DB-WG


>
> Finally I just want to say that ideally (in my opinion) we would ideally not need to care about GeoIP at all but sadly I don't think that is going away anytime soon, so we have to be pragmatic about it.
>
> [1]: https://www.reddit.com/r/Steam/comments/gilapa/pretty_good_transfer_rate_for_antarctica_weird/
>
> P.S. This email is not really a reply to any specific email in this thread but rather just a summary of my current take on this. I am also sorry for the rather long and rambly email, but I felt like I needed to summarize my thoughts on this so that people can correct me if I am wrong about anything or if something that I think is obvious is in fact not obvious.
>
> -Cynthia
>
> On Thu, Mar 2, 2023 at 12:53 PM Sylvain Baya via db-wg <db-wg at ripe.net> wrote:
>>
>> Dear RIPE DB-WG,
>>
>> Hoping that this email finds you in good health!
>> Please see my comments below, inline...
>>
>> Thanks.
>>
>> Le lundi 20 février 2023, Leo Vegoda via db-wg <db-wg at ripe.net> a écrit :
>>>
>>>
>>> > [...]
>>> >
>>> > With clear explanations sent to all resource holders and/or maintainers of
>>> > the resource objects, I think we could get this message out there.
>>>
>>> Setting semantics aside... I don't know whether changing definitions —
>>> and adding a missing definition is a de facto change — would improve
>>> things or make them worse.
>>>
>>>
>>
>> Hi Leo,
>>
>> Thanks for your email, brother.
>>
>> ...imho! it should be obvious that no one know :-/
>>
>> However, i think we could first separate two goals:
>>
>> G1. Documentation improvement
>>
>> G2. Behaviour improvement
>>
>>
>>>
>>>
>>> What research do we have to support the
>>> position that it would be an improvement?
>>>
>>
>> ...while proceeding, as suggested above, i think we
>> would not, absolutely, need a research in order to
>> choose a common/consensual direction.
>>
>> For G1. we could simply answer the following questions:
>>
>> target="DB documentation"
>>
>> Q1.1 Do we need to improve $target?
>>
>> Q1.2 Do we want to do it?
>>
>> Q1.3 Can we obviously expect to succeed?
>>
>> ...imho!
>> Yes! (Q1.1) | Maybe! (Q1.2) | Yes! (Q.1.3)
>>
>> For G2. we could simply answer the following questions:
>>
>> target="user/admin behaviour"
>>
>> Q2.1=Q1.1
>>
>> Q2.2=Q1.2
>>
>> Q2.3=Q1.3
>>
>> ...imho!
>> Yes! (Q2.1) | Maybe! (Q2.2) | No! (Q2.3)
>>
>> If you try to follow my reasoning; then you might
>> conclude that "influencing the average behaviour"
>> is a task that the outcomes/results are too difficult
>>  to predict.
>>
>> In general, the result would stay as bad as it's
>> actually (20 years after)...
>>
>> ...but, imho, i couldn't recommend to a book writer
>> to stop writing useful books; simply because there
>> is clear evidences that "people do not actually like
>>  to read, as they prefer to watch videos".
>>
>> Time to read is different than time to write...a book
>> can wait its readers & meet them after a long time.
>>
>> :-)
>>
>> Shalom,
>> --sb.
>>
>>
>>>
>>> Kind regards,
>>>
>>> Leo
>>> [...]
>>
>>
>>
>> --
>>
>> Best Regards !
>> __
>> baya.sylvain[AT cmNOG DOT cm]|<https://cmnog.cm/dokuwiki/Structure>
>> Subscribe to Mailing List: <https://lists.cmnog.cm/mailman/listinfo/cmnog/>
>> __
>> #‎LASAINTEBIBLE‬|#‎Romains15‬:33«Que LE ‪#‎DIEU‬ de ‪#‎Paix‬ soit avec vous tous! ‪#‎Amen‬!»
>> ‪#‎MaPrière‬ est que tu naisses de nouveau. #Chrétiennement‬
>> «Comme une biche soupire après des courants d’eau, ainsi mon âme soupire après TOI, ô DIEU!»(#Psaumes42:2)
>>
>> --
>>
>> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/
>
> --
>
> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/