You are here: Home > Participate > Join a Discussion > RIPE Forum
RIPE Forum v1.4.1

Database Working Group

Threaded
Collapse

[db-wg] NWI-10 Definition of Country

ripedenis@yahoo.co.uk

2019-10-07 11:28:57 CET

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.

User Image

Artyom Gavrichenkov

2019-10-07 12:01:34 CET

Peace,

On Mon, Oct 7, 2019, 12:30 PM ripedenis--- via db-wg <db-wg _at_ ripe _dot_ 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

Nick Hilliard

2019-10-07 14:52:10 CET

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


Nick Hilliard

2019-10-07 14:54:51 CET

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

User Image

Carlos Friacas

2019-10-07 17:08:35 CET

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


Ronald F. Guilmette

2019-10-07 20:51:32 CET

In message <521118721.6532191.1570440537653 _at_ mail.yahoo _dot_ com>, 
"ripedenis _at_ yahoo.co _dot_ uk" <ripedenis _at_ yahoo.co _dot_ 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


Ronald F. Guilmette

2019-10-07 20:56:32 CET

In message <CALZ3u+anKFULDRsx1HymnFrVJ36heMgM-a9VAQajZM_sr4dTuw _at_ mail.gmail _dot_ com>
=?utf-8?q?T=C3=B6ma_Gavrichenkov_via_db-wg?= <db-wg _at_ ripe _dot_ 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

George Michaelson

2019-10-08 00:29:26 CET

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 _at_ ripe _dot_ net> wrote:
>
> In message <CALZ3u+anKFULDRsx1HymnFrVJ36heMgM-a9VAQajZM_sr4dTuw _at_ mail.gmail _dot_ com>
> =?utf-8?q?T=C3=B6ma_Gavrichenkov_via_db-wg?= <db-wg _at_ ripe _dot_ 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
>

Ronald F. Guilmette

2019-10-08 00:38:16 CET

In message Np36V_ctaxpASjFnnw _at_ mail.gmail _dot_ com>, 
 George Michaelson <ggm _at_ algebras _dot_ 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

George Michaelson

2019-10-08 03:31:38 CET

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 _at_ ripe _dot_ net> wrote:
>
> In message Np36V_ctaxpASjFnnw _at_ mail.gmail _dot_ com>,
>  George Michaelson <ggm _at_ algebras _dot_ 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
>

Ronald F. Guilmette

2019-10-08 07:44:54 CET

In message <CAKr6gn04LMMs5ALEZoO_2hhuMG4t78XeWwun+FzA8xk7PDBphA _at_ mail.gmail _dot_ com>
George Michaelson <ggm _at_ algebras _dot_ 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


Tony Finch

2019-10-08 13:13:18 CET

George Michaelson via db-wg <db-wg _at_ ripe _dot_ 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 _at_ dotat _dot_ 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.

User Image

Cynthia Revström

2019-10-08 15:38:47 CET

+1

On Mon, Oct 7, 2019 at 11:30 AM ripedenis--- via db-wg <db-wg _at_ ripe _dot_ 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.
>
>
>
User Image

Jacob Slater

2019-10-08 15:40:54 CET

+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 _at_ ripe _dot_ 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.
>
>

User Image

Arash Naderpour

2019-11-01 05:36:49 CET

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

ripedenis@yahoo.co.uk

2019-11-01 13:52:12 CET

 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 fileftp://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 countriesIf 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.
cheersdenis
co-chair DB-WG
    On Friday, 1 November 2019, 05:37:28 CET, Arash Naderpour via db-wg <db-wg _at_ ripe _dot_ 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 NaderpourParsun Network Solutions    
User Image

Sanjaya Sanjaya

2019-11-01 21:35:37 CET

Hi Denis, Arash and all,

Just a thought, maybe we could redefine the RIR extended delegated file format to incorporate both cc values of inet(6)num|autnum and organisation Whois objects like this:

registry|xx|type|start|value|date|status|yy-custodianid

Where:

xx = country code of inet(6)num|autnum

yy = country code of organisation

This will require agreement among the RIRs and some adjustments by the relying parties, but provides a clearer mapping between Whois objects and the stats file records. My 2 cents.

Cheers,
Sanjaya


________________________________
From: db-wg <db-wg-bounces _at_ ripe _dot_ net> on behalf of ripedenis--- via db-wg <db-wg _at_ ripe _dot_ net>
Sent: Friday, November 1, 2019 10:52:12 PM
To: DB-WG <db-wg _at_ ripe _dot_ net>
Subject: Re: [db-wg] NWI-10 Definition of Country

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 _at_ ripe _dot_ 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
________________________________
From: db-wg <db-wg-bounces _at_ ripe _dot_ net> on behalf of ripedenis--- via db-wg <db-wg _at_ ripe _dot_ net>
Sent: Friday, November 1, 2019 10:52:12 PM
To: DB-WG <db-wg _at_ ripe _dot_ net>
Subject: Re: [db-wg] NWI-10 Definition of Country

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 _at_ ripe _dot_ 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
User Image

Arash Naderpour

2019-11-06 12:05:39 CET

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 _at_ yahoo.co _dot_ 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 _at_ ripe _dot_ 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
>

Leo Vegoda

2019-11-06 17:43:01 CET

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

User Image

Arash Naderpour

2019-11-08 05:22:10 CET

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 _at_ icann _dot_ 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
>
>
User Image

Sanjaya Sanjaya

2019-11-08 06:16:24 CET

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 _at_ ripe _dot_ net> On Behalf Of Arash Naderpour via db-wg
Sent: Friday, 8 November 2019 2:22 PM
To: Leo Vegoda <leo.vegoda _at_ icann _dot_ org>
Cc: db-wg _at_ ripe _dot_ net; denis walker <dw100uk _at_ yahoo.co _dot_ 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 _at_ icann _dot_ orgleo.vegoda _at_ icann _dot_ 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
User Image

Randy Bush

2019-11-08 08:32:50 CET

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

User Image

Sanjaya Sanjaya

2019-11-08 10:15:15 CET

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 _at_ ripe _dot_ net> on behalf of Randy Bush via db-wg <db-wg _at_ ripe _dot_ net>
Sent: Friday, November 8, 2019 5:32:50 PM
To: Sanjaya Sanjaya via db-wg <db-wg _at_ ripe _dot_ 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

Leo Vegoda

2019-11-08 17:33:30 CET

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