At the RIPE NCC we’re busy working out the implementation of Numbered Working Item (NWI) 10, which deals with clarifying the meaning of the country code attribute in the RIPE Database and the Extended Delegated Statistics.
Problem statement
Back in 2018 and 2019, during RIPE 77 and RIPE 78, we presented about the lack of a clear definition for the Country Code attribute. This attribute is present in both the RIPE Database and the Extended Delegated Statistics for the Internet number resources that the RIPE NCC allocates and assigns to LIRs and their End Users.
In general, the Country Code refers to the country where the network is located. But, what does that actually mean? Well, it's complicated.
There are different interpretations as a network can be spread over multiple countries and this can also change over time. Also, there is no proper way to verify if the Country Codes entered are correct, so we have to believe what the user tells us. In addition to the above, we have been receiving an increasing number of requests to update the country code in the Extended Delegated Statistics. This is why we have decided to look into this problem and propose a solution to the community.
Our proposal
Here’s what we proposed:
- The Country Code for resource objects in the RIPE Database will remain as is, maintained by the resource holder who decides the criteria.
- A new attribute will be added to the ORGANISATION object, with the Country Code for the country in which the resource holder is legally based. This attribute will be maintained by the RIPE NCC.
- This new Country Code attribute will also be reflected in the Extended Delegated Statistics. Hence, this file will show in which country the resource holder is legally based.
This will make our data more consistent with that of other Regional Internet Registries (RIRs), as most of them use the legal country where the holder is registered.
The community takes over
We understood that country codes are used by community members for different purposes (e.g. commercial) and therefore we needed to have the community’s support before taking action and changing things.
The RIPE Database Working Group (DB-WG) took over the issue and started a discussion on how the Country Code attribute should be defined. After some months of discussion in the mailing list, the DB-WG Chairs announced that consensus was reached on our proposal and that we could start the implementation.
Getting our tools ready
Before going forward with the implementation, we had to make sure we had the following information ready in our systems:
1. The RIPE Database needs to have the "country:" attribute available for ORGANISATION objects.
The RIPE Database part is ready! The "country:" attribute is now available and can be added in the ORGANISATION objects for entities that hold both Provider Aggregatable (PA) space and Provider Independent (PI) resources.
2. The legal address for our members
We have the legal address of each of our members (LIR) already in place, digitalised in our internal records.
3. The legal address for our members’ End Users (holders of PI resources)
While working on the bits and bobs of the implementation plan, we realised we first had an obstacle to bypass. We have the legal address of End Users who hold Provider Independent resources, but they are only available in the registration papers we have approved upon requesting the resources via their Sponsoring LIR. The problem is that this information is not yet in the right format in our system (see Phase 2 below for more details).
Implementation plan
Phase 1
We will first update the ORGANISATION objects with "org-type:" 'LIR' and include the "country:" attribute. The value of this attribute will be taken from our internal records.
At the same time, we will also update the Country Code in the Extended Delegated Statistics file for all the resources an LIR holds. These resources will have as Country Code the Country Code that will be visible in the respective ORGANISATION object.
This is expected to be done by the end of 2020. An announcement will be sent once this is completed.
Phase 2
We will need to update the functionality of our tools so as to be able to digitally edit the legal addresses for End Users that hold Provider Independent resources. This is already in progress. However, we estimate that it will take some time. If everything goes according to plan, our tools will be ready within next year.
Once our tools are ready, we will need to manually add the legal address for all End Users. At the time of writing, the total number of End Users that hold Provider Independent resources is 19,383.
At that moment, further adjustments will need to take place in our existing requests forms (e.g. resource requests, update requests), where Sponsoring LIRs will be required to add the legal address of their End User upon submitting a new request to the RIPE NCC on their behalf.
Phase 3
Once we have the legal address recorded for all End Users, we will be able to repeat Phase 1. This means updating the ORGANISATION objects with "org-type:" 'OTHER' and include the "country:" attribute, if that org-id is referenced to a Provider Independent resource. The value of this attribute will be taken from our internal records.
At the same time, we will also update the Country Code in the Extended Delegated Statistics file for all the Provider Independent resources an End User holds. These resources will have as Country Code the Country Code that will be visible in the respective ORGANISATION object.
Important to note:
Once Phase 1 is completed, the change of the Country Code in the Extended Delegated Statistics file will only be possible if there is proof from the National Authorities that the legal entity has been moved to another country. LIRs will need to contact the RIPE NCC and submit documentation proving the need to update, for example due to a business restructure (merger/acquisition). Nothing new here - This is the current standard process for updates on the legal information of any LIR/End User. Sponsoring LIRs can contact us directly at any moment to fix incorrect country codes for their End Users.
Please note that the maintainer of the INET(6)NUM objects in the RIPE Database will still be able to update the Country Code. However, any changes on the "country:" attribute in the resource objects will not impact the Extended Delegated Statistics.
Comments 18
Comments are disabled on articles published more than a year ago. If you'd like to inform us of any issues, please reach out to us via the contact form here.
Leo Vegoda •
You state that "We understood that country codes are used by community members for different purposes." I am sure this is correct. Normalizing the meaning of the input data is sound. I would welcome a separate blog post on how you will be reaching out to all the organizations that currently use the data to explain what will change and what their options are.
Den Is •
Leo, I don't think there is any need for the RIPE NCC to reach out to organisations individually who may use the current country data. Nothing really changes. I think, as long as the details of the new arrangement are clearly defined in articles like this one, the RIPE Database documentation, the whois -v output, the ftp README files for the stats and in announcements made to Working Group mailing lists then everyone should be duly informed. Why do I think "Nothing really changes"? The database documentation is very clear that the country attribute in resource objects has no defined meaning. This will not change. So anyone currently using that data for any purpose should already know they cannot rely on undefined data. The new country attribute in the ORGANISATION object is exactly that, it is new. Anyone wishing to use this new data should look up what it means. The ftp README file for the extended delegated stats also clearly states that "There are no rules defined for this value." regarding the country data. So again if anyone is using undefined data they cannot rely on it. The fact that this data will now have a definition doesn't change the meaning of any application that was previously using undefined data.
Hide replies
Leo Vegoda •
Denis, I disagree. While some of the organizations using the data will be regular participants in the RIR system, many will not. We cannot expect them to track changes announced inside a community they are not actively involved in. And while the database documentation is now of a very high standard, this was not always the case. Organizations that started using this data over a decade ago did not have the benefits available to people starting afresh today. I am concerned that as the data is updated to reflect its newly given meaning, Internet end users will suffer real unpredictable issues. I would have preferred a change in the data format, forcing the people at those organizations to make new decisions. That was not the path taken. So be it. The least we should do is to contact them and let them know what is happening before it is implemented.
Hide replies
Den Is •
What can be more unpredictable than offering a service based on undefined data which can (and does) change at any time to some other random value? If anyone is providing a service based on the country code in resource objects, nothing will change. If a service is provided based on country code in the stats it 'may' have a one off change as the organisation's legal base country is set in the stats. Many of those values probably won't change anyway, but at least they are now set in stone. The data format of the stats is agreed between all the RIRs. It was not possible to change the data format. How do you contact organisations who download a daily file from the RIPE NCC's ftp site? I don't know what, if any, identifiable details they leave when downloading this file. It is probably not possible to identify these organisations, never mind contact them.
Hide replies
Leo Vegoda •
Denis, You are probably better informed about the data and the history than anyone else. Even within the RIR communities, very few people are so well informed. We simply don't know that users understood that country was undefined. We have to assume that they thought it meant what they thought it meant. And of course we can contact the organizations who download the file. For a start, we can use the contact information for the IP address to send an e-mail. But the RIPE NCC staff is more than capable of using other approaches to communicate with likely users. They just need to be given the task.
Stylianos Miaoudakis •
Hello, could you please provide a real example of how this is going to look like? What will be the impact for Cloud Providers that IP Geolocation is very important because of the infrastructure they utilise across the Globe. Thank you in advance for your response
Alex •
Hello, Could you please provide a real example of how this is going to work for global service providers as their infrastructure is spread across the Globe without local offices in each country? Thank you in advance for the support.
Stefania Fokaeos •
Dear all, First of all thank you for your comments and our apologies for not replying sooner. I have commented in line on the couple of points raised. Please see below. --- > on how you will be reaching out to all the organizations that currently use the data Unfortunately we cannot know which (and how) different organisations use data that are recorded in the Extended Delegated Statistics files. However, we ensured we contacted all the impacted LIRs separately to be aware that changes will take place in the resources allocated/assigned to them. In addition to that we contacted all the Geolocation providers listed in the webpage: https://www.ripe.net/manage-ips-and-asns/db/tools/geolocation-in-the-ripe-database > could you please provide a real example of how this is going to look like? For example, RIPE NCC has also an LIR Account and is the holder of resources. Some of the resources registered to the RIPE NCC will be impacted by the upcoming changes. For example the resource 93.175.159.0/24 has currently as Country Code (CC) EU and it should be NL. During the scheduled automatic updates, the CC for 93.175.159.0/24 will be updated to NL to match where RIPE NCC is legally established. The CC that the INETNUM object for 93.175.159.0/24 has in the RIPE Database will remain as it is (i.e. SE). If for some reason (e.g. during a RIPE Meeting) there is a geolocation concern for services offered behind 93.175.159.0/24, then: 1. the maintainer of the object can update the "country:" attribute listed in the INETNUM object with a different CC and/or add a "geoloc:" attribute. 2. the RIPE NCC's Network Engineers should contact the geolocation providers and ask them to update the CC to show to the correct Country. > What will be the impact for Cloud Providers that IP Geolocation is very important because of the infrastructure they utilise across the Globe. You should register the assignments made to your network across the Globe in the RIPE Database and use "country:" and/or "geoloc:" attributes accordingly. --- For any additional questions that may arise, please feel free to contact us. We are happy to assist you further.
Hide replies
Stef Renders •
> You should register the assignments made to your network across the Globe in the RIPE Database and use "country:" and/or "geoloc:" attributes accordingly. These are not used by pretty much all geolocation providers, we have an INETNUM tagged on NL for years and is still not updated. As a workaround since some geodb didn't update our information at all, we had a NL ASN assigned to advertise this range. All was well until a month ago where the geodb pulled our ASN again and it had change to BE. Now we are 1) desperately contacting geodb parties to update our information as it is NOT pulled from INETNUM (or if it is, only from ALLOCATED PA not ASSIGNED PA) and we simply do not have enough resources to allocate a PA per country. After reaching out to a senior ripe engineer whom was involved in the rollout of the geoloc attributes, it was confirmed this attribute is still not used at all by third party geodb. So why bother updating it. 2) requesting sponsored ASN's for our subsidiaries in other countries since option 1 is just a pain in the *** and would probably keep on failing as information is not pulled correctly. RIPE should take its responsibility and contact their GEOdb partners and have them pull information correctly.
Hide replies
Stefania Fokaeos •
Dear Stef, Thank you for your comment and for sharing with us your concerns. I believe the best place to share your concerns regarding the update of the Country Code (CC) that took place due to NWI-10 would be the RIPE Database Working Group (DB-WG). The community discussed quite extensively this proposal (i.e. NWI-10) in the DB-WG and once consensus was reached, we (RIPE NCC) got instructed and had no other choice but to start the implementation of it. Similarly to what we do with all accepted policy proposals. However, I can guarantee you that we ensured before making any changes that: 1. all the impacted Resource Holders (of Implementation Phase 1) were informed in advance to adjust if needed any network settings. Your LIR was one of those that was informed. 2. the Geolocation Providers were contacted to be informed about the upcoming changes and to update their algorithms so to be able to provide the geolocation services accurately. We contacted the Geolocation providers that are listed on our Website (https://www.ripe.net/manage-ips-and-asns/db/tools/geolocation-in-the-ripe-database) As a suggestion to solve your problem, have you tried to contact MaxMind via the following form: https://support.maxmind.com/geoip-data-correction-request/correct-a-geoip-location/ Also, have you tried to see if the situation will be improved, after you have updated the related INETNUM objects (allocation and assignments) and included the "geoloc:" attribute on those? In any case, we are happy to discuss your case in more details. Feel free to send us an email to <lir-help@ripe.net>. Kind regards, Stefania Fokaeos Internet Resource Analyst RIPE NCC
Olga •
Break compatibility? Why? RIPE database is working well, no reason for fix something what is working well.
Hide replies
Stefania Fokaeos •
Dear Olga, Thank you for your comment. Unfortunately I'm not sure I understand what you mean. Could you please clarify into more details what do you mean? The RIPE Database information remains as it is. Only additional information was added in the ORGANISATION objects, which show where each holder is legally established.
Christian •
I think this is a great improvement! It really helps to get a feel for where a company is originating from.
Lukasz Sokol •
The Country Codes as saved in the RIPE Database, are being used by providers of geo-fencing software; this might not matter for a lot of LIRs, but what of those who are registered companies in one country, but their IP(6) resources are only in use in another? (Answer: the country code for their country of residence is added to the record of the particular resource). This can create a problem for end-users of those resources (not PI) as all of a sudden their geographically-aware access is revoked and requires them to use a VPN to be useable again. (Pls note: I'm not holding this against the resolution, I am only rising it as a special case)
Hide replies
Den Is •
The Country Code that was previously saved in the RIPE Database (resource objects) has not changed. So any geo-fencing software that used that data will not be affected in any way. Additional country information has been added to ORGANISATION objects. This has a clearly defined meaning - legal country where LIR operates from. Any software that is changed to make use of this additional country information should take account of it's definition.
Emmanuel Ojo •
So now how do i get the invalid ripe access code solved
Maximilian Baehring •
Hello! I have got your email today! >... on Monday 31st >October the RIPE NCC populated the "country:" >attribute on your organisation(s) in the RIPE database, using the >country code in which >the organisation is legally based. > >Here is the list of changes made to your objects: > >1. Added country code DE to *CENSORED* Why should this be necessary? i am from the press, a blogger and net poltician and do not want to any (so called) "community" to use my data. there already was the correct info in an "address:" field of the "object" ... address: *CENSORED*ZIP-CODE* *CENSORED*CITY/TOWN* address: Germany ... Max
Kai Liu •
I think the property should be set by the resource holder, because the organization country does not represent the country that the network actually uses. Even the network has nothing to do with the organization country