Hi, Going down the path of allowing some form of abuse-email directly on the resources would indeed work for almost everyone and keep the centralised abuse-c system for the ones who do not need a more complicated setup. The IPv4/6 PI holders would not be able to do the "granularity" with their single assignments where several abuse-mail might be needed in network segments from within a single inet(6)num. But that would be one more of the restrictions to add to the lists of differences between PI and PA since assignments, a large PI assignment already cannot be broken into smaller assignment unless converted to Allocated PA. It would still confuse any person inheriting the job of reviewing the Data once all the entries are already made. One would actually have to review the abuse contacts on: 1) Your own main org object and its abuse-c:. 2) Any potential org objects that may contain an abuse-c: referenced on your more specific inet(6)nums 3) Any abuse-mail on any inet(6)nums (parent and more specifics) and aut-nums. 4) Figure out the hierarchy and order of which abuse mail-box is displayed based on the intricate DB rules that were decided in order to know if the displayed email address is the intended one or not for those DB entries. This reminds me of the RIPE DB update notifications system: https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-datab... "notify:" "mnt-nfy:" "upd-to:" "irt-nfy:" "ref-nfy:" Each one of them makes sense individually, but really confuses people in general, notifiers require quite some DB knowledge once you want to know why you received a notification and even more when you want to know why you didn't receive one! Complicated to setup, complicated to debug, but once understood, it does exactly what it is intended for and provides flexibility. All and all it might be the only way to achieve the intended results though. Cheers, David Hilario On Tuesday, November 8, 2016 7:02 PM, Tim Bruijnzeels <tim@ripe.net> wrote: Dear WG,
Problem statement: ==================
It is currently not possible to specify alternative abuse contacts for different resources held by the same organisation in the RIPE Database. This can be problematic.
For example for abuse contact management for big organisations which want multiple abuse contacts for different parts of the organisation. The org is using a lot of PI resources, some of them legacy. Currently they all use the same ORGANISATION object which is inextricably linked to the same abuse-c mailbox. [example taken from Sebastian's first email]
Another example applies to different allocations held by a single LIR. The reference to the LIR's ORGANISATION object is maintained as part of the registry managed by RIPE NCC, and therefore all allocations will have the same abuse-c mailbox. There may however be good operational reasons for having different contacts. [same issue, slightly different example also mentioned by David]
It should be noted however that it is considered useful that in cases where there is no need to have a different abuse-c mailbox, the abuse-c can be defined on an ORGANISATION object that is referenced from an INET(6)NUM object, and have it apply to more specific INET(6)NUM objects through inheritance. This avoids data duplication, and makes it easier to manage this information.
But on the other hand it should also be noted that for a lot of less experienced users of the RIPE database it has proven to be difficult to find the applicable abuse contact for a resource, following this hierarchy. For this reason the abuse contact is now mentioned as a comment in whois output, and is highlighted explicitly on the web query results.
As a somewhat related issue I would also mention the following:
Management of administrative and technical contacts in the RIPE Database is done differently, and the challenges of maintaining that data is somewhat different. While here it is possible, or even mandatory, to have explicit references to admin-c or tech-c contacts for each resource object that may differ from the objects, it is *not* possible here to inherit these contacts from a covering INET(6)NUM or ORGANISATION object. This results in an increase in maintenance burden for this data and therefore makes it more difficult to maintain accurate data.