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

Colleagues

Following on from Havard's comments below I would like to expand the
discussion to consider the general use of country codes in the RIPE
Database. As I tend to write long emails that many people don't read,
I'll summarise my main points first then expand on the details for
those who want it.

My suggestions for the community to consider are these:
1/ The country: attribute in ORGANISATION objects is only used to
specify the legal address country of organisations (including
individuals) holding internet resources and is tied to the country
values in the extended delegated stats file. These values are
maintained by the RIPE NCC. This is what the community agreed to when
they accepted the implementation plan for NWI-10.

2/ The country: attribute in ORGANISATION objects cannot be set by
users to meaningless, undefined values for other reasons, as this was
not in the agreed implementation plan.

3/ The country: attribute in INET(6)NUM objects is made optional.

4/ We define the optional country: attribute in INET(6)NUM objects to
be used for geolocation purposes only

5/ If included, this country code will signal that all the addresses
covered by this range/prefix are used within the geographical boundary
of the country value.

6/ The geofeed: attribute can be used where a block of addresses are
used in multiple countries or if more fine grained details are needed.

7/ An optional country: attribute could be added to the AUT-NUM object
if anyone feels it necessary to specify a geolocation for an ASN.

As always your thoughts are welcome...

Now I will expand on some of these points and explain why I am
suggesting them. The implementation plan for NWI-10, which proposed
the addition of a country code in the ORGANISATION object, is
contained in a RIPE Labs article (
https://labs.ripe.net/author/stefania_fokaeos/our-plan-to-update-country-codes/
). This has 3 phases. All of these phases are concerned with the
addition of the legal country for resource holders and syncing that
data with the extended delegated stats. The implementation plan does
not suggest making this attribute available for users to edit for
ORGANISATION objects that are not linked to resource objects. This is
the plan that was agreed to by the community. We therefore have no
community consensus on allowing users to edit this attribute. If
anyone thinks users should be able to edit this attribute we will need
a new consensus. The discussion on that will have to justify the value
of allowing meaningless, undefined data in the database. If some
meaning, other than a legal address synced to the stats file, is
assigned to the user entered data then we will have to justify the
benefit of having two different meanings to the same attribute
dependent on other parameters. The documentation on this attribute
will have to explain the two meanings and the parameters that
determine which meaning applies. Personally I think overloading the
same attribute with the same values set but with two different
meanings is a bad idea.

The use of the country: attribute in INET(6)NUM objects has never been
defined. In the early days of the internet it may have been possible
to assume it was the country where the addresses were used. Without a
clear definition, that cannot be assumed today. The RIPE NCC has been
telling people for the last 20 years that they cannot reliably use
this information for IP to country mapping. But people still do it
anyway. If you have to give the same negative answer to the same
question for 20 years, something is seriously wrong. Data with a fixed
set of values, where the values have a meaning, but the data itself
has no meaning, has no place in this database. So either we give it a
meaning or we deprecate the attribute completely.

Most people seem to assume it can be reliably used for geolocation
purposes. That would be the most obvious use case for this attribute.
Entering an optional value would signify that all the addresses in
this block are used within the geographical boundary of the country
defined by the code. Where the addresses are used in multiple
countries, it may be possible to show this at the assignment object
level. Otherwise the optional country: attribute could be omitted and
the geolocation information would be determined by the geofeed:
attribute.

This issue has been discussed many times over the last couple of
decades. Most recently during the discussion over NWI-10 in Oct/Nov
2019 and early in 2020 on this mailing list. I think it is long
overdue for a resolution...

cheers
denis
co-chair DB-WG


On Thu, 12 Jan 2023 at 15:42, Havard Eidnes <he at uninett.no> wrote:
>
> > [...]  But people will start making assumptions about it,
> > especially in the geo location area, as they have done for
> > years with the also meaningless country values in INET(6)NUM
> > objects.
>
> Following up on the tangent of "contry" for inet(6)num objects:
>
> I realize that there are cases where the address space is in use in
> multiple countries.  However, I would guess that is rather the
> exception than the rule.  Would it not have been nice if a network
> address holder could indicate to geo location providers a "full
> override" to "idiot automation" that "yes, the entirety of use of
> this address space is being used by users who come from within the
> borders of this country"?  This would then work irrespective of
> e.g. users bringing their cell phones with them with (GPS and other)
> location services turned on to vacations in faraway places and
> VPNing in to your network, and immediately causing all your VPN
> users for that VPN concentrator to be geo-located to that country?
> (Yes, we have had that happen, and getting it fixed is apparently
> going to take months!)
>
> That would make it so that the geo-feed URLs would only be necessary
> to maintain and serve a useful purpose for those address space
> holders which use their address space in more than one country.
>
> It's permitted to dream, right?
>
> Yes, I know, getting universal agreement on this or something like
> it from all the sundry geo-location providers is basically *never*
> going to happen, and instead the geo-location providers farm out the
> effort of collecting and maintaining geo-location data to all the
> address space holders instead.  Sigh!
>
> And for IPv6 you basically have to list shorter prefixes than what
> the "idiot automation" insists on using internally but in all
> probability does not document externally, so you have to rely on
> unsubstantiated rumours from other ISPs.  Double sigh!
>
> And each attempt apparently has a "duty cycle" of a month or more.
> Triple sigh!
>
> Geo location providers are just the worst to work with!
> Particularly if you have not had to bother with them earlier.
>
> Best regards,
>
> - Håvard