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 <[email protected]> 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 <[email protected]> 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://lists.ripe.net/mailman/listinfo/db-wg >
-- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
