On Tue, Mar 8, 2016 at 9:14 AM, Richard Hartmann <richih.mailinglist@gmail.com> wrote:
On Mon, Mar 7, 2016 at 1:33 PM, Gert Doering <gert@space.net> wrote:
I would like abuse-c: much more if it were changed in two ways:
- permit abuse-c: in inet(6)num: objects - permit abuse-c: to point to a normal person: object, not only role:
This boils down to what I thought would have been the better implementation all along.
Strong +1.
If I can chip in with a -1 here, and maybe shed some light on this... It's not enough to state "let's add abuse-c here and here and here". Also think about how one is supposed to return the abuse contact afterwards. It should be algorithmically feasible to fetch the abuse contact from the RIPE DB. Should inet(6)num take precedence? Should the role object? or the organisation? or maybe a route? Or a combination of these, with their parents involved? And one more thing. As far as data quality goes, users are not known to keep their data up to date (sorry for the few exceptions - you're not the rule). Then you will have to start to figure out which abuse-c is outdated and which isn't; which one is still relevant and which is not. That's NOT a database, that's a job for google. If there is a data you want to store and retrieve, there should be one and exactly one way to do that. You make more, there will be confusion. I agree the current way abuse-c is done is complicated. We knew that when we implemented it. But it IS a single place to store that data, and that is very important. Because changing data format is easy. Adding a new API to return abuse contact is easy. What is extremely hard is to gather data that is simply not present in the database. The real problem with the RIPE DB is that it is vastly outdated. A lot of maintenance has been neglected over the years, because it's costly for everyone. Abuse-c is a breaking point - having to choose between data quality and ease of use. Cheers, Agoston