NWI-10 Definition of Country
Colleagues The DB-WG chairs have agreed to create "NWI-10 Definition of Country". This is an issue that has been debated many times over many years and needs a solution. The Solution Definition below is based on a presentation made at RIPE 78 by the RIPE NCC. There has been very little discussion on this since RIPE 78 so perhaps we can have a final round of pros and cons over this next week and then see if we have a consensus. cheersdenis co-chair DB-WG NWI-10 Definition of Country Problem DefinitionThere is no clarity for the meaning of the country code attribute in the RIPE Database and the Extended Delegated statistics. This creates confusion and inconsistencies. Historically the country code was used to refer to the location of the network. Until recently this location was, in most cases, identical to the legal presence of the resource holder. However, in recent years there has been a growing number of resource holders that have, for various reasons, their legal presence in one country, but the network located in another country. There is also a growing number of out-of-region members resulting in an increase in requests to update the country code in the Extended Delegated Statistics for different purposes (e.g. commercial). While the country code attribute in the RIPE Database can be updated directly by the resource holder, the Extended Delegated Statistics are maintained by the RIPE NCC and they were created as part of a joint effort from the RIRs with a specific purpose. Solution Definition1. The country code for resource objects in the RIPE Database should remain as it is currently, ie the resource holder remains responsible for maintaining this attribute and deciding what the country code should be, according to whatever criteria best suits their needs. 2. A new attribute should be added to the ORGANISATION object, which contains a country code that refers to where the resource holder is legally based. The RIPE NCC would be responsible for this field and would only make updates to this field after being provided with documentation that proves the resources holder is legally-based in another country. This would essentially be the same process for updating an organisation's legal name currently. 3. The new country code value in the ORGANISATION object would then be reflected in the Extended Delegated Statistics – so that this file will show where the holder of a resource is legally based and will not make any claims about where the resources are being used. This will ensure the Extended Delegated Statistics file is consistent with those published by the other RIRs. This may mean there is a greater divergence between the country code contained in resource objects in the RIPE Database and those listed in the statistics file. As the country code in the resource objects only has meaning to the resource holder, which should be made clear, this should not be a problem.
Peace, On Mon, Oct 7, 2019, 12:30 PM ripedenis--- via db-wg <db-wg@ripe.net> wrote:
The DB-WG chairs have agreed to create "NWI-10 Definition of Country". This is an issue that has been debated many times over many years and needs a solution.
What particular issue is this a solution for? The whole IP-to-country-code mapping story is and has always inevitably been technologically MUBAR. (Replacing "F" with "M" for "messed" only b/c it's a public mailing list which kids may be reading.) What is even more important, there's no reason to even try to sort out that mess b/c virtually any problem that could be solved with such a mapping either could also be solved in a much more appropriate way without it, with the rest of the data in RIPE DB available, or doesn't need a solution at all. Having a company deciding by itself on what country code explains its operations in the best way appears to work just fine. OTOH, I can't notice any particular benefit from populating the DB with a number of BVI or LUX entries. -- Töma
In message <CALZ3u+anKFULDRsx1HymnFrVJ36heMgM-a9VAQajZM_sr4dTuw@mail.gmail.com> =?utf-8?q?T=C3=B6ma_Gavrichenkov_via_db-wg?= <db-wg@ripe.net> wrote:
Having a company deciding by itself on what country code explains its operations in the best way appears to work just fine.
I beg to disagree. No,. it doesn't. Allowing organizations to specify their primary country of operations as "ZZ" or "Fantasystan" or to utterly fail to designate any country at all is not my definition of "working fine". Regards, rfg
As a point of information, APNIC uses cc "ZZ" specifically for unallocated and "stub" (outward transferred) records. ZZ is an ISO3166 assigned code for "unknown" -George On Tue, Oct 8, 2019 at 4:56 AM Ronald F. Guilmette via db-wg <db-wg@ripe.net> wrote:
In message <CALZ3u+anKFULDRsx1HymnFrVJ36heMgM-a9VAQajZM_sr4dTuw@mail.gmail.com> =?utf-8?q?T=C3=B6ma_Gavrichenkov_via_db-wg?= <db-wg@ripe.net> wrote:
Having a company deciding by itself on what country code explains its operations in the best way appears to work just fine.
I beg to disagree. No,. it doesn't.
Allowing organizations to specify their primary country of operations as "ZZ" or "Fantasystan" or to utterly fail to designate any country at all is not my definition of "working fine".
Regards, rfg
In message <CAKr6gn1QRwJrnjD+tqFth8SJ5x=EyTi=Np36V_ctaxpASjFnnw@mail.gmail.com>, George Michaelson <ggm@algebras.org> wrote:
As a point of information, APNIC uses cc "ZZ" specifically for unallocated and "stub" (outward transferred) records.
ZZ is an ISO3166 assigned code for "unknown"
Thank you for pointing this out. It is an interesting point of curiosity, but as I am sure you realize, this particular small factoid neither rebutts nor dininishes my basic thesis, which is (a) that all resource and organization records should have a country: and (b) that the values in these country: fields should obey either some generally accepted and recognized standard (e.g. ISO 3166) or at the very least some well defined and well documented convention. Regards, rfg
There was an implication in your mail that no WHOIS records should have ZZ. There are specific reasons *some* WHOIS records have ZZ. I understand you want *delegated* WHOIS records to have valid economies. FYI the readme of delegated-extened and the non-exteded delegated statistics files for the RIR (and the # comments) are very clear that the *intent* of the economy field in these compressed reports, is not Geolocation of the IP ranges, but is about the entity registration. The Organization object may be doing a better job of accounting for that, but changing Both format, and semantic intent of things like the delegated statistics report is a complex, tedious process. -George On Tue, Oct 8, 2019 at 8:38 AM Ronald F. Guilmette via db-wg <db-wg@ripe.net> wrote:
In message <CAKr6gn1QRwJrnjD+tqFth8SJ5x=EyTi=Np36V_ctaxpASjFnnw@mail.gmail.com>, George Michaelson <ggm@algebras.org> wrote:
As a point of information, APNIC uses cc "ZZ" specifically for unallocated and "stub" (outward transferred) records.
ZZ is an ISO3166 assigned code for "unknown"
Thank you for pointing this out.
It is an interesting point of curiosity, but as I am sure you realize, this particular small factoid neither rebutts nor dininishes my basic thesis, which is (a) that all resource and organization records should have a country: and (b) that the values in these country: fields should obey either some generally accepted and recognized standard (e.g. ISO 3166) or at the very least some well defined and well documented convention.
Regards, rfg
In message <CAKr6gn04LMMs5ALEZoO_2hhuMG4t78XeWwun+FzA8xk7PDBphA@mail.gmail.com> George Michaelson <ggm@algebras.org> wrote:
There was an implication in your mail that no WHOIS records should have ZZ.
There are specific reasons *some* WHOIS records have ZZ.
I'm fine with that, if the associated record does not describe any actual organization, other than an RIR, or any actual alloctable number resource.
I understand you want *delegated* WHOIS records to have valid economies.
Yes.
FYI the readme of delegated-extened and the non-exteded delegated statistics files for the RIR (and the # comments) are very clear that the *intent* of the economy field in these compressed reports, is not Geolocation of the IP ranges, but is about the entity registration.
I am also fine with having the country: values -consistantly- represent even the favorite holiday destinations of the CEOs of the relevant organizations, as long as this is done -consistantly-. I don't really care that much what the community elects to have these values mean, exactly, as long as values *are* present in all records where the community believes that they should appear, and as long as there is -some- consistant meaning for this information. Right now, there is no consistancy at all, either in terms of the intended meaning, or the syntax, or even the presence/absence of the field, thus rendering the data base an utter shambles and making any productive use of the country: fields, across the entire data base, essentially impossible. A present, the country: values have about as much value as your typical pub dartboard does in the way of predicting tomorrow's weather.... assuming, in some cases at least, that you even remove all of the darts. Regards, rfg
George Michaelson via db-wg <db-wg@ripe.net> wrote:
As a point of information, APNIC uses cc "ZZ" specifically for unallocated and "stub" (outward transferred) records.
ZZ is an ISO3166 assigned code for "unknown"
Which reminds me of some of the more horrible code I have shipped. FreeBSD's whois client tries to know as little as possible about which whois server it needs to ask for which query, and instead starts from IANA and follows referrals. This works surprisingly well given that there isn't a standard for whois referrals and there are at least 5 referral formats out there. The main point where this strategy fails is for IP address queries, because RIPE and APNIC only say "dunno" rather than providing a referral. This is kind of annoying since I believe they have the necessary information and expose it via RDAP, but omit it via whois. So the whois client guesses that ARIN might be more helpful and in horrible cases might try all the RIRs in turn. Yuck. https://svnweb.freebsd.org/base/head/usr.bin/whois/whois.c?revision=326025&view=markup#l124 Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Channel Islands: West to southwest 5 to 6, increasing locally 7 at times. Rather rough to rough, locally moderate in the far southeast. Isolated showers, becoming more frequent and locally heavy overnight, with isolated thunderstorms developing by tomorrow morning. Good, occasionally moderate, but poor in heavy showers.
ripedenis--- via db-wg wrote on 07/10/2019 10:28:
There has been very little discussion on this since RIPE 78 so perhaps we can have a final round of pros and cons over this next week and then see if we have a consensus.
more context: https://ripe78.ripe.net/archives/video/118/ Nick
ripedenis--- via db-wg wrote on 07/10/2019 10:28:
While the country code attribute in the RIPE Database can be updated directly by the resource holder, the Extended Delegated Statistics are maintained by the RIPE NCC and they were created as part of a joint effort from the RIRs with a specific purpose.
fwiw, the proposed solution looks fine to me. I would be happy to see it proceed. Nick
On Mon, 7 Oct 2019, Nick Hilliard via db-wg wrote:
ripedenis--- via db-wg wrote on 07/10/2019 10:28:
While the country code attribute in the RIPE Database can be updated directly by the resource holder, the Extended Delegated Statistics are maintained by the RIPE NCC and they were created as part of a joint effort from the RIRs with a specific purpose.
fwiw, the proposed solution looks fine to me. I would be happy to see it proceed.
Nick
+1 Carlos
In message <521118721.6532191.1570440537653@mail.yahoo.com>, "ripedenis@yahoo.co.uk" <ripedenis@yahoo.co.uk> wrote:
The DB-WG chairs have agreed to create "NWI-10 Definition of Country". This is an issue that has been debated many times over many years and needs a solution. The Solution Definition below is based on a presentation made at RIPE 78 by the RIPE NCC.
I applaud any and all efforts to improve upon the current situation with respect to country designations within the data base. That having been said, I want to take this opportunity to note once again the two issues which, for me at least, are of overriding concern: *) There current exist in the data base many many organization and resource records for which there is a total absence of -any- indication of the relevant country. *) There current exist in the data base many many organization and resource records for which the actual text of the country designation obeys no known standard whatsoever. For anyone attempting to perform even the most basic analysis of data base objects, it is bad enough that many records properly use ISO 3166 two-letter country code designations (e.g. "FR") while many others spell the country name out in full (e.g. "France"), but an even more dauting challenge to any kind of automated analysis is presented in those cases... and there are many... where -neither- of these standards is obeyed. There are quite certainly entries in the data base whose two-letter country designations appear to have been drawn at random from an alphabet soup. Quite obviously, these defy all rasonable attempts at automated analysis. In other cases, the intent is clear, but the designations are still problematic in the context of automated analysis. I am speaking now specifically of the many data abase objects whose "country" designations are "EU". I do well and and turly understand the rationale of those who have used this "country" designation, but it is quite definitly not a standardized ISO 3166 designation and thuse cauuses more problems than it solves. I would like to see its use outright banned. I have previously proposed that the NCC take meaures to introduce reasonable and, in most cases, obvious remedies for the above two problems. I have further offered to volunteer my own time towards this effort, and to share the many logical inferences that I've already worked out for many many specific data base objects (e.g. if some address: line mentions "Sofia" then in the absence of any other clear indication to the contrary, it is reasonable to infer that "BG" should be the country code). I say again that I am perfectly in favor of this new proposal, NWI-10, as promulgated by the chair, and that I welcome any proposal to move things in a positive direction, however modest. That having been said however, it appears to me that NWI-10 is only aimed at making small improvements around the edges. It certainly makes no attempt to address either of the two glaring issues and gaping wounds that I've noted, yet again, above. So this naturally causes me to raise, the question, in my own mind at least, of what it might take to generate some interest in attacking these two overriding issues that I have reiterated above. Why does everyone seem so content to simply ignore these very serious issues? And what sort of verbal Molotov cocktail can I possibly hurl into this abyss of silence about these problems that might make anyone here sit up and give a darn? I support NWI-10 and applaud the chair for bringing it forward. But even its full adoption and implementation will, I'm afraid, amount to little more than putting lipstick on a pig so long as the very nature of country designations in the data base, and even the need for such remains, as it is now, subject to whim, personal fancy, and unrestricted interpretation. Regards, rfg
+1 On Mon, Oct 7, 2019 at 11:30 AM ripedenis--- via db-wg <db-wg@ripe.net> wrote:
Colleagues
The DB-WG chairs have agreed to create "NWI-10 Definition of Country". This is an issue that has been debated many times over many years and needs a solution. The Solution Definition below is based on a presentation made at RIPE 78 by the RIPE NCC.
There has been very little discussion on this since RIPE 78 so perhaps we can have a final round of pros and cons over this next week and then see if we have a consensus.
cheers denis
co-chair DB-WG
NWI-10 Definition of Country
Problem Definition There is no clarity for the meaning of the country code attribute in the RIPE Database and the Extended Delegated statistics. This creates confusion and inconsistencies.
Historically the country code was used to refer to the location of the network. Until recently this location was, in most cases, identical to the legal presence of the resource holder. However, in recent years there has been a growing number of resource holders that have, for various reasons, their legal presence in one country, but the network located in another country. There is also a growing number of out-of-region members resulting in an increase in requests to update the country code in the Extended Delegated Statistics for different purposes (e.g. commercial).
While the country code attribute in the RIPE Database can be updated directly by the resource holder, the Extended Delegated Statistics are maintained by the RIPE NCC and they were created as part of a joint effort from the RIRs with a specific purpose.
Solution Definition 1. The country code for resource objects in the RIPE Database should remain as it is currently, ie the resource holder remains responsible for maintaining this attribute and deciding what the country code should be, according to whatever criteria best suits their needs.
2. A new attribute should be added to the ORGANISATION object, which contains a country code that refers to where the resource holder is legally based. The RIPE NCC would be responsible for this field and would only make updates to this field after being provided with documentation that proves the resources holder is legally-based in another country. This would essentially be the same process for updating an organisation's legal name currently.
3. The new country code value in the ORGANISATION object would then be reflected in the Extended Delegated Statistics – so that this file will show where the holder of a resource is legally based and will not make any claims about where the resources are being used. This will ensure the Extended Delegated Statistics file is consistent with those published by the other RIRs. This may mean there is a greater divergence between the country code contained in resource objects in the RIPE Database and those listed in the statistics file. As the country code in the resource objects only has meaning to the resource holder, which should be made clear, this should not be a problem.
+1 Thank you for the well-reasoned proposal to fix an issue that has been a problem for far too long. Jacob Slater On Mon, Oct 7, 2019 at 5:31 AM ripedenis--- via db-wg <db-wg@ripe.net> wrote:
Colleagues
The DB-WG chairs have agreed to create "NWI-10 Definition of Country". This is an issue that has been debated many times over many years and needs a solution. The Solution Definition below is based on a presentation made at RIPE 78 by the RIPE NCC.
There has been very little discussion on this since RIPE 78 so perhaps we can have a final round of pros and cons over this next week and then see if we have a consensus.
cheers denis
co-chair DB-WG
NWI-10 Definition of Country
Problem Definition There is no clarity for the meaning of the country code attribute in the RIPE Database and the Extended Delegated statistics. This creates confusion and inconsistencies.
Historically the country code was used to refer to the location of the network. Until recently this location was, in most cases, identical to the legal presence of the resource holder. However, in recent years there has been a growing number of resource holders that have, for various reasons, their legal presence in one country, but the network located in another country. There is also a growing number of out-of-region members resulting in an increase in requests to update the country code in the Extended Delegated Statistics for different purposes (e.g. commercial).
While the country code attribute in the RIPE Database can be updated directly by the resource holder, the Extended Delegated Statistics are maintained by the RIPE NCC and they were created as part of a joint effort from the RIRs with a specific purpose.
Solution Definition 1. The country code for resource objects in the RIPE Database should remain as it is currently, ie the resource holder remains responsible for maintaining this attribute and deciding what the country code should be, according to whatever criteria best suits their needs.
2. A new attribute should be added to the ORGANISATION object, which contains a country code that refers to where the resource holder is legally based. The RIPE NCC would be responsible for this field and would only make updates to this field after being provided with documentation that proves the resources holder is legally-based in another country. This would essentially be the same process for updating an organisation's legal name currently.
3. The new country code value in the ORGANISATION object would then be reflected in the Extended Delegated Statistics – so that this file will show where the holder of a resource is legally based and will not make any claims about where the resources are being used. This will ensure the Extended Delegated Statistics file is consistent with those published by the other RIRs. This may mean there is a greater divergence between the country code contained in resource objects in the RIPE Database and those listed in the statistics file. As the country code in the resource objects only has meaning to the resource holder, which should be made clear, this should not be a problem.
participants (9)
-
Carlos Friaças
-
Cynthia Revström
-
George Michaelson
-
Jacob Slater
-
Nick Hilliard
-
ripedenis@yahoo.co.uk
-
Ronald F. Guilmette
-
Tony Finch
-
Töma Gavrichenkov