Database Working Group

Colleagues

We have a number of outstanding issues from RIPE 85 so let's start
with NWI-10. Ed said in his update,
"Country code is now editable in organisations without co-maintained resources"
I think this is a really bad idea.

The country codes entered into ORGANISATION objects by the RIPE NCC
are well defined, verified and maintained by the RIPE NCC. If we allow
users to edit this field in other ORGANISATION objects, the values
they enter will be undefined, unverified and meaningless. Just like
the country code in resource objects. I don't think we should allow
more meaningless data to be added to the RIPE Database. Even worse, we
are mixing well defined data with meaningless data in the same
attribute in the same object. This will end up with some people
trusting all of this data and some people not trusting any of
it...confusion.

I suggest we don't allow users to enter any data into this attribute
and remove any data that may have already been entered. If there is a
need for resource holders to enter a country code in ORGANISATION
objects set up for end users, then let's define a specific attribute
for that with a well defined meaning. Your thoughts are welcome...

cheers
denis
co-chair DB-WG

Hi denis,

I have to say that I don't agree with you at all here.
The current state of this is just the same as the org-name attribute which
is user editable in organisations without co-maintained resources.
It doesn't make sense to me to somehow give this country attribute more
weight than the org-name attribute.
It also doesn't make sense to me to have different country code attributes
for orgs with co-maintained resources compared to those without
co-maintained resources.

If you think this is a problem I would say that the better solution here is
to have a different org-type for organizations that have co-maintained
resources.
That way we could communicate that some attributes are verified/maintained
by the RIPE NCC for orgs with co-maintained resources.

Personally, I don't see how having country codes that are unverified for
orgs without co-maintained resources is a real issue, but if people think
that the mixing of verified and unverified data is an issue then I would
propose the org-type solution.

-Cynthia

On Tue, Jan 10, 2023 at 2:03 PM denis walker via db-wg <db-wg _at_ ripe _dot_ net>
wrote:

> Colleagues
>
> We have a number of outstanding issues from RIPE 85 so let's start
> with NWI-10. Ed said in his update,
> "Country code is now editable in organisations without co-maintained
> resources"
> I think this is a really bad idea.
>
> The country codes entered into ORGANISATION objects by the RIPE NCC
> are well defined, verified and maintained by the RIPE NCC. If we allow
> users to edit this field in other ORGANISATION objects, the values
> they enter will be undefined, unverified and meaningless. Just like
> the country code in resource objects. I don't think we should allow
> more meaningless data to be added to the RIPE Database. Even worse, we
> are mixing well defined data with meaningless data in the same
> attribute in the same object. This will end up with some people
> trusting all of this data and some people not trusting any of
> it...confusion.
>
> I suggest we don't allow users to enter any data into this attribute
> and remove any data that may have already been entered. If there is a
> need for resource holders to enter a country code in ORGANISATION
> objects set up for end users, then let's define a specific attribute
> for that with a well defined meaning. Your thoughts are welcome...
>
> cheers
> denis
> co-chair DB-WG
>
> --
>
> To unsubscribe from this mailing list, get a password reminder, or change
> your subscription options, please visit:
> https://lists.ripe.net/mailman/listinfo/db-wg
>

Hi Cynthia

On Tue, 10 Jan 2023 at 15:13, Cynthia Revström <me _at_ cynthia _dot_ re> wrote:
>
> Hi denis,
>
> I have to say that I don't agree with you at all here.
> The current state of this is just the same as the org-name attribute which is user editable in organisations without co-maintained resources.
> It doesn't make sense to me to somehow give this country attribute more weight than the org-name attribute.

They are 2 very different attributes. The issue is not that the user
can edit the data but what does the data mean. The org-name is a free
text label by which the organisation can be known. That is well
defined and we all know what it means. If the org-name is 'Walker
Enterprises' then everyone knows that the organisation holding this
assignment is known as Walker Enterprises.

If the country in the ORGANISATION object is NL what does that mean?
There are many multinational organisations in this region. They may
have a legal address, corporate HQ, server centres, operations
centres, offices... These may be spread across multiple countries. The
"country:" attribute is a single value. Which one does it represent?
It may be different to the country mentioned in the "address:"
attributes of the same object. If you create an ORGANISATION object
for one of your end users, you and your end user know what the value
means. I and the rest of the world have no idea.

This is the issue...this data entered by a user has no meaning to any
other database user. You cannot deduce anything from it or assume
anything about it.  But people will start making assumptions about it,
especially in the geo location area, as they have done for years with
the also meaningless country values in INET(6)NUM objects.

> It also doesn't make sense to me to have different country code attributes for orgs with co-maintained resources compared to those without co-maintained resources.
>
> If you think this is a problem I would say that the better solution here is to have a different org-type for organizations that have co-maintained resources.

You don't need a different org-type to identify co-maintenance as you
can see this from the mnt-by attributes.

> That way we could communicate that some attributes are verified/maintained by the RIPE NCC for orgs with co-maintained resources.
>
> Personally, I don't see how having country codes that are unverified for orgs without co-maintained resources is a real issue, but if people think that the mixing of verified and unverified data is an issue then I would propose the org-type solution.

It is not an issue about verification, that doesn't really matter in
this instance. It is the fact that this user edited data has no
meaning and is of no value or use to anyone besides the person who
entered it.

cheers
denis
co-chair DB-WG


>
> -Cynthia
>
> On Tue, Jan 10, 2023 at 2:03 PM denis walker via db-wg <db-wg _at_ ripe _dot_ net> wrote:
>>
>> Colleagues
>>
>> We have a number of outstanding issues from RIPE 85 so let's start
>> with NWI-10. Ed said in his update,
>> "Country code is now editable in organisations without co-maintained resources"
>> I think this is a really bad idea.
>>
>> The country codes entered into ORGANISATION objects by the RIPE NCC
>> are well defined, verified and maintained by the RIPE NCC. If we allow
>> users to edit this field in other ORGANISATION objects, the values
>> they enter will be undefined, unverified and meaningless. Just like
>> the country code in resource objects. I don't think we should allow
>> more meaningless data to be added to the RIPE Database. Even worse, we
>> are mixing well defined data with meaningless data in the same
>> attribute in the same object. This will end up with some people
>> trusting all of this data and some people not trusting any of
>> it...confusion.
>>
>> I suggest we don't allow users to enter any data into this attribute
>> and remove any data that may have already been entered. If there is a
>> need for resource holders to enter a country code in ORGANISATION
>> objects set up for end users, then let's define a specific attribute
>> for that with a well defined meaning. Your thoughts are welcome...
>>
>> cheers
>> denis
>> co-chair DB-WG
>>
>> --
>>
>> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg

> [...]  But people will start making assumptions about it,
> especially in the geo location area, as they have done for
> years with the also meaningless country values in INET(6)NUM
> objects.

Following up on the tangent of "contry" for inet(6)num objects:

I realize that there are cases where the address space is in use in
multiple countries.  However, I would guess that is rather the
exception than the rule.  Would it not have been nice if a network
address holder could indicate to geo location providers a "full
override" to "idiot automation" that "yes, the entirety of use of
this address space is being used by users who come from within the
borders of this country"?  This would then work irrespective of
e.g. users bringing their cell phones with them with (GPS and other)
location services turned on to vacations in faraway places and
VPNing in to your network, and immediately causing all your VPN
users for that VPN concentrator to be geo-located to that country?
(Yes, we have had that happen, and getting it fixed is apparently
going to take months!)

That would make it so that the geo-feed URLs would only be necessary
to maintain and serve a useful purpose for those address space
holders which use their address space in more than one country.

It's permitted to dream, right?

Yes, I know, getting universal agreement on this or something like
it from all the sundry geo-location providers is basically *never*
going to happen, and instead the geo-location providers farm out the
effort of collecting and maintaining geo-location data to all the
address space holders instead.  Sigh!

And for IPv6 you basically have to list shorter prefixes than what
the "idiot automation" insists on using internally but in all
probability does not document externally, so you have to rely on
unsubstantiated rumours from other ISPs.  Double sigh!

And each attempt apparently has a "duty cycle" of a month or more.
Triple sigh!

Geo location providers are just the worst to work with!
Particularly if you have not had to bother with them earlier.

Best regards,

- Håvard

Ah, I guess I misunderstood you then.
However I still don't really see this as an issue if it can help some orgs
work around weird geoip providers.
I still don't support this proposal, sorry.

-Cynthia

On Thu, Jan 12, 2023 at 11:31 AM denis walker <ripedenis _at_ gmail _dot_ com> wrote:

> Hi Cynthia
>
> On Tue, 10 Jan 2023 at 15:13, Cynthia Revström <me _at_ cynthia _dot_ re> wrote:
> >
> > Hi denis,
> >
> > I have to say that I don't agree with you at all here.
> > The current state of this is just the same as the org-name attribute
> which is user editable in organisations without co-maintained resources.
> > It doesn't make sense to me to somehow give this country attribute more
> weight than the org-name attribute.
>
> They are 2 very different attributes. The issue is not that the user
> can edit the data but what does the data mean. The org-name is a free
> text label by which the organisation can be known. That is well
> defined and we all know what it means. If the org-name is 'Walker
> Enterprises' then everyone knows that the organisation holding this
> assignment is known as Walker Enterprises.
>
> If the country in the ORGANISATION object is NL what does that mean?
> There are many multinational organisations in this region. They may
> have a legal address, corporate HQ, server centres, operations
> centres, offices... These may be spread across multiple countries. The
> "country:" attribute is a single value. Which one does it represent?
> It may be different to the country mentioned in the "address:"
> attributes of the same object. If you create an ORGANISATION object
> for one of your end users, you and your end user know what the value
> means. I and the rest of the world have no idea.
>
> This is the issue...this data entered by a user has no meaning to any
> other database user. You cannot deduce anything from it or assume
> anything about it.  But people will start making assumptions about it,
> especially in the geo location area, as they have done for years with
> the also meaningless country values in INET(6)NUM objects.
>
> > It also doesn't make sense to me to have different country code
> attributes for orgs with co-maintained resources compared to those without
> co-maintained resources.
> >
> > If you think this is a problem I would say that the better solution here
> is to have a different org-type for organizations that have co-maintained
> resources.
>
> You don't need a different org-type to identify co-maintenance as you
> can see this from the mnt-by attributes.
>
> > That way we could communicate that some attributes are
> verified/maintained by the RIPE NCC for orgs with co-maintained resources.
> >
> > Personally, I don't see how having country codes that are unverified for
> orgs without co-maintained resources is a real issue, but if people think
> that the mixing of verified and unverified data is an issue then I would
> propose the org-type solution.
>
> It is not an issue about verification, that doesn't really matter in
> this instance. It is the fact that this user edited data has no
> meaning and is of no value or use to anyone besides the person who
> entered it.
>
> cheers
> denis
> co-chair DB-WG
>
>
> >
> > -Cynthia
> >
> > On Tue, Jan 10, 2023 at 2:03 PM denis walker via db-wg <db-wg _at_ ripe _dot_ net>
> wrote:
> >>
> >> Colleagues
> >>
> >> We have a number of outstanding issues from RIPE 85 so let's start
> >> with NWI-10. Ed said in his update,
> >> "Country code is now editable in organisations without co-maintained
> resources"
> >> I think this is a really bad idea.
> >>
> >> The country codes entered into ORGANISATION objects by the RIPE NCC
> >> are well defined, verified and maintained by the RIPE NCC. If we allow
> >> users to edit this field in other ORGANISATION objects, the values
> >> they enter will be undefined, unverified and meaningless. Just like
> >> the country code in resource objects. I don't think we should allow
> >> more meaningless data to be added to the RIPE Database. Even worse, we
> >> are mixing well defined data with meaningless data in the same
> >> attribute in the same object. This will end up with some people
> >> trusting all of this data and some people not trusting any of
> >> it...confusion.
> >>
> >> I suggest we don't allow users to enter any data into this attribute
> >> and remove any data that may have already been entered. If there is a
> >> need for resource holders to enter a country code in ORGANISATION
> >> objects set up for end users, then let's define a specific attribute
> >> for that with a well defined meaning. Your thoughts are welcome...
> >>
> >> cheers
> >> denis
> >> co-chair DB-WG
> >>
> >> --
> >>
> >> To unsubscribe from this mailing list, get a password reminder, or
> change your subscription options, please visit:
> https://lists.ripe.net/mailman/listinfo/db-wg
>

Hello Denis

Sorry to ask but, how is this country code used / what their meaning when it is entered by RIPE NCC itself?

It appears to me that the challenge on "what to place" would be the same.

Regards

--
INCIBE-CERT - Spanish National CSIRT
https://www.incibe-cert.es/

PGP keys: https://www.incibe-cert.es/en/what-is-incibe-cert/pgp-public-keys

====================================================================

INCIBE-CERT is the Spanish National CSIRT designated for citizens,
private law entities, other entities not included in the subjective
scope of application of the "Ley 40/2015, de 1 de octubre, de Régimen
Jurídico del Sector Público", as well as digital service providers,
operators of essential services and critical operators under the terms
of the "Real Decreto-ley 12/2018, de 7 de septiembre, de seguridad de
las redes y sistemas de información" that transposes the Directive (EU)
2016/1148 of the European Parliament and of the Council of 6 July 2016
concerning measures for a high common level of security of network and
information systems across the Union.

====================================================================

In compliance with the General Data Protection Regulation of the EU
(Regulation EU 2016/679, of 27 April 2016) we inform you that your
personal and corporate data (as well as those included in attached
documents); and e-mail address, may be included in our records
for the purpose derived from legal, contractual or pre-contractual
obligations or in order to respond to your queries. You may exercise
your rights of access, correction, cancellation, portability,
limitationof processing and opposition under the terms established by
current legislation and free of charge by sending an e-mail to
dpd _at_ incibe _dot_ es. The Data Controller is S.M.E. Instituto Nacional de
Ciberseguridad de España, M.P., S.A. More information is available
on our website: https://www.incibe.es/proteccion-datos-personales
and https://www.incibe.es/registro-actividad.

====================================================================

Hi Angel

This is all explained in a RIPE Labs article
https://labs.ripe.net/author/stefania_fokaeos/our-plan-to-update-country-codes/

and was discussed extensively in Oct/Nov 2019 and early 2020 on this
mailing list.

cheers
denis
co-chair DB-WG

On Thu, 12 Jan 2023 at 22:09, Ángel González Berdasco
<angel.gonzalez _at_ incibe _dot_ es> wrote:
>
> Hello Denis
>
> Sorry to ask but, how is this country code used / what their meaning when it is entered by RIPE NCC itself?
>
> It appears to me that the challenge on "what to place" would be the same.
>
> Regards
>
> --
> INCIBE-CERT - Spanish National CSIRT
> https://www.incibe-cert.es/
>
> PGP keys: https://www.incibe-cert.es/en/what-is-incibe-cert/pgp-public-keys
>
> ====================================================================
>
> INCIBE-CERT is the Spanish National CSIRT designated for citizens,
> private law entities, other entities not included in the subjective
> scope of application of the "Ley 40/2015, de 1 de octubre, de Régimen
> Jurídico del Sector Público", as well as digital service providers,
> operators of essential services and critical operators under the terms
> of the "Real Decreto-ley 12/2018, de 7 de septiembre, de seguridad de
> las redes y sistemas de información" that transposes the Directive (EU)
> 2016/1148 of the European Parliament and of the Council of 6 July 2016
> concerning measures for a high common level of security of network and
> information systems across the Union.
>
> ====================================================================
>
> In compliance with the General Data Protection Regulation of the EU
> (Regulation EU 2016/679, of 27 April 2016) we inform you that your
> personal and corporate data (as well as those included in attached
> documents); and e-mail address, may be included in our records
> for the purpose derived from legal, contractual or pre-contractual
> obligations or in order to respond to your queries. You may exercise
> your rights of access, correction, cancellation, portability,
> limitationof processing and opposition under the terms established by
> current legislation and free of charge by sending an e-mail to
> dpd _at_ incibe _dot_ es. The Data Controller is S.M.E. Instituto Nacional de
> Ciberseguridad de España, M.P., S.A. More information is available
> on our website: https://www.incibe.es/proteccion-datos-personales
> and https://www.incibe.es/registro-actividad.
>
> ====================================================================
>
>

Colleagues

Following on from Havard's comments below I would like to expand the
discussion to consider the general use of country codes in the RIPE
Database. As I tend to write long emails that many people don't read,
I'll summarise my main points first then expand on the details for
those who want it.

My suggestions for the community to consider are these:
1/ The country: attribute in ORGANISATION objects is only used to
specify the legal address country of organisations (including
individuals) holding internet resources and is tied to the country
values in the extended delegated stats file. These values are
maintained by the RIPE NCC. This is what the community agreed to when
they accepted the implementation plan for NWI-10.

2/ The country: attribute in ORGANISATION objects cannot be set by
users to meaningless, undefined values for other reasons, as this was
not in the agreed implementation plan.

3/ The country: attribute in INET(6)NUM objects is made optional.

4/ We define the optional country: attribute in INET(6)NUM objects to
be used for geolocation purposes only

5/ If included, this country code will signal that all the addresses
covered by this range/prefix are used within the geographical boundary
of the country value.

6/ The geofeed: attribute can be used where a block of addresses are
used in multiple countries or if more fine grained details are needed.

7/ An optional country: attribute could be added to the AUT-NUM object
if anyone feels it necessary to specify a geolocation for an ASN.

As always your thoughts are welcome...

Now I will expand on some of these points and explain why I am
suggesting them. The implementation plan for NWI-10, which proposed
the addition of a country code in the ORGANISATION object, is
contained in a RIPE Labs article (
https://labs.ripe.net/author/stefania_fokaeos/our-plan-to-update-country-codes/
). This has 3 phases. All of these phases are concerned with the
addition of the legal country for resource holders and syncing that
data with the extended delegated stats. The implementation plan does
not suggest making this attribute available for users to edit for
ORGANISATION objects that are not linked to resource objects. This is
the plan that was agreed to by the community. We therefore have no
community consensus on allowing users to edit this attribute. If
anyone thinks users should be able to edit this attribute we will need
a new consensus. The discussion on that will have to justify the value
of allowing meaningless, undefined data in the database. If some
meaning, other than a legal address synced to the stats file, is
assigned to the user entered data then we will have to justify the
benefit of having two different meanings to the same attribute
dependent on other parameters. The documentation on this attribute
will have to explain the two meanings and the parameters that
determine which meaning applies. Personally I think overloading the
same attribute with the same values set but with two different
meanings is a bad idea.

The use of the country: attribute in INET(6)NUM objects has never been
defined. In the early days of the internet it may have been possible
to assume it was the country where the addresses were used. Without a
clear definition, that cannot be assumed today. The RIPE NCC has been
telling people for the last 20 years that they cannot reliably use
this information for IP to country mapping. But people still do it
anyway. If you have to give the same negative answer to the same
question for 20 years, something is seriously wrong. Data with a fixed
set of values, where the values have a meaning, but the data itself
has no meaning, has no place in this database. So either we give it a
meaning or we deprecate the attribute completely.

Most people seem to assume it can be reliably used for geolocation
purposes. That would be the most obvious use case for this attribute.
Entering an optional value would signify that all the addresses in
this block are used within the geographical boundary of the country
defined by the code. Where the addresses are used in multiple
countries, it may be possible to show this at the assignment object
level. Otherwise the optional country: attribute could be omitted and
the geolocation information would be determined by the geofeed:
attribute.

This issue has been discussed many times over the last couple of
decades. Most recently during the discussion over NWI-10 in Oct/Nov
2019 and early in 2020 on this mailing list. I think it is long
overdue for a resolution...

cheers
denis
co-chair DB-WG


On Thu, 12 Jan 2023 at 15:42, Havard Eidnes <he _at_ uninett _dot_ no> wrote:
>
> > [...]  But people will start making assumptions about it,
> > especially in the geo location area, as they have done for
> > years with the also meaningless country values in INET(6)NUM
> > objects.
>
> Following up on the tangent of "contry" for inet(6)num objects:
>
> I realize that there are cases where the address space is in use in
> multiple countries.  However, I would guess that is rather the
> exception than the rule.  Would it not have been nice if a network
> address holder could indicate to geo location providers a "full
> override" to "idiot automation" that "yes, the entirety of use of
> this address space is being used by users who come from within the
> borders of this country"?  This would then work irrespective of
> e.g. users bringing their cell phones with them with (GPS and other)
> location services turned on to vacations in faraway places and
> VPNing in to your network, and immediately causing all your VPN
> users for that VPN concentrator to be geo-located to that country?
> (Yes, we have had that happen, and getting it fixed is apparently
> going to take months!)
>
> That would make it so that the geo-feed URLs would only be necessary
> to maintain and serve a useful purpose for those address space
> holders which use their address space in more than one country.
>
> It's permitted to dream, right?
>
> Yes, I know, getting universal agreement on this or something like
> it from all the sundry geo-location providers is basically *never*
> going to happen, and instead the geo-location providers farm out the
> effort of collecting and maintaining geo-location data to all the
> address space holders instead.  Sigh!
>
> And for IPv6 you basically have to list shorter prefixes than what
> the "idiot automation" insists on using internally but in all
> probability does not document externally, so you have to rely on
> unsubstantiated rumours from other ISPs.  Double sigh!
>
> And each attempt apparently has a "duty cycle" of a month or more.
> Triple sigh!
>
> Geo location providers are just the worst to work with!
> Particularly if you have not had to bother with them earlier.
>
> Best regards,
>
> - Håvard

Hi Denis,

> On 24 Jan 2023, at 17:19, denis walker via db-wg <db-wg _at_ ripe _dot_ net> wrote:
> 
> Colleagues
> 
> Following on from Havard's comments below I would like to expand the
> discussion to consider the general use of country codes in the RIPE
> Database. As I tend to write long emails that many people don't read,
> I'll summarise my main points first then expand on the details for
> those who want it.
> 
> My suggestions for the community to consider are these:
> 1/ The country: attribute in ORGANISATION objects is only used to
> specify the legal address country of organisations (including
> individuals) holding internet resources and is tied to the country
> values in the extended delegated stats file. These values are
> maintained by the RIPE NCC. This is what the community agreed to when
> they accepted the implementation plan for NWI-10.
> 
> 2/ The country: attribute in ORGANISATION objects cannot be set by
> users to meaningless, undefined values for other reasons, as this was
> not in the agreed implementation plan.
> 

When we introduced NWI-10 we initially did not allow end users to add, update or remove a "country:" attribute on an organisation at all.

However we decided to allow users to update the "country:" attribute on organisations not referenced by resources allocated or assigned by the RIPE NCC, because in this case the attribute value is not maintained by the RIPE NCC, and it is in line with how we treat other attributes such as "org-name:". There is no validation done on "org-name:" either if the organisation is not referenced from any resources issued by the RIPE NCC, it can be set freely by the user.

If the DB-WG wishes us to return to not allowing end users to update "country:" on an organisation at all, then we will do that.

Regards
Ed Shryane
RIPE NCC

Hi Ed

Thanks for the explanation. But as I explained to Cynthia, "org-name:"
and "country:" are very different attributes. The org-name is just a
free text label by which an organisation is known. Whatever label is
specified, people know what its purpose is, even if the value is not
verified by the NCC. With country, the country codes have a well
defined meaning, but when entered by users no one knows what it's
purpose is. Is it the country where the end user is legally based, as
with the NCC verified values? Is it where their servers are based, or
maybe where the majority of their assigned addresses are used, but
perhaps not all of them. We know from the "country:" attribute in the
resource objects that people will interpret this information and often
assign the wrong purpose to it. The RIPE NCC will spend the next 20
years telling people you cannot reliably use (a subset of) this data
for purpose A or B...

cheers
denis
co-chair DB-WG



On Thu, 26 Jan 2023 at 11:54, Edward Shryane <eshryane _at_ ripe _dot_ net> wrote:
>
> Hi Denis,
>
> > On 24 Jan 2023, at 17:19, denis walker via db-wg <db-wg _at_ ripe _dot_ net> wrote:
> >
> > Colleagues
> >
> > Following on from Havard's comments below I would like to expand the
> > discussion to consider the general use of country codes in the RIPE
> > Database. As I tend to write long emails that many people don't read,
> > I'll summarise my main points first then expand on the details for
> > those who want it.
> >
> > My suggestions for the community to consider are these:
> > 1/ The country: attribute in ORGANISATION objects is only used to
> > specify the legal address country of organisations (including
> > individuals) holding internet resources and is tied to the country
> > values in the extended delegated stats file. These values are
> > maintained by the RIPE NCC. This is what the community agreed to when
> > they accepted the implementation plan for NWI-10.
> >
> > 2/ The country: attribute in ORGANISATION objects cannot be set by
> > users to meaningless, undefined values for other reasons, as this was
> > not in the agreed implementation plan.
> >
>
> When we introduced NWI-10 we initially did not allow end users to add, update or remove a "country:" attribute on an organisation at all.
>
> However we decided to allow users to update the "country:" attribute on organisations not referenced by resources allocated or assigned by the RIPE NCC, because in this case the attribute value is not maintained by the RIPE NCC, and it is in line with how we treat other attributes such as "org-name:". There is no validation done on "org-name:" either if the organisation is not referenced from any resources issued by the RIPE NCC, it can be set freely by the user.
>
> If the DB-WG wishes us to return to not allowing end users to update "country:" on an organisation at all, then we will do that.
>
> Regards
> Ed Shryane
> RIPE NCC
>

On Thu, 26 Jan 2023 at 03:55, denis walker via db-wg <db-wg _at_ ripe _dot_ net> wrote:
>
> Hi Ed
>
> Thanks for the explanation. But as I explained to Cynthia, "org-name:"
> and "country:" are very different attributes. The org-name is just a
> free text label by which an organisation is known. Whatever label is
> specified, people know what its purpose is, even if the value is not
> verified by the NCC. With country, the country codes have a well
> defined meaning, but when entered by users no one knows what it's
> purpose is.

I think you have this the wrong way around.

ISO 3166 has a well defined purpose: "The purpose of ISO 3166 is to
define internationally recognized codes of letters and/or numbers that
we can use when we refer to countries and their subdivisions."

https://www.iso.org/iso-3166-country-codes.html

What we are missing is a meaning for the application of these codes in
the context of the RIPE database.

But even if we started to define a meaning at this late stage, who
would choose to use it?

Hi Leo

On Thu, 26 Jan 2023 at 13:48, Leo Vegoda <leo _at_ vegoda _dot_ org> wrote:
>
> On Thu, 26 Jan 2023 at 03:55, denis walker via db-wg <db-wg _at_ ripe _dot_ net> wrote:
> >
> > Hi Ed
> >
> > Thanks for the explanation. But as I explained to Cynthia, "org-name:"
> > and "country:" are very different attributes. The org-name is just a
> > free text label by which an organisation is known. Whatever label is
> > specified, people know what its purpose is, even if the value is not
> > verified by the NCC. With country, the country codes have a well
> > defined meaning, but when entered by users no one knows what it's
> > purpose is.
>
> I think you have this the wrong way around.
>
> ISO 3166 has a well defined purpose: "The purpose of ISO 3166 is to
> define internationally recognized codes of letters and/or numbers that
> we can use when we refer to countries and their subdivisions."
>
> https://www.iso.org/iso-3166-country-codes.html
>
> What we are missing is a meaning for the application of these codes in
> the context of the RIPE database.

This is exactly what I said. In the quoted para above I said "the
country codes have a well defined meaning", which you agree with. Then
I said "but when entered by users no one knows what it's purpose is.".
Another way of saying no one knows their meaning in the context of the
database, which you also agree with.

>
> But even if we started to define a meaning at this late stage, who
> would choose to use it?

In the case of the ORGANISATION object it would be at this 'early'
stage. Which I think would be a bad idea. For the INET(6)NUM objects I
agree it is at a late stage. But for the last 20 years many people
have assumed the country codes relate to geolocation and used the data
in that way. If we define it to mean that now, and make it optional,
we are aligning reality with what so many people already believe. With
clear explanations sent to all resource holders and/or maintainers of
the resource objects, I think we could get this message out there.

cheers
denis
co-chair DB-WG

Dear RIPE DBWG,
Hope this email finds you in good health!

Please see my comment below, inline...

Le mardi 24 janvier 2023, denis walker via db-wg <db-wg _at_ ripe _dot_ net> a écrit :

> Colleagues
>
> [...]
>
> Most people seem to assume it can be reliably used for geolocation
> purposes. That would be the most obvious use case for this attribute.
> Entering an optional value would signify that all the addresses in
> this block are used within the geographical boundary of the country
> defined by the code. Where the addresses are used in multiple
> countries, it may be possible to show this at the assignment object
> level. Otherwise the optional country: attribute could be omitted and
> the geolocation information would be determined by the geofeed:
> attribute.
>
>
Hi Denis,
Thanks for your email, brother!

imho:
...no need to ommit it; if it's possible to (i) interpret
country: attribute values as default, when it exist,
for INET(6)NUM objects without geofeed: attribute
values; and (ii) give priority to geofeed: attribute
values against country: ones.

Shalom,
--sb.



> This issue has been discussed many times over the last couple of
> decades. Most recently during the discussion over NWI-10 in Oct/Nov
> 2019 and early in 2020 on this mailing list. I think it is long
> overdue for a resolution...
>
> cheers
> denis
> co-chair DB-WG
>
>
> On Thu, 12 Jan 2023 at 15:42, Havard Eidnes <he _at_ uninett _dot_ no> wrote:
> >
> > > [...]
> > >
> >
>
>

-- 

Best Regards !
__
baya.sylvain[AT cmNOG DOT cm]|
Subscribe to Mailing List: 
__
#‎LASAINTEBIBLE‬|#‎Romains15‬:33«Que LE ‪#‎DIEU‬ de ‪#‎Paix‬ soit avec vous
tous! ‪#‎Amen‬!»
‪#‎MaPrière‬ est que tu naisses de nouveau. #Chrétiennement‬
«Comme une biche soupire après des courants d’eau, ainsi mon âme soupire
après TOI, ô DIEU!»(#Psaumes42:2)

denis walker wrote:
> > What we are missing is a meaning for the application of these codes in
> > the context of the RIPE database.
> 
> This is exactly what I said. In the quoted para above I said "the
> country codes have a well defined meaning", which you agree with. Then
> I said "but when entered by users no one knows what it's purpose is.".
> Another way of saying no one knows their meaning in the context of the
> database, which you also agree with.
> 
> > 
> > But even if we started to define a meaning at this late stage, who
> > would choose to use it?


I'm afraid even with detailed documentation available some people won't
read them and make up their own meaning for the attributes. But there's
little that can be done for that. Having an explicit, consistent and
documented meaning is much better than not.

It might have been preferable in NWI-10 to use a different attribute
name (e.g. org-country or legal-country) for ORGANISATIONS, to make it
even more evident that it has a different meaning, but it is still
clear for those interested in getting things right.

I think Denis proposal makes sense.

Regards

-- 
INCIBE-CERT - Spanish National CSIRT
https://www.incibe-cert.es/

PGP keys: https://www.incibe-cert.es/en/what-is-incibe-cert/pgp-public-keys

====================================================================

INCIBE-CERT is the Spanish National CSIRT designated for citizens,
private law entities, other entities not included in the subjective
scope of application of the "Ley 40/2015, de 1 de octubre, de Régimen
Jurídico del Sector Público", as well as digital service providers,
operators of essential services and critical operators under the terms
of the "Real Decreto-ley 12/2018, de 7 de septiembre, de seguridad de
las redes y sistemas de información" that transposes the Directive (EU)
2016/1148 of the European Parliament and of the Council of 6 July 2016
concerning measures for a high common level of security of network and
information systems across the Union.

====================================================================

In compliance with the General Data Protection Regulation of the EU
(Regulation EU 2016/679, of 27 April 2016) we inform you that your
personal and corporate data (as well as those included in attached
documents); and e-mail address, may be included in our records 
for the purpose derived from legal, contractual or pre-contractual
obligations or in order to respond to your queries. You may exercise
your rights of access, correction, cancellation, portability,
limitationof processing and opposition under the terms established by
current legislation and free of charge by sending an e-mail to
dpd _at_ incibe _dot_ es. The Data Controller is S.M.E. Instituto Nacional de
Ciberseguridad de España, M.P., S.A. More information is available
on our website: https://www.incibe.es/proteccion-datos-personales
and https://www.incibe.es/registro-actividad.

====================================================================

26-01-2023 17:46 +0100, Sylvain Baya wrote:
> Le mardi 24 janvier 2023, denis walker via db-wg <db-wg _at_ ripe _dot_ net> a
> écrit :
> > Colleagues
> > 
> > [...]
> > 
> > Most people seem to assume it can be reliably used for geolocation
> > purposes. That would be the most obvious use case for this
> > attribute.
> > Entering an optional value would signify that all the addresses in
> > this block are used within the geographical boundary of the country
> > defined by the code. Where the addresses are used in multiple
> > countries, it may be possible to show this at the assignment object
> > level. Otherwise the optional country: attribute could be omitted
> > and
> > the geolocation information would be determined by the geofeed:
> > attribute.
> > 
> > 
> 
>  
> Hi Denis,
> Thanks for your email, brother!
> 
> 
> imho:
> ...no need to ommit it; if it's possible to (i) interpret 
> country: attribute values as default, when it exist, 
> for INET(6)NUM objects without geofeed: attribute 
> values; and (ii) give priority to geofeed: attribute 
> values against country: ones.
> 
> 
> Shalom,
> --sb.

I understand the proposal as already doing this: geofeed
would have priority over country.

The point is: If the country attribute means 'all the addresses in
this block are used within the geographical boundary
of the country', what else could you do when that's not the case?

You have to modify the value to allow something else than ISO
country codes (e.g. allow an optional trailing asterisk to the country
code to mean not all really fall in that country)

The only case I can think were you could use a ISO 3166-1 with the
above
meaning of "all the addresses in this block are used within the
geographical boundary of the country defined by the code" (loosening it
somewhat), but still being on different countries would be when using
the
exceptional reservation of EU to mean that all those addresses are
within
the borders of the European Union, but not on a single country.

Regards


-- 
INCIBE-CERT - Spanish National CSIRT
https://www.incibe-cert.es/

PGP keys: https://www.incibe-cert.es/en/what-is-incibe-cert/pgp-public-keys

====================================================================

INCIBE-CERT is the Spanish National CSIRT designated for citizens,
private law entities, other entities not included in the subjective
scope of application of the "Ley 40/2015, de 1 de octubre, de Régimen
Jurídico del Sector Público", as well as digital service providers,
operators of essential services and critical operators under the terms
of the "Real Decreto-ley 12/2018, de 7 de septiembre, de seguridad de
las redes y sistemas de información" that transposes the Directive (EU)
2016/1148 of the European Parliament and of the Council of 6 July 2016
concerning measures for a high common level of security of network and
information systems across the Union.

====================================================================

In compliance with the General Data Protection Regulation of the EU
(Regulation EU 2016/679, of 27 April 2016) we inform you that your
personal and corporate data (as well as those included in attached
documents); and e-mail address, may be included in our records 
for the purpose derived from legal, contractual or pre-contractual
obligations or in order to respond to your queries. You may exercise
your rights of access, correction, cancellation, portability,
limitationof processing and opposition under the terms established by
current legislation and free of charge by sending an e-mail to
dpd _at_ incibe _dot_ es. The Data Controller is S.M.E. Instituto Nacional de
Ciberseguridad de España, M.P., S.A. More information is available
on our website: https://www.incibe.es/proteccion-datos-personales
and https://www.incibe.es/registro-actividad.

====================================================================

Dear RIPE DBWG,

...comment below, please.

Le jeudi 26 janvier 2023, Ángel González Berdasco via db-wg <db-wg _at_ ripe _dot_ net>
a écrit :

>
> >
> > >
> > > [...]
> > >
>
>
> I'm afraid even with detailed documentation available some people won't
> read them and make up their own meaning for the attributes. But there's
> little that can be done for that. Having an explicit, consistent and
> documented meaning is much better than not.
>
>
Hi Angel,
Thanks for your email, brother!


>
> It might have been preferable in NWI-10 to use a different attribute
> name (e.g. org-country or legal-country) for ORGANISATIONS, to make it
>
>
...right! it makes sense to differentiate the country:
 attribute where there is some of those managed by
 RIPE NCC...but would prefer to create the new one
and leave the country: attribute as is.

That solve, imho, the usecase shared by the Staff.

Shalom,
--sb.



>
> even more evident that it has a different meaning, but it is still
> clear for those interested in getting things right.
>
> I think Denis proposal makes sense.
>
> Regards
>
> --
> INCIBE-CERT - Spanish National CSIRT
> https://www.incibe-cert.es/
>
> PGP keys: https://www.incibe-cert.es/en/what-is-incibe-cert/pgp-
> public-keys
>
> [...]



-- 

Best Regards !
__
baya.sylvain[AT cmNOG DOT cm]|
Subscribe to Mailing List: 
__
#‎LASAINTEBIBLE‬|#‎Romains15‬:33«Que LE ‪#‎DIEU‬ de ‪#‎Paix‬ soit avec vous
tous! ‪#‎Amen‬!»
‪#‎MaPrière‬ est que tu naisses de nouveau. #Chrétiennement‬
«Comme une biche soupire après des courants d’eau, ainsi mon âme soupire
après TOI, ô DIEU!»(#Psaumes42:2)