Articles
Likes on articles
I am an independent netizen, no longer working for the RIPE NCC, but still with the same meticulous interest in all things RIPE Database. I am a software developer and business analyst with almost 40 years experience as a 'C' language developer (and similar languages) working mainly on database and real time systems. From 2001 to 2015 I was a developer and then the business analyst for the RIPE Database with the RIPE NCC. During this time I took a holistic approach to the database system and have been involved in every aspect of it's design and development of the software, web services and infrastructure. I started to work on the RIPE Database the week after the RPSL version was deployed in April 2001. I have been heavily involved in two major re-writes of the software in 2004 (C code re-structuring) and 2012 (complete re-write in java). For the 2012 re-write I reverse engineered the C code to write the specifications for every part of the new java system to maintain the original functionality. I was also the lead developer in setting up the AFRINIC Database and migration of data from both the RIPE and ARIN Databases to populate it in 2005.
“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)”
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.
“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.”
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.
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.
Showing 3 comment(s)