Good try but this script does not do it. Firstly, if you start with the allocation object it needs to be -rM in the first query. Then you are only looking for the "org:" attribute. The INET(6)NUM object may have an "abuse-c:" attribute in the object. It may have both in which case the local attribute overrides the "abuse-c:" in the referenced ORGANISATION object. Also to manage this feature it is not just about producing a list of abuse email addresses. It is knowing where these are referenced within a hierarchy and knowing which parts of the hierarchy are covered by which addresses.

I agree that most resources will only have a single abuse contact referenced from their single ORGANISATION object. However, we were pushed hard by the community to allow "abuse-c:" to be added to the INET(6)NUM objects. I assume therefore that this feature has been used. So we already have a mix of abuse contacts referenced from both ORGANISATION and resource objects.

When this was asked for the emphasis was on 'ease of use' to add these contacts. Probably no one gave much thought to how these contacts will be cleaned up when no longer relevant. It's most likely that someone will ask someone to remove it. Knowing human nature it is more likely some will just be forgotten about. If the contact is still there it is still active, but maybe no one is reading that email address any longer.

I am not an operator so I don't know how many end user customers in large networks handle their own abuse reports. Or how many sub allocations handle abuse with their own customers handling abuse. So I don't know how complex this will get and maybe all operators already have good procedures in place to manage all this. That is why I am asking the question...is such a visualisation tool needed, useful or a waste of time? As an analyst, I can only see how complex this 'could' become over time.

Unless we go back to the drawing board and redesign the abuse contact system (again) this is not going to be simplified any time soon.

cheers

denis

co-chair DB-WG

On Thursday, 24 September 2020, 15:32:09 CEST, Lutz Donnerhacke via db-wg <db-wg@ripe.net> wrote:

> > We need to take some action on these old NWIs. Either we move forward
> with them or we cancel them. It is difficult to draw a consensus on 2
> comments. Can you please give us a couple of minutes of your time and
> let us know if this NWI-1 is needed, useful or a waste of time.
>
> I share the view already expressed. If we need a tool, maybe the problem
> is somewhere else.

I support any proposal, that comes to the same result as the ripe whois database tool.
It's not really hard to do correctly.

#! /bin/sh

getripe="whois -h whois.ripe.net --"

$getripe -rL -T inetnum,inet6num "$1" | egrep '^org:' | while read ot ov; do
$getripe -r -T organisation $ov | egrep '^abuse-c:' | while read at av; do
$getripe -r $av | fgrep abuse-mailbox
done
done | tail -1

In order to fix the issue on the database side, it's necessary to prevent any occurrence of "abuse-mailbox" in all objects beside an newly created "abuse-contact" type, which is only allowed to referenced in the "abuse-c".

See here for a corner case: https://lutz.donnerhacke.de/eng/Blog/Antispammers-and-Abuse-C