Hi Cynthia On Tue, 10 Jan 2023 at 15:13, Cynthia Revström <me@cynthia.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@ripe.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

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-cod... ). 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@uninett.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 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@ripe.net> wrote:

Hi Denis,

...

On 24 Jan 2023, at 17:19, denis walker via db-wg <db-wg@ripe.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 Leo On Thu, 26 Jan 2023 at 13:48, Leo Vegoda <leo@vegoda.org> wrote:

On Thu, 26 Jan 2023 at 03:55, denis walker via db-wg <db-wg@ripe.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, ...comment below, please. Le jeudi 26 janvier 2023, Ángel González Berdasco via db-wg <db-wg@ripe.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]|<https://cmnog.cm/dokuwiki/Structure> Subscribe to Mailing List: <https://lists.cmnog.cm/mailman/listinfo/cmnog/> __ #‎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)

Hi Leo On Mon, 20 Feb 2023 at 15:58, Leo Vegoda <leo@vegoda.org> wrote:

On Thu, 26 Jan 2023 at 07:18, denis walker <ripedenis@gmail.com> wrote:

[...]

...

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.

Setting semantics aside... I don't know whether changing definitions — and adding a missing definition is a de facto change — would improve things or make them worse. What research do we have to support the position that it would be an improvement?

An interesting question. But take a step back and consider the current situation. We have an element of mandatory data with no definition. This data has been entered into millions of INET(6)NUM objects but it has no meaning. No one can reliably use this information for anything. And yet we know many people DO interpret this data and assume a meaning for it without any justification. So where we are now is not a good place. Let me make a quick modified suggestion. We make "country:" an optional attribute in INET(6)NUM objects. The RIPE NCC removes this attribute from ALL existing objects. Consider it as a reset, removing undefined data. We give this attribute a definition related to geolocation. Anyone who chooses to add this attribute with the new definition may do so. Now we have meaningful information that anyone can use in a reliable way. cheers denis co-chair DB-WG

Kind regards,

Leo

Hi Leo On Mon, 20 Feb 2023 at 16:37, Leo Vegoda <leo@vegoda.org> wrote:

On Mon, 20 Feb 2023 at 07:25, denis walker <ripedenis@gmail.com> wrote:

...

On Mon, 20 Feb 2023 at 15:58, Leo Vegoda <leo@vegoda.org> wrote:

[...]

...

...

Setting semantics aside... I don't know whether changing definitions — and adding a missing definition is a de facto change — would improve things or make them worse. What research do we have to support the position that it would be an improvement?

An interesting question. But take a step back and consider the current situation. We have an element of mandatory data with no definition. This data has been entered into millions of INET(6)NUM objects but it has no meaning. No one can reliably use this information for anything. And yet we know many people DO interpret this data and assume a meaning for it without any justification. So where we are now is not a good place.

Let me make a quick modified suggestion. We make "country:" an optional attribute in INET(6)NUM objects. The RIPE NCC removes this attribute from ALL existing objects. Consider it as a reset, removing undefined data. We give this attribute a definition related to geolocation. Anyone who chooses to add this attribute with the new definition may do so. Now we have meaningful information that anyone can use in a reliable way.

The RIPE NCC has been publishing country-related data and refining draft text about its unreliable nature for more than 20 years. We know that users infer what they want to infer about what country-related data means. Can we make predictions about changes in user behaviour with any degree of accuracy? If not, are there ways we can influence user behaviour?

My concern is that lots of users will not be aware of the change, or not have the resources to adapt to it in a timely fashion. So, if any change is made, it ought to be accompanied by a change management plan. The alternative is guessing and hoping and I personally believe that is not the responsible path.

I see your point. We have many examples over the years of changes that have been made and some people haven't responded to those changes years later. From the Early Registration Transfer (ERX) project we did 20 years ago there are still INETNUM objects with the combined data from ARIN and RIPE and a comment asking resource holders to update the object. We have three options here. 1/ We never change anything because some people don't take notice. 2/ We do a 'best effort' campaign to let people know. This could involve an occasional/regular newsletter sent to resource holders with details of important changes to tools managed by the RIPE NCC. This could also be published on the website for consumers of the database information. Include a comment in query output referring to this changes page. Users of these tools have some personal responsibility to keep themselves informed of important changes. 3/ In this case we can simply deprecate the meaningless, undefined, useless and misleading "country:" attribute from INET(6)NUM objects. The fact that the RIPE NCC has spent 20 years telling people not to rely on this piece of information for anything, is a good clue that change is needed. If anyone thinks it could be useful for geolocation purposes to have a 'geo' country then we could consider adding a new optional attribute "geo-country:" later. cheers denis co-chair DB-WG

Kind regards,

Leo

Dear RIPE DB-WG, Hoping that this email finds you in good health! Please see my comments below, inline... Thanks. Le lundi 20 février 2023, Leo Vegoda via db-wg <db-wg@ripe.net> a écrit :

...

[...]

With clear explanations sent to all resource holders and/or maintainers of the resource objects, I think we could get this message out there.

Setting semantics aside... I don't know whether changing definitions — and adding a missing definition is a de facto change — would improve things or make them worse.

Hi Leo, Thanks for your email, brother. ...imho! it should be obvious that no one know :-/ However, i think we could first separate two goals: G1. Documentation improvement G2. Behaviour improvement

What research do we have to support the position that it would be an improvement?

...while proceeding, as suggested above, i think we would not, absolutely, need a research in order to choose a common/consensual direction. For G1. we could simply answer the following questions: target="DB documentation" Q1.1 Do we need to improve $target? Q1.2 Do we want to do it? Q1.3 Can we obviously expect to succeed? ...imho! Yes! (Q1.1) | Maybe! (Q1.2) | Yes! (Q.1.3) For G2. we could simply answer the following questions: target="user/admin behaviour" Q2.1=Q1.1 Q2.2=Q1.2 Q2.3=Q1.3 ...imho! Yes! (Q2.1) | Maybe! (Q2.2) | No! (Q2.3) If you try to follow my reasoning; then you might conclude that "influencing the average behaviour" is a task that the outcomes/results are too difficult to predict. In general, the result would stay as bad as it's actually (20 years after)... ...but, imho, i couldn't recommend to a book writer to stop writing useful books; simply because there is clear evidences that "people do not actually like to read, as they prefer to watch videos". Time to read is different than time to write...a book can wait its readers & meet them after a long time. :-) Shalom, --sb.

Kind regards,

Leo [...]

-- Best Regards ! __ baya.sylvain[AT cmNOG DOT cm]|<https://cmnog.cm/dokuwiki/Structure> Subscribe to Mailing List: <https://lists.cmnog.cm/mailman/listinfo/cmnog/> __ #‎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)

HI Cynthia On Thu, 2 Mar 2023 at 17:43, Cynthia Revström via db-wg <db-wg@ripe.net> wrote:

Hi db-wg,

I just want to start out by saying that I support efforts to try to better understand and document this. What I don't (currently) support is changing DB policy (policy in the form of RIPE documents or policy enforced by the RIPE DB software), especially before we really know much about the impact.

I think it is rather obvious that some forms of country codes in the RIPE DB are very likely to have an impact on GeoIP data in some cases at least.

Yes, some of the country codes (cc) in the database are likely to have an impact on GeoIP. Some people have entered cc to reflect GeoIP, others have not. But we don't know which is which. So using any cc from the database is as likely to be wrong as right.

Additionally, as I think we all are painfully aware of, a lot of online services are restricted or change their behaviour based on GeoIP data. If I can use the country attribute in an inet(6)num or organisation object to potentially correct some invalid GeoIP data then I am probably going to want to use that. (Assuming I have no better options)

This approach simply won't work. (btw some of the approaches I have suggested in this thread won't work either, but we are getting a clearer picture as we discuss it.) You cannot correct invalid GeoIP with more invalid data that was never intended to be used for GeoIP. You are just moving a block of IP addresses from one wrong location to a different wrong location.

I have actually been casually experimenting a bit with this for almost 3 years now and I can say for sure that there are major online services that utilize the country attribute in inetnum objects for GeoIP data. (I don't know if they do it directly or if they get it from a third party, but that is not really relevant.) It's a bit of a tangent, but you can see one of the amusing effects of this in a post[1] on the r/Steam subreddit from when someone on there discovered that my network was supposedly the largest ISP in Antarctica according to Steam's statistics.

This example is exactly why maintaining uncertain data for unknown reasons in the database is both wrong and misleading. The fact that you can say for sure that 'major online services' use data in a way that the RIPE NCC has spent 20+ years telling people not to do, is why we do need to take some action.

I agree that this is by no means an ideal situation we are in. However, we also shouldn't make life more difficult for the people working at ISPs who have IP space that is being misidentified by GeoIP databases. While large ISPs might be able to go to the GeoIP databases or content providers and tell them to fix their data, this doesn't really work for small ISPs (as far as I know). In the long term we will hopefully not have any need for these country attributes and everything that relies on GeoIP will just use geofeeds but currently that is not the case.

I don't think that it is a good idea to focus on country codes in the database at the moment. I think that we instead need to look at GeoIP and the sources that are being used as a whole. It is a big and messy thing and it will not just be a quick NWI but I think it is what we have to do if we want to deal with this.

I agree we need to look in more detail if Geolocation using the RIPE Database is best served with (and maybe only with) the new "geofeed:" attribute or if a "geo-country:" attribute may be useful as well. But I think the best and only solution to the misuse and misunderstanding of the "country:" attribute in INET(6)NUM objects is to deprecate it. As Leo pointed out, if we try to define it now after 20+ years the message will not reach many users. To continue allowing it's (confused) existence at a time when geo fencing is becoming a politically and socially sensitive issue, is simply making the situation worse than it has ever been. Maybe by deprecating it we will achieve what you suggested above by focusing people's minds on what is needed in the RIPE Database for geolocation rather than spending time trying to fix the unfixable. cheers denis co-chair DB-WG

Finally I just want to say that ideally (in my opinion) we would ideally not need to care about GeoIP at all but sadly I don't think that is going away anytime soon, so we have to be pragmatic about it.

[1]: https://www.reddit.com/r/Steam/comments/gilapa/pretty_good_transfer_rate_for...

P.S. This email is not really a reply to any specific email in this thread but rather just a summary of my current take on this. I am also sorry for the rather long and rambly email, but I felt like I needed to summarize my thoughts on this so that people can correct me if I am wrong about anything or if something that I think is obvious is in fact not obvious.

-Cynthia

On Thu, Mar 2, 2023 at 12:53 PM Sylvain Baya via db-wg <db-wg@ripe.net> wrote:

...

Dear RIPE DB-WG,

Hoping that this email finds you in good health! Please see my comments below, inline...

Thanks.

Le lundi 20 février 2023, Leo Vegoda via db-wg <db-wg@ripe.net> a écrit :

...

...

[...]

With clear explanations sent to all resource holders and/or maintainers of the resource objects, I think we could get this message out there.

Setting semantics aside... I don't know whether changing definitions — and adding a missing definition is a de facto change — would improve things or make them worse.

Hi Leo,

Thanks for your email, brother.

...imho! it should be obvious that no one know :-/

However, i think we could first separate two goals:

G1. Documentation improvement

G2. Behaviour improvement

...

What research do we have to support the position that it would be an improvement?

...while proceeding, as suggested above, i think we would not, absolutely, need a research in order to choose a common/consensual direction.

For G1. we could simply answer the following questions:

target="DB documentation"

Q1.1 Do we need to improve $target?

Q1.2 Do we want to do it?

Q1.3 Can we obviously expect to succeed?

...imho! Yes! (Q1.1) | Maybe! (Q1.2) | Yes! (Q.1.3)

For G2. we could simply answer the following questions:

target="user/admin behaviour"

Q2.1=Q1.1

Q2.2=Q1.2

Q2.3=Q1.3

...imho! Yes! (Q2.1) | Maybe! (Q2.2) | No! (Q2.3)

If you try to follow my reasoning; then you might conclude that "influencing the average behaviour" is a task that the outcomes/results are too difficult to predict.

In general, the result would stay as bad as it's actually (20 years after)...

...but, imho, i couldn't recommend to a book writer to stop writing useful books; simply because there is clear evidences that "people do not actually like to read, as they prefer to watch videos".

Time to read is different than time to write...a book can wait its readers & meet them after a long time.

:-)

Shalom, --sb.

...

Kind regards,

Leo [...]

--

Best Regards ! __ baya.sylvain[AT cmNOG DOT cm]|<https://cmnog.cm/dokuwiki/Structure> Subscribe to Mailing List: <https://lists.cmnog.cm/mailman/listinfo/cmnog/> __ #‎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)

--

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

--

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, I strongly support what George has written. On Tue, 7 Mar 2023 at 14:29, George Michaelson via db-wg <db-wg@ripe.net> wrote: [...]

I don't necessarily disagree with you about the risks here, but I suggest that the decision to deprecate or alter behavior with this field is not something which a single RIR should undertake without a wider conversation.

In particular, I support this paragraph. We need to reach out to people who use this data and get them to tell us what they need or want it to mean. Until we hear from them we are just guessing. Kind regards, Leo

Hi Denis, On Tue, 7 Mar 2023 at 16:20, denis walker <ripedenis@gmail.com> wrote:

...

On Tue, 7 Mar 2023 at 14:29, George Michaelson via db-wg <db-wg@ripe.net> wrote:

[...]

...

I don't necessarily disagree with you about the risks here, but I suggest that the decision to deprecate or alter behavior with this field is not something which a single RIR should undertake without a wider conversation.

In particular, I support this paragraph.

We need to reach out to people who use this data and get them to tell us what they need or want it to mean. Until we hear from them we are just guessing.

"what they need or want it to mean" You said it yourself Leo, if we try to change the perceived meaning of this data after 20+ years, many people will never get the message. We cannot 'fix' this particular piece of undefined data...ever!! We can debate it as long as we want but it changes nothing. As Cynthia said, she knows for sure "there are major online services that utilize the country attribute in inetnum objects for GeoIP data". This is despite the RIPE NCC telling people for over 20 years they cannot reliably do this. Every time anyone influences the wider geoIP data set with any data from this attribute, they are potentially corrupting that data set. There is nothing we can do to change that fact as long as this indeterminate data exists and is used against official advice.

"We need to reach out to people who use this data" We have been discussing this issue on this mailing list for months. We have comments from a handful of people. That is out of tens of thousands of resource holders, hundreds of thousands, maybe millions, of consumers of this data. For the majority of people these discussions are not important. No outreach is likely to create any mass influx of opinion. That is an unfortunate reality. An informed, educated guess is often the best we can hope for.

This mailing list. You said it. Lots of people from different types of organisations use data that helps them without deep-diving into the communities that produce it. Half the problem is that the RIPE community has spent 20 years writing documentation that is barely glanced at by developers who decide that this data means what they want it to mean. But do people from the RIPE community engage with the people who run GeoIP databases? How can we complain that people misunderstand us if we don't actively engage with them about what they need the data to mean? Kind regards, Leo

Hi Denis, On Tue, 7 Mar 2023 at 18:52, denis walker <ripedenis@gmail.com> wrote:

From my perspective as an analyst it's getting interesting now... Yes we can consider it as a complex problem needing a complex solution...but are either really complex? Maybe it is the environment that is complex and not this specific problem or solution.

Yes, the environment is more complex now than it was 20 years ago. There has been considerable economic integration across Europe and the world. At the same time, the Internet has transformed from an interesting research project to an essential utility. Utilities are essential infrastructure. While removing or redefining data and seeing what break might seem like fun, it has consequences. I'd love to see a formal problem statement that calls out the known users of the data. They are legitimate stakeholders. I'd also like to see a plan for contacting those users and asking them what they need and engaging them in the discussion. But if there are ways to achieve a useful outcome without speaking with the users of the data I'd love to hear them. Kind regards, Leo

From what you say it sounds like you have to provide lots of information to geoIP aggregators to convince them their assertion is wrong. Do you think this may be because they don't trust the country attribute information currently available in INET(6)NUM objects? Maybe

Hi Eric I appreciate your comment. It is good to know the views of new subscribers. Let me throw a couple of points back to you and I would be interested to know what you think. You suggested that geofeed may be the answer. But geofeed is just a more precise location than say geo-country. It also allows for specifying locations where a block of addresses are used in more than one country. Maybe for many ISPs publishing the country level information may be enough detail. they know the RIPE NCC has spent the last 20 years telling people they cannot rely on that attribute for IP location, so geoIP aggregators ignore it. Suppose for now we just leave the "country:" attribute alone. We don't delete it, don't change it and don't try to redefine it. People can continue to put whatever they want in there and other people can believe (or not) what they want about what they see. The RIPE NCC will continue to tell anyone who asks, that they cannot rely on that data for any purpose. A completely hands off position, maintaining the status quo. Now suppose we create a new optional attribute, say "geo-country:". It can be used by resource holders, if you want to, to specify the location where you say this whole block of addresses are used. We can tell the geoIP aggregators that this geo-country data is a reliable statement from the resource holder about where these addresses are being used. Do you think that would help you as an ISP? We can invent all sorts of complex solutions like geofeed that will address all situations. Then spend another year debating with the RIPE NCC legal team about how to use it. Perhaps we can also do something very simple like geo-country that may quickly improve the situation for a large number of resource holders. cheers denis co-chair DB-WG On Fri, 10 Mar 2023 at 08:57, Delmas, Eric <edelmas@cogentco.com> wrote:

Hi Denis,

I am an IP Engineer at Cogent (ISP). I subscribed to this mailing list few months ago (sorry for being silent).

One comment on your suggestion to delete the "country:" attribute in resource objects.

When in the need to contact the GeoIP aggregators (MaxMind and others.) asking correction of some wrong data, I have to show some concrete information such as traceroute + registration re-assignment record. Geodeed if/when widely adopted may be the solution. In the meantime the "country:" attribute in INET(6)NUM object is helpful.

Best regards Éric

-----Original Message----- From: db-wg <db-wg-bounces@ripe.net> On Behalf Of denis walker via db-wg Sent: Wednesday, March 8, 2023 3:52 AM To: Leo Vegoda <leo@vegoda.org> Cc: RIPE Database WG <db-wg@ripe.net>; Havard Eidnes <he@uninett.no>; George Michaelson <ggm@algebras.org> Subject: Re: [db-wg] country codes in the RIPE Database (was: ORGANISATION country code)

CAUTION: This email originated from an external sender! Do not click the links, open attachments or reply, unless you recognize/trust the sender's email address and know the content is safe!

Hi Leo

From my perspective as an analyst it's getting interesting now... Yes we can consider it as a complex problem needing a complex solution...but are either really complex? Maybe it is the environment that is complex and not this specific problem or solution.

On Wed, 8 Mar 2023 at 01:29, Leo Vegoda <leo@vegoda.org> wrote:

...

This mailing list. You said it.

Lots of people from different types of organisations use data that helps them without deep-diving into the communities that produce it.

The community that produces this data doesn't dive very deep either.

...

Half the problem is that the RIPE community has spent 20 years writing documentation that is barely glanced at by developers who decide that this data means what they want it to mean.

And half of those developers who barely glance at this documentation are the ones whose developments create this data.

...

But do people from the RIPE community engage with the people who run GeoIP databases?

Only a handful of the RIPE community engages with this mailing list, so I doubt many of them engage with GeoIP people about the RIPE Database.

...

How can we complain that people misunderstand us if we don't actively engage with them about what they need the data to mean?

The difficulty here is defining 'people' and 'us' and the overlap and how and where active engagement could take place and where to publicise any outcome of such engagement that would make the outcome effective.

The problem is simple: -"country:" in resource objects has never been defined -that fact is well documented in places no one reads -it is discussed in places creators and users of this data don't follow -it is a mandatory attribute so all resource objects must have this data -no one knows what the resource holders mean by it -no one knows what consumers perceive it to mean -by using it to influence geolocation we probably pollute the wider GeoIP data set -we have spent 20+ years telling people they can't use it for GeoIP but we know they still do -if we give it a definition now, many creators and consumers will never get the message

So the solution is also simple -no registry data depends on it -no one can rely on it -it has no value in it's indeterminate state ---so delete it

THEN we can have a discussion about what 'people' want 'us' to provide. Maybe a new, optional "geo-country:" attribute with a clear definition from the start and guidelines on usage, with a name that implies what it means even if you don't read anything about it. By deleting the current useless data we might get a few more people to join the discussion on how to move forward.

But there is another interesting aspect to this. We had a lively discussion last year on "geofeed:". Lots of people from the community were involved in that discussion. Where are they now? This discussion has turned into a more general debate about the use of the RIPE Database for GeoIP purposes. Why were so many people so interested in "geofeed:" but avoid a more general geolocation discussion? Why are so few people publicly arguing for or against this use of the RIPE Database and how to do it? (...and one speaks as I am writing this email.)

cheers denis co-chair DB-WG

...

Kind regards,

Leo

--

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 Laurent On Thu, 23 Mar 2023 at 12:45, Laurent Pellegrino <laurent.pellegrino@ipregistry.co> wrote:

Hi Denis, all,

That's just my thought, but who can do the more can do the less. If an ISP prefers to publish country-level information only, that's possible with a geofeed.

Personally, from what I see at Ipregistry, geofeed has only recently started to receive attention from companies, despite its existence for years. Introducing a geo-country attribute would add even more confusion and undermine the efforts put into geofeed. This would result in some people preferring to use the geo-country attribute, others using the geofeed attribute, still others using the geoloc attribute (and even some using the country attribute at inetnum level despite RIPE NCC has spent the last 20 years telling people they cannot rely on that attribute for IP location).

And the worst part is when organizations use two or three of the aforementioned attributes at the same time with conflicting values. Yes, this really happens, often because people are unaware of the different attributes available for each RIR or because they update one but not the others. In such cases, it becomes unclear which attribute should be used, and the multitude of attributes available for geolocation purposes creates confusion.

This is a very good point.

Again, this is a personal view, but I believe there should be a single attribute officially supported for geolocation purposes. Other attributes should be deprecated and removed after a transition period. As for which attribute to promote, that is another question. However, geofeed looks like a good candidate for multiple reasons, such as its flexibility, various levels of granularity, privacy awareness (compared to the geoloc attribute), and standardized format. This vision could one day allow all RIRs to converge on the same attribute, the purpose of which is clearly understood by all, leading to better and more accurate IP geolocation-related information for all.

I totally agree with you. My suggestion for a geo-country was really just a conversation starter to try to get more people to say what they really want. I think you summed it up well in this paragraph. If more people can get behind this and EXPRESS their support we can move forward and make some progress. We need to finalise the legal issues over geofeed and get community agreement NOW to deprecate the redundant attributes like "geoloc:" and "country:", after the transition period. SO if anyone supports the goal of a single, officially supported attribute for geolocation purposes, later deprecating all the others...please, please, please let us know. Then we can wrap this issue up with a ToDo list and some time lines. cheers denis co-chair DB-WG

Kind regards, Laurent Pellegrino

On Thu, Mar 23, 2023 at 11:57 AM denis walker via db-wg <db-wg@ripe.net> wrote:

...

Hi Eric

I appreciate your comment. It is good to know the views of new subscribers. Let me throw a couple of points back to you and I would be interested to know what you think.

You suggested that geofeed may be the answer. But geofeed is just a more precise location than say geo-country. It also allows for specifying locations where a block of addresses are used in more than one country. Maybe for many ISPs publishing the country level information may be enough detail.

From what you say it sounds like you have to provide lots of information to geoIP aggregators to convince them their assertion is wrong. Do you think this may be because they don't trust the country attribute information currently available in INET(6)NUM objects? Maybe they know the RIPE NCC has spent the last 20 years telling people they cannot rely on that attribute for IP location, so geoIP aggregators ignore it.

Suppose for now we just leave the "country:" attribute alone. We don't delete it, don't change it and don't try to redefine it. People can continue to put whatever they want in there and other people can believe (or not) what they want about what they see. The RIPE NCC will continue to tell anyone who asks, that they cannot rely on that data for any purpose. A completely hands off position, maintaining the status quo.

Now suppose we create a new optional attribute, say "geo-country:". It can be used by resource holders, if you want to, to specify the location where you say this whole block of addresses are used. We can tell the geoIP aggregators that this geo-country data is a reliable statement from the resource holder about where these addresses are being used. Do you think that would help you as an ISP?

We can invent all sorts of complex solutions like geofeed that will address all situations. Then spend another year debating with the RIPE NCC legal team about how to use it. Perhaps we can also do something very simple like geo-country that may quickly improve the situation for a large number of resource holders.

cheers denis co-chair DB-WG

On Fri, 10 Mar 2023 at 08:57, Delmas, Eric <edelmas@cogentco.com> wrote:

...

Hi Denis,

I am an IP Engineer at Cogent (ISP). I subscribed to this mailing list few months ago (sorry for being silent).

One comment on your suggestion to delete the "country:" attribute in resource objects.

When in the need to contact the GeoIP aggregators (MaxMind and others.) asking correction of some wrong data, I have to show some concrete information such as traceroute + registration re-assignment record. Geodeed if/when widely adopted may be the solution. In the meantime the "country:" attribute in INET(6)NUM object is helpful.

Best regards Éric

-----Original Message----- From: db-wg <db-wg-bounces@ripe.net> On Behalf Of denis walker via db-wg Sent: Wednesday, March 8, 2023 3:52 AM To: Leo Vegoda <leo@vegoda.org> Cc: RIPE Database WG <db-wg@ripe.net>; Havard Eidnes <he@uninett.no>; George Michaelson <ggm@algebras.org> Subject: Re: [db-wg] country codes in the RIPE Database (was: ORGANISATION country code)

CAUTION: This email originated from an external sender! Do not click the links, open attachments or reply, unless you recognize/trust the sender's email address and know the content is safe!

Hi Leo

From my perspective as an analyst it's getting interesting now... Yes we can consider it as a complex problem needing a complex solution...but are either really complex? Maybe it is the environment that is complex and not this specific problem or solution.

On Wed, 8 Mar 2023 at 01:29, Leo Vegoda <leo@vegoda.org> wrote:

...

This mailing list. You said it.

Lots of people from different types of organisations use data that helps them without deep-diving into the communities that produce it.

The community that produces this data doesn't dive very deep either.

...

Half the problem is that the RIPE community has spent 20 years writing documentation that is barely glanced at by developers who decide that this data means what they want it to mean.

And half of those developers who barely glance at this documentation are the ones whose developments create this data.

...

But do people from the RIPE community engage with the people who run GeoIP databases?

Only a handful of the RIPE community engages with this mailing list, so I doubt many of them engage with GeoIP people about the RIPE Database.

...

How can we complain that people misunderstand us if we don't actively engage with them about what they need the data to mean?

The difficulty here is defining 'people' and 'us' and the overlap and how and where active engagement could take place and where to publicise any outcome of such engagement that would make the outcome effective.

The problem is simple: -"country:" in resource objects has never been defined -that fact is well documented in places no one reads -it is discussed in places creators and users of this data don't follow -it is a mandatory attribute so all resource objects must have this data -no one knows what the resource holders mean by it -no one knows what consumers perceive it to mean -by using it to influence geolocation we probably pollute the wider GeoIP data set -we have spent 20+ years telling people they can't use it for GeoIP but we know they still do -if we give it a definition now, many creators and consumers will never get the message

So the solution is also simple -no registry data depends on it -no one can rely on it -it has no value in it's indeterminate state ---so delete it

THEN we can have a discussion about what 'people' want 'us' to provide. Maybe a new, optional "geo-country:" attribute with a clear definition from the start and guidelines on usage, with a name that implies what it means even if you don't read anything about it. By deleting the current useless data we might get a few more people to join the discussion on how to move forward.

But there is another interesting aspect to this. We had a lively discussion last year on "geofeed:". Lots of people from the community were involved in that discussion. Where are they now? This discussion has turned into a more general debate about the use of the RIPE Database for GeoIP purposes. Why were so many people so interested in "geofeed:" but avoid a more general geolocation discussion? Why are so few people publicly arguing for or against this use of the RIPE Database and how to do it? (...and one speaks as I am writing this email.)

cheers denis co-chair DB-WG

...

Kind regards,

Leo

--

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

--

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 George Thanks for your comments. Of course global context is important in these situations and I appreciate you raising this issue. It says in the file: https://ftp.ripe.net/pub/stats/ripencc/RIR-Statistics-Exchange-Format.txt 3.3 Record format: ... 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 in which the resource holder is legally based. However, it is not specified whether this is the country where the IP addresses are used. This value can therefore not be reliably used to map IP addresses to countries. This used to be taken from the "country:" attribute in the resource objects. However, the RIPE community agreed to a change to this which is explained in this article: https://labs.ripe.net/author/stefania_fokaeos/our-plan-to-update-country-cod... So the values in the RIPE extended delegated stats file are no longer linked to the "country:" attribute in resource objects. Now the change referred to in this article has been fully implemented, I don't think deprecating the "country:" attribute will have any impact at all on the stats file. cheers denis co-chair DB-WG On Tue, 7 Mar 2023 at 23:29, George Michaelson <ggm@algebras.org> wrote:

I suggest that this is not just a localized decision of the db-wg, but has global implications. You are discussing a field whose value is interpreted both directly from WHOIS and RDAP, and less directly from delegated files in the registry system across all the RIR. Your consumers are my consumers, and ARINs and LACNIC and AfriNICs. It is a global market of consumption.

I don't necessarily disagree with you about the risks here, but I suggest that the decision to deprecate or alter behavior with this field is not something which a single RIR should undertake without a wider conversation.

Obviously my statement has no "normative force". We're not discussing address policy, we're not discussing "global address policy" and in any case, RIR secretariat staff aren't "in charge" here, its something discussed inside your own process.

I just think that there's a global context which is very important: Cohesion of this data across the "ecology" is a really big deliverable.

cheers

-George

Hi Randy On Wed, 8 Mar 2023 at 03:11, Randy Bush <randy@psg.com> wrote:

...

I suggest that this is not just a localized decision of the db-wg, but has global implications.

+1, and this aside from the idea having other fatal flaws, as discussed here before.

Can you please be a little more specific? What is the global implication of deleting undefined and misleading data from the RIPE Database that no other data in the RIPE or other registries depends on? Can you summarise the fatal flows that follow from deleting this data? Perhaps the circumstances are different now to when these 'fatal flows' were discussed before. cheers denis co-chair DB-WG

randy

26-01-2023 17:46 +0100, Sylvain Baya wrote:

Le mardi 24 janvier 2023, denis walker via db-wg <db-wg@ripe.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@incibe.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. ====================================================================

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@gmail.com> wrote:

Hi Cynthia

On Tue, 10 Jan 2023 at 15:13, Cynthia Revström <me@cynthia.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@ripe.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