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

Hi Laurent

On Thu, 23 Mar 2023 at 12:45, Laurent Pellegrino
<laurent.pellegrino at ipregistry.co> wrote:
>
> Hi Denis, all,
>
> That's just my thought, but who can do the more can do the less. If an ISP prefers to publish country-level information only, that's possible with a geofeed.
>
> Personally, from what I see at Ipregistry, geofeed has only recently started to receive attention from companies, despite its existence for years. Introducing a geo-country attribute would add even more confusion and undermine the efforts put into geofeed. This would result in some people preferring to use the geo-country attribute, others using the geofeed attribute, still others using the geoloc attribute (and even some using the country attribute at inetnum level despite RIPE NCC has spent the last 20 years telling people they cannot rely on that attribute for IP location).
>
> And the worst part is when organizations use two or three of the aforementioned attributes at the same time with conflicting values. Yes, this really happens, often because people are unaware of the different attributes available for each RIR or because they update one but not the others. In such cases, it becomes unclear which attribute should be used, and the multitude of attributes available for geolocation purposes creates confusion.

This is a very good point.

>
> Again, this is a personal view, but I believe there should be a single attribute officially supported for geolocation purposes. Other attributes should be deprecated and removed after a transition period. As for which attribute to promote, that is another question. However, geofeed looks like a good candidate for multiple reasons, such as its flexibility, various levels of granularity, privacy awareness (compared to the geoloc attribute), and standardized format. This vision could one day allow all RIRs to converge on the same attribute, the purpose of which is clearly understood by all, leading to better and more accurate IP geolocation-related information for all.

I totally agree with you. My suggestion for a geo-country was really
just a conversation starter to try to get more people to say what they
really want. I think you summed it up well in this paragraph. If more
people can get behind this and EXPRESS their support we can move
forward and make some progress. We need to finalise the legal issues
over geofeed and get community agreement NOW to deprecate the
redundant attributes like "geoloc:" and "country:", after the
transition period.

SO if anyone supports the goal of a single, officially supported
attribute for geolocation purposes, later deprecating all the
others...please, please, please let us know. Then we can wrap this
issue up with a ToDo list and some time lines.

cheers
denis
co-chair DB-WG


>
> Kind regards,
> Laurent Pellegrino
>
> On Thu, Mar 23, 2023 at 11:57 AM denis walker via db-wg <db-wg at ripe.net> wrote:
>>
>> Hi Eric
>>
>> I appreciate your comment. It is good to know the views of new
>> subscribers. Let me throw a couple of points back to you and I would
>> be interested to know what you think.
>>
>> You suggested that geofeed may be the answer. But geofeed is just a
>> more precise location than say geo-country. It also allows for
>> specifying locations where a block of addresses are used in more than
>> one country. Maybe for many ISPs publishing the country level
>> information may be enough detail.
>>
>> From what you say it sounds like you have to provide lots of
>> information to geoIP aggregators to convince them their assertion is
>> wrong. Do you think this may be because they don't trust the country
>> attribute information currently available in INET(6)NUM objects? Maybe
>> they know the RIPE NCC has spent the last 20 years telling people they
>> cannot rely on that attribute for IP location, so geoIP aggregators
>> ignore it.
>>
>> Suppose for now we just leave the "country:" attribute alone. We don't
>> delete it, don't change it and don't try to redefine it. People can
>> continue to put whatever they want in there and other people can
>> believe (or not) what they want about what they see. The RIPE NCC will
>> continue to tell anyone who asks, that they cannot rely on that data
>> for any purpose. A completely hands off position, maintaining the
>> status quo.
>>
>> Now suppose we create a new optional attribute, say "geo-country:". It
>> can be used by resource holders, if you want to, to specify the
>> location where you say this whole block of addresses are used. We can
>> tell the geoIP aggregators that this geo-country data is a reliable
>> statement from the resource holder about where these addresses are
>> being used. Do you think that would help you as an ISP?
>>
>> We can invent all sorts of complex solutions like geofeed that will
>> address all situations. Then spend another year debating with the RIPE
>> NCC legal team about how to use it. Perhaps we can also do something
>> very simple like geo-country that may quickly improve the situation
>> for a large number of resource holders.
>>
>> cheers
>> denis
>> co-chair DB-WG
>>
>> On Fri, 10 Mar 2023 at 08:57, Delmas, Eric <edelmas at cogentco.com> wrote:
>> >
>> > Hi Denis,
>> >
>> > I am an IP Engineer at Cogent (ISP). I subscribed to this mailing list few months ago (sorry for being silent).
>> >
>> > One comment on your suggestion to delete the "country:" attribute in resource objects.
>> >
>> > When in the need to contact the GeoIP aggregators (MaxMind and others.) asking correction of some wrong data, I have to show some concrete information such as traceroute + registration re-assignment record. Geodeed if/when widely adopted may be the solution. In the meantime the "country:" attribute in INET(6)NUM object is helpful.
>> >
>> > Best regards
>> > Éric
>> >
>> > -----Original Message-----
>> > From: db-wg <db-wg-bounces at ripe.net> On Behalf Of denis walker via db-wg
>> > Sent: Wednesday, March 8, 2023 3:52 AM
>> > To: Leo Vegoda <leo at vegoda.org>
>> > Cc: RIPE Database WG <db-wg at ripe.net>; Havard Eidnes <he at uninett.no>; George Michaelson <ggm at algebras.org>
>> > Subject: Re: [db-wg] country codes in the RIPE Database (was: ORGANISATION country code)
>> >
>> > CAUTION: This email originated from an external sender! Do not click the links, open attachments or reply, unless you recognize/trust the sender's email address and know the content is safe!
>> >
>> >
>> >
>> > Hi Leo
>> >
>> > From my perspective as an analyst it's getting interesting now... Yes we can consider it as a complex problem needing a complex solution...but are either really complex? Maybe it is the environment that is complex and not this specific problem or solution.
>> >
>> > On Wed, 8 Mar 2023 at 01:29, Leo Vegoda <leo at vegoda.org> wrote:
>> > >
>> > > This mailing list. You said it.
>> > >
>> > > Lots of people from different types of organisations use data that
>> > > helps them without deep-diving into the communities that produce it.
>> >
>> > The community that produces this data doesn't dive very deep either.
>> >
>> > >
>> > > Half the problem is that the RIPE community has spent 20 years writing
>> > > documentation that is barely glanced at by developers who decide that
>> > > this data means what they want it to mean.
>> >
>> > And half of those developers who barely glance at this documentation are the ones whose developments create this data.
>> >
>> > >  But do people from the RIPE
>> > > community engage with the people who run GeoIP databases?
>> >
>> > Only a handful of the RIPE community engages with this mailing list, so I doubt many of them engage with GeoIP people about the RIPE Database.
>> >
>> > > How can we
>> > > complain that people misunderstand us if we don't actively engage with
>> > > them about what they need the data to mean?
>> >
>> > The difficulty here is defining 'people' and 'us' and the overlap and how and where active engagement could take place and where to publicise any outcome of such engagement that would make the outcome effective.
>> >
>> > The problem is simple:
>> > -"country:" in resource objects has never been defined -that fact is well documented in places no one reads -it is discussed in places creators and users of this data don't follow -it is a mandatory attribute so all resource objects must have this data -no one knows what the resource holders mean by it -no one knows what consumers perceive it to mean -by using it to influence geolocation we probably pollute the wider GeoIP data set -we have spent 20+ years telling people they can't use it for GeoIP but we know they still do -if we give it a definition now, many creators and consumers will never get the message
>> >
>> > So the solution is also simple
>> > -no registry data depends on it
>> > -no one can rely on it
>> > -it has no value in it's indeterminate state ---so delete it
>> >
>> > THEN we can have a discussion about what 'people' want 'us' to provide. Maybe a new, optional "geo-country:" attribute with a clear definition from the start and guidelines on usage, with a name that implies what it means even if you don't read anything about it. By deleting the current useless data we might get a few more people to join the discussion on how to move forward.
>> >
>> > But there is another interesting aspect to this. We had a lively discussion last year on "geofeed:". Lots of people from the community were involved in that discussion. Where are they now? This discussion has turned into a more general debate about the use of the RIPE Database for GeoIP purposes. Why were so many people so interested in "geofeed:" but avoid a more general geolocation discussion? Why are so few people publicly arguing for or against this use of the RIPE Database and how to do it? (...and one speaks as I am writing this
>> > email.)
>> >
>> > cheers
>> > denis
>> > co-chair DB-WG
>> >
>> >
>> > >
>> > > Kind regards,
>> > >
>> > > Leo
>> >
>> > --
>> >
>> > 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/