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

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.
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)

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.

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.

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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/db-wg/attachments/20230302/cdbc3226/attachment-0001.html>