Fw: [anti-abuse-wg] NWI reviews: NWI-1 staying on top of abuse contact changes
Colleagues 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. cheersdenis co-chair DB-WG ----- Forwarded message ----- From: ripedenis--- via anti-abuse-wg <anti-abuse-wg@ripe.net>To: anti-abuse-wg@ripe.net <anti-abuse-wg@ripe.net>Sent: Tuesday, 22 September 2020, 22:50:52 CESTSubject: [anti-abuse-wg] NWI reviews: NWI-1 staying on top of abuse contact changes Colleagues This is now a very old NWI that never got out of the starting blocks. I am posting this to the AA-WG as I think the discussion is more relevant to this community given the impact of not properly managing this data. https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005234.html Since I raised this point the world has moved on and the situation is now even more complex. The "abuse-c:" attribute can be added to:-the resource holders primary ORGANISATION object-any secondary ORGANISATION object referenced from any point in the address hierarchy-any resource object at any point in the address hierarchy-all, or any combination, of the above These (multiple) "abuse-c:" attributes can reference the same or multiple ROLE objects. These (multiple) ROLE objects can include "abuse-mailbox:" attributes referencing the same or multiple email addresses. Over time, with large hierarchies, we could end up with very complex arrangements with objects, attributes and values that have been overlooked and forgotten about. Even though they may have been forgotten about they are still 'active' and queries will return the most appropriate abuse contact details, even if it is the wrong contact. There is no simple query that will return the details of such a complex structure of abuse contact data in the RIPE Database. So there is no easy way for a resource holder to review or manage these abuse contacts. Although most resources will only ever have one abuse contact for the whole hierarchy, over several years we could end up with the kind of data swamp we had before we introduced the "abuse-c:" attribute for the larger networks. Any user could write their own script to do more specific queries, parse the returned objects and work out the abuse contact data structure for their resource. It would require detailed knowledge of the RIPE Database structure, the abuse contact rules and would involve multiple queries just to get the data, which you then have to visualise. My reason for this NWI-1 was to suggest the RIPE NCC creates a tool or RIPEstat widget that would take in a resource and map out the abuse contact details for the whole hierarchy including that resource. Would this be useful, is it necessary or a waste of time? Please discuss.... cheersdenis co-chair DB-WG
On Thu, Sep 24, 2020 at 12:30:06PM +0000, ripedenis--- via db-wg wrote: Denis, All,
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. Best, Piotr -- Piotr Strzyżewski
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
participants (3)
-
Lutz Donnerhacke
-
Piotr Strzyzewski
-
ripedenis@yahoo.co.uk