[db-wg] ORGANISATION country code

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

> Hi Cynthia
>
> On Tue, 10 Jan 2023 at 15:13, Cynthia Revström <me at 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 at 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://mailman.ripe.net/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/db-wg/attachments/20230112/58e781f4/attachment.html>