[db-wg] [ncc-announce] [news] RIPE Database: Cleaning-up Organisation Names in "descr:"

Dear Peter, wg,

On 25 Apr 2016, at 14:35, Peter Hessler <phessler at theapt.org> wrote:
> 
> On 2016 Apr 25 (Mon) at 14:03:32 +0200 (+0200), Tim Bruijnzeels wrote:
> :Dear Akil Evlat,
> :
> :When the change was discussed in this working group, it was concluded
> :that this change should not affect any routing operations. And indeed,
> :after we modified just over 93 thousand resource objects we received not
> :a single report about operational issues. 
> 
> As one who did report issues, I must disagree.
> 
> We can debate what "operational issues" mean, but my objects having a
> new "name" on various 3rd party services _is_ an issue that is a problem.
> 
> We set those entries with care.  Hell, (let's bring up something older)
> we even used changed: correctly!  (side note: changed: could have ALSO
> been used for us to understand why this changed happened)
> 
> A number of people are very concerned that their objects will be
> modified without concern that these values have been chosen on purpose.
> 
> What is the criteria for selecting which objects will be changed?  Not
> set to the previous default?  Multiple lines?

I was referring to issues related to routing, as I hoped would be clear from the continuation of the paragraph.

Let me get back to the other point you raise here at the end of this email.

> :We rolled this change back
> :because of issues with whitespace and a concern raised that a warning
> :should have gone out to ncc-announce, but it's important to note that as
> :far as we can tell there were indeed no operational issues affecting
> :*routing*.
> :
> 
> Is *routing* the only thing that the database cares about?  If that's
> true, there is a lot of things I can stop doing in the database, and all
> sorts of objects that can be deleted.
> 
> Is that really what you are saying?

No, all I am saying is that it's important to point out that this working group thought about any potential impact on routing, came to conclusion that routing should not be affected, and this is confirmed by the change that was rolled back.

Other than the issues reported by you regarding whitespace and contact information in third party tools, we received no tickets.

> :Where this would affect operations is w.r.t. to look ups. I believe your allocation objects currently only have one "descr:" entry with your organisation name. So in your case the clean-up would mean that your allocation objects would have no remaining "descr:" attribute, but do keep a reference to your organisation through the "org:". 
> :
> :So people doing ad-hoc lookups, or tools that show the organisation associated with a resource should now follow the reference to the organisation object instead.
> :
> :This is good advice in general because the "descr:" attribute may be blank, as it's now optional (even without the clean-up), or it may have something that looks like an organisation name - but it's not kept in sync with the organisation name that the RIPE NCC verifies, and in case of more specific int(6)num objects under allocations or legacy objects it can contain any text entered by the holder of the object. So in short: it has never been possible to trust that "descr:" has the organisation name for all resource objects in the database, even more so now that users can modify it for allocations and assignments done through RIPE NCC.

It was definitely not the case that routing was the only concern. Data quality and clarity on where to find information were precisely why a clean-up was intended.

The criteria for clean-up were discussed in this working group. Those "descr:" attributes that have been enforced by RIPE NCC were to be cleaned-up, so that it would be clear that a) this is NOT the place to look for the authoritative organisation name, and b) this is no longer enforced by RIPE NCC (as required by the community).

Third party tools that assume that the "descr:" attribute refers to the organisation name will find that this assumption does not hold up in general. Even without a clean-up this is something that may become modified to something else completed, or outdated w.r.t. the organisation name verified by RIPE NCC. Furthermore the assumption has never been true for assignments done by LIRs and resources held by legacy holders. So, regardless of whether the clean-up is actually done, third party tools *should* look for an associated organisation object (possibly higher in the hierarchy*). For example, Alex recently had contact with Hurricane Electric and they are now changing their implementation along these lines.

As I mentioned in a previous email, these concerns were discussed in this working group. And at the time there was consensus to go-ahead with a clean up. That being said I also made it clear in that email that in the light of recent discussions we are looking at the working group to decide on how to move forward, and we will only run the clean-up again after a consensus is called again by the co-chairs.


*: BTW. Regardless of whether a clean-up is done, we can implement something to show the actual organisation name when a resource is looked up - similar to how we now show abuse contact information with resources.



Kind regards,
Tim Bruijnzeels







> :
> :
> :Kind regards,
> :
> :Tim Bruijnzeels
> :
> 
> -- 
> Avoid Quiet and Placid persons unless you are in Need of Sleep.
> 		-- National Lampoon, "Deteriorata"