<div><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">---------- Forwarded message ---------<br>From: <strong class="gmail_sendername" dir="auto">denis walker via db-wg</strong> <span dir="auto"><<a href="mailto:db-wg@ripe.net">db-wg@ripe.net</a>></span><br>Date: Tue, Jan 24, 2023 at 4:19 PM<br>Subject: Re: [db-wg] country codes in the RIPE Database (was: ORGANISATION country code)<br>To: Havard Eidnes <<a href="mailto:he@uninett.no">he@uninett.no</a>><br>CC: Database WG <<a href="mailto:db-wg@ripe.net">db-wg@ripe.net</a>><br></div><br><br>Colleagues<br>
<br>
Following on from Havard's comments below I would like to expand the<br>
discussion to consider the general use of country codes in the RIPE<br>
Database. As I tend to write long emails that many people don't read,<br>
I'll summarise my main points first then expand on the details for<br>
those who want it.<br>
<br>
My suggestions for the community to consider are these:<br>
1/ The country: attribute in ORGANISATION objects is only used to<br>
specify the legal address country of organisations (including<br>
individuals) holding internet resources and is tied to the country<br>
values in the extended delegated stats file. These values are<br>
maintained by the RIPE NCC. This is what the community agreed to when<br>
they accepted the implementation plan for NWI-10.<br>
<br>
2/ The country: attribute in ORGANISATION objects cannot be set by<br>
users to meaningless, undefined values for other reasons, as this was<br>
not in the agreed implementation plan.<br>
<br>
3/ The country: attribute in INET(6)NUM objects is made optional.<br>
<br>
4/ We define the optional country: attribute in INET(6)NUM objects to<br>
be used for geolocation purposes only<br>
<br>
5/ If included, this country code will signal that all the addresses<br>
covered by this range/prefix are used within the geographical boundary<br>
of the country value.<br>
<br>
6/ The geofeed: attribute can be used where a block of addresses are<br>
used in multiple countries or if more fine grained details are needed.<br>
<br>
7/ An optional country: attribute could be added to the AUT-NUM object<br>
if anyone feels it necessary to specify a geolocation for an ASN.<br>
<br>
As always your thoughts are welcome...<br>
<br>
Now I will expand on some of these points and explain why I am<br>
suggesting them. The implementation plan for NWI-10, which proposed<br>
the addition of a country code in the ORGANISATION object, is<br>
contained in a RIPE Labs article (<br>
<a href="https://labs.ripe.net/author/stefania_fokaeos/our-plan-to-update-country-codes/" rel="noreferrer" target="_blank">https://labs.ripe.net/author/stefania_fokaeos/our-plan-to-update-country-codes/</a><br>
). This has 3 phases. All of these phases are concerned with the<br>
addition of the legal country for resource holders and syncing that<br>
data with the extended delegated stats. The implementation plan does<br>
not suggest making this attribute available for users to edit for<br>
ORGANISATION objects that are not linked to resource objects. This is<br>
the plan that was agreed to by the community. We therefore have no<br>
community consensus on allowing users to edit this attribute. If<br>
anyone thinks users should be able to edit this attribute we will need<br>
a new consensus. The discussion on that will have to justify the value<br>
of allowing meaningless, undefined data in the database. If some<br>
meaning, other than a legal address synced to the stats file, is<br>
assigned to the user entered data then we will have to justify the<br>
benefit of having two different meanings to the same attribute<br>
dependent on other parameters. The documentation on this attribute<br>
will have to explain the two meanings and the parameters that<br>
determine which meaning applies. Personally I think overloading the<br>
same attribute with the same values set but with two different<br>
meanings is a bad idea.<br>
<br>
The use of the country: attribute in INET(6)NUM objects has never been<br>
defined. In the early days of the internet it may have been possible<br>
to assume it was the country where the addresses were used. Without a<br>
clear definition, that cannot be assumed today. The RIPE NCC has been<br>
telling people for the last 20 years that they cannot reliably use<br>
this information for IP to country mapping. But people still do it<br>
anyway. If you have to give the same negative answer to the same<br>
question for 20 years, something is seriously wrong. Data with a fixed<br>
set of values, where the values have a meaning, but the data itself<br>
has no meaning, has no place in this database. So either we give it a<br>
meaning or we deprecate the attribute completely.<br>
<br>
Most people seem to assume it can be reliably used for geolocation<br>
purposes. That would be the most obvious use case for this attribute.<br>
Entering an optional value would signify that all the addresses in<br>
this block are used within the geographical boundary of the country<br>
defined by the code. Where the addresses are used in multiple<br>
countries, it may be possible to show this at the assignment object<br>
level. Otherwise the optional country: attribute could be omitted and<br>
the geolocation information would be determined by the geofeed:<br>
attribute.<br>
<br>
This issue has been discussed many times over the last couple of<br>
decades. Most recently during the discussion over NWI-10 in Oct/Nov<br>
2019 and early in 2020 on this mailing list. I think it is long<br>
overdue for a resolution...<br>
<br>
cheers<br>
denis<br>
co-chair DB-WG<br>
<br>
<br>
On Thu, 12 Jan 2023 at 15:42, Havard Eidnes <<a href="mailto:he@uninett.no" target="_blank">he@uninett.no</a>> wrote:<br>
><br>
> > [...]  But people will start making assumptions about it,<br>
> > especially in the geo location area, as they have done for<br>
> > years with the also meaningless country values in INET(6)NUM<br>
> > objects.<br>
><br>
> Following up on the tangent of "contry" for inet(6)num objects:<br>
><br>
> I realize that there are cases where the address space is in use in<br>
> multiple countries.  However, I would guess that is rather the<br>
> exception than the rule.  Would it not have been nice if a network<br>
> address holder could indicate to geo location providers a "full<br>
> override" to "idiot automation" that "yes, the entirety of use of<br>
> this address space is being used by users who come from within the<br>
> borders of this country"?  This would then work irrespective of<br>
> e.g. users bringing their cell phones with them with (GPS and other)<br>
> location services turned on to vacations in faraway places and<br>
> VPNing in to your network, and immediately causing all your VPN<br>
> users for that VPN concentrator to be geo-located to that country?<br>
> (Yes, we have had that happen, and getting it fixed is apparently<br>
> going to take months!)<br>
><br>
> That would make it so that the geo-feed URLs would only be necessary<br>
> to maintain and serve a useful purpose for those address space<br>
> holders which use their address space in more than one country.<br>
><br>
> It's permitted to dream, right?<br>
><br>
> Yes, I know, getting universal agreement on this or something like<br>
> it from all the sundry geo-location providers is basically *never*<br>
> going to happen, and instead the geo-location providers farm out the<br>
> effort of collecting and maintaining geo-location data to all the<br>
> address space holders instead.  Sigh!<br>
><br>
> And for IPv6 you basically have to list shorter prefixes than what<br>
> the "idiot automation" insists on using internally but in all<br>
> probability does not document externally, so you have to rely on<br>
> unsubstantiated rumours from other ISPs.  Double sigh!<br>
><br>
> And each attempt apparently has a "duty cycle" of a month or more.<br>
> Triple sigh!<br>
><br>
> Geo location providers are just the worst to work with!<br>
> Particularly if you have not had to bother with them earlier.<br>
><br>
> Best regards,<br>
><br>
> - Håvard<br>
<br>
-- <br>
<br>
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: <a href="https://lists.ripe.net/mailman/listinfo/db-wg" rel="noreferrer" target="_blank">https://lists.ripe.net/mailman/listinfo/db-wg</a><br>
</div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Christian Nzhie.<br></div></div></div></div></div>