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 <[email protected]> wrote: > Hi Cynthia > > On Tue, 10 Jan 2023 at 15:13, Cynthia Revström <[email protected]> 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 <[email protected]> > 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 >
-- 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
