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