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