Change of Country entries in the database
Dear colleagues of the RIPE NCC database group! I'm using the RIPE whois database in its bulk version ripe.db.inetnum for statistical uses while evaluating the netflow data of our border routers. What I'm much interested in is the origin of an IP address which I get by the country entry of the respective inetnum block of the database. Therefore, I'm always a bit confused about the many addresses which are located in the Netherlands. Since I prefer large inetnum blocks for reasons of performance of my software, I often use entries of many C blocks which are registered for the RIPE NCC with the country entry NL. In the meantime, I already corrected the country entries of some inetnums in my own local copy of the database but this is just a workaround which isn't really satisfying. So I would like to suggest the change of the country entry of - at least - the following inetnum blocks (only inetnum, netname and country entries): inetnum: 0.0.0.0 - 255.255.255.255 netname: IANA-BLK country: NL proposed country: EU # Country is really world wide inetnum: 10.0.0.0 - 10.255.255.255 netname: IANA-ABLK-RESERVED1 country: NL proposed country: EU # Country is really world wide inetnum: 145.224.0.0 - 145.254.255.255 netname: RIPE-NCC-145 country: NL proposed country: EU # Country is really world wide inetnum: 145.0.0.0 - 145.127.255.255 netname: RIPE-NL country: NL proposed country: EU inetnum: 147.233.0.0 - 147.237.255.255 netname: RIPE-ISRAELB-NET country: NL proposed country: EU [or IL] inetnum: 149.132.0.0 - 149.134.255.255 netname: RIPE-149-BLK country: NL proposed country: EU inetnum: 149.202.0.0 - 149.204.255.255 netname: RIPE-149-202-BLK country: NL proposed country: EU inetnum: 149.221.0.0 - 149.250.255.255 netname: EU-ZZ-990225 country: NL proposed country: DE inetnum: 149.206.0.0 - 149.251.255.255 netname: RIPE-149-206-BLK country: NL proposed country: EU inetnum: 163.156.0.0 - 163.175.255.255 netname: NETBLK-RIPE-B country: NL proposed country: EU inetnum: 164.128.0.0 - 164.143.255.255 netname: NETBLK-RIPE-B-128 country: NL proposed country: EU inetnum: 164.0.0.0 - 164.40.255.255 netname: RIPE-164-BLK country: NL proposed country: EU inetnum: 172.16.0.0 - 172.31.255.255 netname: IANA-BBLK-RESERVED1 country: NL proposed country: EU # Country is really world wide inetnum: 192.168.0.0 - 192.168.255.255 netname: IANA-CBLK-RESERVED1 country: NL proposed country: EU # Country is really world wide With the entry 'EU # Country is really world wide' I'm referring to an invention of the RIPE NCC due to the ERX project. You created in 2003 the following inetnums: inetnum: 141.0.0.0 - 141.255.255.255 netname: EU-ZZ-141 country: EU # Country is really world wide inetnum: 151.0.0.0 - 151.255.255.255 netname: EU-ZZ-151 country: EU # Country is really world wide inetnum: 188.0.0.0 - 188.255.255.255 netname: EU-ZZ-188 country: EU # Country is really world wide Better would be nevertheless the creation of let's say 'ZZ' or 'WW' for worldwide use, but if you put in exactly 'EU # Country is really world wide', this will be easily been parsed by Perl. I think that this is a good solution, since it doesn't make sense to put in NL for the whole IPv4 address space for example or for let's say RIPE-ISRAELB-NET. The fact that anybody in the Netherlands has to deal with the related range is clearly reflected by the contact persons or roles which is CREW-RIPE or something like that and which is situated in NL. I'm looking forward to hear your opinion. Best regards, Christoph Mohr -- -- Christoph Mohr, BelWue Coordination ---------- mailto:mohr@belwue.de ----- Computing Center University of Stuttgart (RUS) Phone: +49 711 685-2079 Allmandring 30, D-70550 Stuttgart Fax: +49 711 678-8363 ------------------------------------------------- http://www.belwue.de/ -----
At 06:27 PM 08-10-03 +0200, Christoph Mohr wrote:
I think that this is a good solution, since it doesn't make sense to put in NL for the whole IPv4 address space for example or for let's say RIPE-ISRAELB-NET. The fact that anybody in the Netherlands has to deal with
By coincidence, I am working with RIPE NCC on fixing up that entry. -Hank PS I think the country code should 00 for whole world since as countries split - who knows if ZZ or any two letters will be used in the future.
the related range is clearly reflected by the contact persons or roles which is CREW-RIPE or something like that and which is situated in NL.
I'm looking forward to hear your opinion.
Best regards, Christoph Mohr -- -- Christoph Mohr, BelWue Coordination ---------- mailto:mohr@belwue.de ----- Computing Center University of Stuttgart (RUS) Phone: +49 711 685-2079 Allmandring 30, D-70550 Stuttgart Fax: +49 711 678-8363 ------------------------------------------------- http://www.belwue.de/ -----
Hank Nussbacher wrote:
PS I think the country code should 00 for whole world since as countries split - who knows if ZZ or any two letters will be used in the future.
ZZ is fine. ISO 3166-1 has reserved code points for exactly this purpose. See http://www.iso.ch/iso/en/prods-services/iso3166ma/10faq/frequently-asked-que... "EU" is not on this list, but it's on a - meanwhile non-public - separate list and will not be assigned. Different topic :-) -Peter
PS I think the country code should 00 for whole world since as countries split - who knows if ZZ or any two letters will be used in the future. At the iso 3166 Maintenance Agency, there is a list of country codes which can be used for private use. I suggest you pick one of those instead of inventing your own. jaap
Dear Christoph, all, On 2003-10-08 18:27:59 +0200, Christoph Mohr wrote:
Dear colleagues of the RIPE NCC database group!
I'm using the RIPE whois database in its bulk version ripe.db.inetnum for statistical uses while evaluating the netflow data of our border routers. What I'm much interested in is the origin of an IP address which I get by the country entry of the respective inetnum block of the database.
Let me quote a couple of sentences from one of the most used ripe-dbm templates: ---quote The RIPE Network Management Database contains information about IP address space allocations and assignments. This information also indicates the country where resources were first allocated or assigned. However it is not intended that the data be considered as an authoritative statement of the location where any specific resource may currently be in use. Therefore using this information for IP to country mapping may result in inaccuracies and, as a result, in user's confusion in many cases. For instance, as the Internet is global, it is easy for users to either intentionally or unintentionally use IP addresses that have been assigned to a company conducting business in another region. For example, a user in Italy may be receiving ISP service from a company who gets a link to Japan via a satellite company run out of the US. Which company has the space registered depends on their business and networking arrangements. ---end quote Indeed, because of this reason, it might be good idea to obsolete "country:" attribute in the inetnums. What do you think about this? In the mean time, of course it is a good idea to keep the available information as close to the reality as possible. So we will change NLs to EUs where applicable, for the moment. Also, if we decide to keep "country:" attribute in inetnums, then using a code to denote 'the world' sounds like a good idea. According to the ISO pages that Peter posted, ZZ looks like available for this purpose.
Therefore, I'm always a bit confused about the many addresses which are located in the Netherlands. Since I prefer large inetnum blocks for reasons of performance of my software, I often use entries of many C blocks which are registered for the RIPE NCC with the country entry NL. In the meantime, I already corrected the country entries of some inetnums in my own local copy of the database but this is just a workaround which isn't really satisfying. So I would like to suggest the change of the country entry of - at least - the following inetnum blocks (only inetnum, netname and country entries):
[...]
inetnum: 145.0.0.0 - 145.127.255.255 netname: RIPE-NL country: NL proposed country: EU
The above should stay as is, as SURFnet is in NL.
inetnum: 147.233.0.0 - 147.237.255.255 netname: RIPE-ISRAELB-NET country: NL proposed country: EU [or IL]
This has already been changed. Best regards, -- Engin Gunduz RIPE NCC Database Group
On Fri, 10 Oct 2003, Engin Gunduz wrote:
---quote The RIPE Network Management Database contains information about IP address space allocations and assignments. This information also indicates the country where resources were first allocated or assigned. However it is not intended that the data be considered as an authoritative statement of the location where any specific resource may currently be in use.
Therefore using this information for IP to country mapping may result in inaccuracies and, as a result, in user's confusion in many cases.
For instance, as the Internet is global, it is easy for users to either intentionally or unintentionally use IP addresses that have been assigned to a company conducting business in another region.For example, a user in Italy may be receiving ISP service from a company who gets a link to Japan via a satellite company run out of the US.Which company has the space registered depends on their business and networking arrangements. ---end quote
Indeed, because of this reason, it might be good idea to obsolete "country:" attribute in the inetnums. What do you think about this?
Please don't. 99.9% accurate info is better than 0% info. -Hank
On 10.10 11:20, Hank Nussbacher wrote:
Indeed, because of this reason, it might be good idea to obsolete "country:" attribute in the inetnums. What do you think about this?
Please don't. 99.9% accurate info is better than 0% info.
I agree with Hank. One has to clearly differentiate between *hard* info that needs as close to 100% accuracy as one can get, and *soft* info that is still useful even when full accuracy cannot be guaranteed. Examples of hard info are address space allocation and assignment chains. country: is an example of soft info. Removing an attribute because its information is becoming too soft should only be done when the usefulness is much less than the current country:. Daniel
Daniel Karrenberg wrote:
On 10.10 11:20, Hank Nussbacher wrote:
Indeed, because of this reason, it might be good idea to obsolete "country:" attribute in the inetnums. What do you think about this?
Please don't. 99.9% accurate info is better than 0% info.
I agree with Hank. One has to clearly differentiate between *hard* info that needs as close to 100% accuracy as one can get, and *soft* info that is still useful even when full accuracy cannot be guaranteed.
Examples of hard info are address space allocation and assignment chains. country: is an example of soft info.
Removing an attribute because its information is becoming too soft should only be done when the usefulness is much less than the current country:.
Perhaps we should make it optional then. People who want to maintain the information can keep it up to date, and people who want to use the information will have greater certainty that if the attribute is there that it is correct. Also, I suggest that it may make sense to make it list-valued. Right now it is: country: [mandatory] [multiple] [ ] So users who have networks in multiple countries and want to document have to do things like: country: NL country: BE country: DE Or worse, things like: country: NL # BE DE Allowing the use of: country: NL, BE, DE Would solve this issue. -- Shane Kerr RIPE NCC
On Wed, 22 Oct 2003, Shane Kerr wrote:
Daniel Karrenberg wrote:
On 10.10 11:20, Hank Nussbacher wrote:
Indeed, because of this reason, it might be good idea to obsolete "country:" attribute in the inetnums. What do you think about this?
Please don't.99.9% accurate info is better than 0% info.
I agree with Hank. One has to clearly differentiate between *hard* info that needs as close to 100% accuracy as one can get, and *soft* info that is still useful even when full accuracy cannot be guaranteed.
Examples of hard info are address space allocation and assignment chains. country: is an example of soft info.
Removing an attribute because its information is becoming too soft should only be done when the usefulness is much less thanthe current country:.
Perhaps we should make it optional then.People who want to maintain the information can keep it up to date, and people who want to use the information will have greater certainty that if the attribute is there that it is correct.
I wouldn't make it optional, but I very much like your idea below but will cause havoc on all those automated scripty things out there pulling out the country tag and assuming a 2 character string. If you make the change remember to post to many Internet lists so everyone knows of the change. -Hank
Also, I suggest that it may make sense to make it list-valued.Right now it is:
country: [mandatory] [multiple] [ ]
So users who have networks in multiple countries and want to document have to do things like:
country: NL country: BE country: DE
Or worse, things like:
country: NL # BE DE
Allowing the use of:
country:NL, BE, DE
Would solve this issue.
-- Shane Kerr RIPE NCC
Hank Nussbacher
Hank Nussbacher <hank@att.net.il> wrote: [...]
I wouldn't make it optional
What is the benefit of having it as a mandatory attribute? Regards, -- leo vegoda RIPE NCC Registration Services Manager
On Wed, 22 Oct 2003, leo vegoda wrote:
Hank Nussbacher <hank@att.net.il> wrote:
[...]
I wouldn't make it optional
What is the benefit of having it as a mandatory attribute?
If this is optional, many will not fill out this data (especially those who operate in more then one country as well as some other people who are just "lazy" and do not fill out optional fiels). But if this field is mandatory, this will always exist and organizations operating in more then one country will provide exact data about those countries. So making this madatory makes, whois data a lot more valuable when trying to create statistics on ip allocations and use in different regions. And although I'm not from RIPE region, I'd like to state my support for doing it as Shane suggested (Country: NL, BE, DE). -- William Leibzon Elan Networks william@elan.net
On Wed, 22 Oct 2003, leo vegoda wrote:
Hank Nussbacher <hank@att.net.il> wrote:
[...]
I wouldn't make it optional
What is the benefit of having it as a mandatory attribute?
Internet mapping comes to mind. Internet filtering as well.
Regards,
-- leo vegoda RIPE NCC Registration Services Manager
Hank Nussbacher
Shane, On Wed, Oct 22, 2003 at 06:45:03PM +0200, Shane Kerr wrote:
Perhaps we should make it optional then. People who want to maintain the information can keep it up to date, and people who want to use the information will have greater certainty that if the attribute is there that it is correct.
Also, I suggest that it may make sense to make it list-valued. Right now it is:
country: [mandatory] [multiple] [ ]
So users who have networks in multiple countries and want to document have to do things like:
country: NL country: BE country: DE
Or worse, things like:
country: NL # BE DE
Allowing the use of:
country: NL, BE, DE
Would solve this issue.
I like your proposal. David K. ---
Dear Shane! On Wed 2003-10-22 (18:45), Shane Kerr wrote:
Daniel Karrenberg wrote:
On 10.10 11:20, Hank Nussbacher wrote:
Indeed, because of this reason, it might be good idea to obsolete "country:" attribute in the inetnums. What do you think about this?
Please don't. 99.9% accurate info is better than 0% info.
I agree with Hank. One has to clearly differentiate between *hard* info that needs as close to 100% accuracy as one can get, and *soft* info that is still useful even when full accuracy cannot be guaranteed.
Examples of hard info are address space allocation and assignment chains. country: is an example of soft info.
Removing an attribute because its information is becoming too soft should only be done when the usefulness is much less than the current country:.
Perhaps we should make it optional then. People who want to maintain the information can keep it up to date, and people who want to use the information will have greater certainty that if the attribute is there that it is correct.
Please don't make it optional! With that reason you can abolish all other mandatory attributes (like descr, tech-c, admin-c) as well. There will always be lazy people who don't want their data to be as correct as others want. But with Daniel's words: "99.9% accurate info is better than 0% info."
Also, I suggest that it may make sense to make it list-valued. Right now it is:
country: [mandatory] [multiple] [ ]
So users who have networks in multiple countries and want to document have to do things like:
country: NL country: BE country: DE
Or worse, things like:
country: NL # BE DE
Allowing the use of:
country: NL, BE, DE
Would solve this issue.
Good idea. Anything *well-defined* which is easy to pe parsed by PERL is good and a single line is easier to parse various or a single one. By the way: I noticed the changes in the RIPE DB you or your colleagues made. Now we have two versions of "country: EU": country: EU (e.g. in 194.60.0.0/15) country: EU # Country is really world wide (e.g. in 141/8) Anything new about the idea with ZZ which sounds good to me? Best regards, Christoph Mohr -- -- Christoph Mohr, BelWue Coordination ---------- mailto:mohr@belwue.de ----- Computing Center University of Stuttgart (RUS) Phone: +49 711 685-2079 Allmandring 30, D-70550 Stuttgart Fax: +49 711 678-8363 ------------------------------------------------- http://www.belwue.de/ -----
Hi, On Thu, Oct 23, 2003 at 10:17:09AM +0200, Christoph Mohr wrote: [...]
Please don't make it optional! With that reason you can abolish all other mandatory attributes (like descr, tech-c, admin-c) as well.
I can see good reasons for making admin-c and tech-c optional in some (not all) inetnum objects. Doing so might actually make the database more useful. But that's a little OT here.
There will always be lazy people who don't want their data to be as correct as others want. But with Daniel's words: "99.9% accurate info is better than 0% info."
I think we need to define what is correct and why it is correct. Why should the information be included in the database? Is the database there to support technical operations on the Internet? If so, including contact information is appropriate. This contact information can include details of a persons habitual location, official location, position, telephone number, e-mail address, etc... Is the database there to provide registration information on the organisations holding Internet numbering resources (AS numbers and and IP address space)? I think so and I think that the proposed Organisation object will make a good contribution to this. It will have space for address information that can include details of the country the organisation is based in. Is the database there to provide information about which countries a network is located in? If so, why? Who uses the information? What do they do with it? Does Joe User with a /28 for his SOHO network, have an obligation to provide them with that information? If the country attribute remains mandatory then how should its values be interpreted? Should be be see as "This is the country my network is based in" or should they be seen as "This is the country my head office is based in"? How can the person receiving the data in response to a query know the intention of the person who registered the data? Without a definition of why the country attribute is there and how it is meant to be used it is not really possible to actually determine what "correct" is. Best regards, -- leo vegoda RIPE NCC Registration Services Manager
So we will change NLs to EUs where applicable, for the moment.
I think that is unwise. It should not be changed before ISO-3166 is updated correspondingly, which hasn't happened so far, as far as I know. Regards, - Håvard
Dear Havard, On 2003-10-10 17:07:04 +0200, Havard Eidnes wrote:
So we will change NLs to EUs where applicable, for the moment.
I think that is unwise. It should not be changed before ISO-3166 is updated correspondingly, which hasn't happened so far, as far as I know.
And it does not seem like it will happen in the near future. However, the code EU is already used in RIPE Whois Database. Probably it was in use since the birth of the database. According to http://www.iso.ch/iso/en/prods-services/iso3166ma/10faq/frequently-asked-que... even if EU is not an ISO-3166 code, it's reserved.
Regards,
- Håvard
Best regards, -- Engin Gunduz RIPE NCC Database Group
participants (11)
-
Christoph Mohr -
Daniel Karrenberg -
David Kessens -
Engin Gunduz -
Hank Nussbacher -
Havard Eidnes -
Jaap Akkerhuis -
leo vegoda -
Peter Koch -
Shane Kerr -
william＠elan.net