Re: [db-wg] NWI-10 Definition of Country
Hi Denis, What you name it as "meaningless values" are not meaningless to the organizations that they are using it. When you request a new allocation from NCC you will be asked to *"specify the country which the allocation will be announced"*, and based on your selection the country code will be set for both the inet(6)numns and allocation entry in the delegation file. This is the way that the country code is added in first place in delegation file. A member may decides to use the allocation later in a different country, and they can update the country code for inet(6)numns in ripe db, so I think the best practice is to sync the delegation file with the database and let the members decide what value should be set. Regards, Arash Naderpour On Fri, Nov 1, 2019 at 11:50 PM denis walker <dw100uk@yahoo.co.uk> wrote:
Hi Arash
If many organisations are using these values then, unfortunately, you are basing decisions on meaningless values.
The country attribute in resource objects is undefined. Users can set this to any country they wish with no meaning to anyone reading the value from the database.
From the description of the extended delegated stats file ftp://ftp.ripe.net/ripe/stats/RIR-Statistics-Exchange-Format.txt
it says this about the country code:
Format:
registry|cc|type|start|value|date|status[|extensions...]
registry = One value from the set of defined strings:
{apnic,arin,iana,lacnic,ripencc};
cc = ISO 3166 2-letter country code, and the enumerated variances of
{AP,EU,UK}
These values are not defined in ISO 3166 but are widely used.
The cc value identifies the country. However, it is not specified if this is the country where the addresses are used. There are no rules defined for this value. It therefore cannot be used in any reliable way to map IP addresses to countries
If you were to sync the stats file with resource object data you are in effect setting an undefined field in the stats to an undefined value from the database.
The purpose of NWI-10 is to create a well defined country value in both the stats file and the ORGANISATION object. The legal location of an organisation is currently the only well defined country information available. There is no information available anywhere in the database or stats file telling you where a network is being used.
cheers denis
co-chair DB-WG
On Friday, 1 November 2019, 05:37:28 CET, Arash Naderpour via db-wg < db-wg@ripe.net> wrote:
Hi,
I'm new to DB-WG, but want to express my opinion in this regard, from problem definition: "Historically the country code was used to refer to the location of the network"
There are plenty of organization out there that are already set their network and firewalls rules to use country code value in delegation file as reference to the location of the network.
Changing the rule to to something new, will cause problem for clients and providers, so I don't think it is a good idea, country code in delegation file can be synced with the country code for resource object in RIPE DB. A new attribute in organization object refers to where the resource holder is legally based is totally fine, but having the same value in delegation file can break networks and services.
Regards,
Arash Naderpour Parsun Network Solutions
Arash, Arash Naderpour wrote:
What you name it as "meaningless values" are not meaningless to the organizations that they are using it.
How do we know that all, or even most, users of the data infer the same meanings? Has the RIPE NCC or anyone else ever measured what people understand this value to mean and the operational purposes to which it is put?
When you request a new allocation from NCC you will be asked to "specify the country which the allocation will be announced", and based on your selection the country code will be set for both the inet(6)numns and allocation entry in the delegation file. This is the way that the country code is added in first place in delegation file.
This was not always the case. Furthermore, allocations are not necessarily announced as single aggregate or from a single country. It is entirely possible for an allocation to be announced from multiple countries, or to be split into smaller blocks that are announced from different countries. The stats file is just about good enough to give some idea of the distribution of Internet Number Resources in different countries in a statistically useful way. But using the country code information in it to make operational decisions seems to be placing weight on both the meaning and accuracy of the data that is probably not justifiable. Kind regards, Leo Vegoda
Yes I know allocations and assignments can be announced from multiple countries, but a member has this option to set the country code for allocation and assignments based on their needs. If I can set my allocation's country code in RIPE DB why I should not be able to have the same value in delegation file for the same allocation? Having different values for country code in DB and delegation file for exact same allocation will make more confusion and can break networks, Currently country codes in the RIPE Database are quite consistent with the e xtended delegated file, I wish someone from RIPE NCC can run a test and confirm this. A workable solution to me is to let we have this consistency between DB and delegation file, and I don't see an actual need to break it. Regards, Arash Naderpour On Thu, Nov 7, 2019 at 3:43 AM Leo Vegoda <leo.vegoda@icann.org> wrote:
Arash,
Arash Naderpour wrote:
What you name it as "meaningless values" are not meaningless to the organizations that they are using it.
How do we know that all, or even most, users of the data infer the same meanings? Has the RIPE NCC or anyone else ever measured what people understand this value to mean and the operational purposes to which it is put?
When you request a new allocation from NCC you will be asked to "specify the country which the allocation will be announced", and based on your selection the country code will be set for both the inet(6)numns and allocation entry in the delegation file. This is the way that the country code is added in first place in delegation file.
This was not always the case. Furthermore, allocations are not necessarily announced as single aggregate or from a single country. It is entirely possible for an allocation to be announced from multiple countries, or to be split into smaller blocks that are announced from different countries. The stats file is just about good enough to give some idea of the distribution of Internet Number Resources in different countries in a statistically useful way. But using the country code information in it to make operational decisions seems to be placing weight on both the meaning and accuracy of the data that is probably not justifiable.
Kind regards,
Leo Vegoda
FWIW, APNIC Whois database has 3 objects with more than one distinct country attributes, out of the 1,147,623 inetnum/inet6num/autnum objects. Cheers, Sanjaya From: db-wg <db-wg-bounces@ripe.net> On Behalf Of Arash Naderpour via db-wg Sent: Friday, 8 November 2019 2:22 PM To: Leo Vegoda <leo.vegoda@icann.org> Cc: db-wg@ripe.net; denis walker <dw100uk@yahoo.co.uk> Subject: Re: [db-wg] [Ext] Re: NWI-10 Definition of Country Yes I know allocations and assignments can be announced from multiple countries, but a member has this option to set the country code for allocation and assignments based on their needs. If I can set my allocation's country code in RIPE DB why I should not be able to have the same value in delegation file for the same allocation? Having different values for country code in DB and delegation file for exact same allocation will make more confusion and can break networks, Currently country codes in the RIPE Database are quite consistent with the extended delegated file, I wish someone from RIPE NCC can run a test and confirm this. A workable solution to me is to let we have this consistency between DB and delegation file, and I don't see an actual need to break it. Regards, Arash Naderpour On Thu, Nov 7, 2019 at 3:43 AM Leo Vegoda <leo.vegoda@icann.org<mailto:leo.vegoda@icann.org>> wrote: Arash, Arash Naderpour wrote:
What you name it as "meaningless values" are not meaningless to the organizations that they are using it.
How do we know that all, or even most, users of the data infer the same meanings? Has the RIPE NCC or anyone else ever measured what people understand this value to mean and the operational purposes to which it is put?
When you request a new allocation from NCC you will be asked to "specify the country which the allocation will be announced", and based on your selection the country code will be set for both the inet(6)numns and allocation entry in the delegation file. This is the way that the country code is added in first place in delegation file.
This was not always the case. Furthermore, allocations are not necessarily announced as single aggregate or from a single country. It is entirely possible for an allocation to be announced from multiple countries, or to be split into smaller blocks that are announced from different countries. The stats file is just about good enough to give some idea of the distribution of Internet Number Resources in different countries in a statistically useful way. But using the country code information in it to make operational decisions seems to be placing weight on both the meaning and accuracy of the data that is probably not justifiable. Kind regards, Leo Vegoda
sanjaya:
FWIW, APNIC Whois database has 3 objects with more than one distinct country attributes, out of the 1,147,623 inetnum/inet6num/autnum objects.
are these useful to apnic, ops, or even researchers? randy
Good question Randy. I don't know. I can try to ask those 3 object owners. Back to the extended stats file, it would be good to identify its consumers and ask their assumptions and expectations. I know for a fact that having a 'wrong' country code can cause operational issues in some situations. It shouldn't, but it happens. Cheers, Sanjaya Sent from my mobile ________________________________ From: db-wg <db-wg-bounces@ripe.net> on behalf of Randy Bush via db-wg <db-wg@ripe.net> Sent: Friday, November 8, 2019 5:32:50 PM To: Sanjaya Sanjaya via db-wg <db-wg@ripe.net> Subject: Re: [db-wg] [Ext] Re: NWI-10 Definition of Country sanjaya:
FWIW, APNIC Whois database has 3 objects with more than one distinct country attributes, out of the 1,147,623 inetnum/inet6num/autnum objects.
are these useful to apnic, ops, or even researchers? randy
Hi Arash, Arash Naderpour wrote:
Yes I know allocations and assignments can be announced from multiple countries, but a member has this option to set the country code for allocation and assignments based on their needs. If I can set my allocation's country code in RIPE DB why I should not be able to have the same value in delegation file for the same allocation?
Having different values for country code in DB and delegation file for exact same allocation will make more confusion and can break networks,
I have no objection to resource holders being able to control how their resource is described (within reasonable constraints) in the RIPE Database or in the stats files. My concern is that there has never been any guidance from the RIPE community to network operators as to what these values mean. Because there has been no guidance, users of the data have inferred whatever meaning(s) they wish. This is relatively harmless when the only use is to measure the distribution of Internet Number Resources across the region in a purely statistical manner. But as you say, when people use these data to configure networks, it has an operational impact on other networks. If the RIPE community maintains the "country:" attribute in inet(6)num objects but defines its meaning - and so changes it for some users of the data - it will inevitably create new and subtle errors for networks around the globe. For this reason, I think the most appropriate thing to do is remove this attribute after a suitable outreach campaign. Network operators who need geolocation data can then obtain well-defined data from one or more of the geolocation data providers. Kind regards, Leo Vegoda
participants (4)
-
Arash Naderpour -
Leo Vegoda -
Randy Bush -
Sanjaya Sanjaya