Hi Sebastian If this is going to be an NWI the process should be to identify a problem statement and then move onto possible solutions. But as we have gone so far down the road with many ideas already on the table let me address a few of the issues. On 04/11/2016 13:38, Sebastian Wiesinger wrote:
Hi David,
thank you for the in-depth answer!
* fransossen@yahoo.com <fransossen@yahoo.com> [2016-11-03 12:12]:
A) Being able to indicate the AS and prefixes covered by a specific abuse email directly in the role object used as abuse-c: .
Annoying to set up, not very intuitive at first, but less annoying than having to create new org objects per network segments requiring different role objects as abuse-c: each time. Covers the need of LIRs with PA, AS number and PI resource holders in terms of potential granularity.
I personally would also find this annoying and quite a bit unintuitive. ;) I *DO* like the granularity but I don't think it outweighs having all of that pushed to a single object instead of having multiple abuse-c's that are probably managed by different maintainers (giving customers the opportunity to manage their own abuse-c object). Also I would image this would necessitate quite a bit of special parsing in the database software.
Firstly don't worry about how the database parses data. This is trivial compared to some of the parsing it already does. One of the key objectives of this "abuse-c:" design was specifically to bring all abuse contact details into a centrally controlled place. I agree it has caused some problems. But having multiple "abuse-c:" attributes in the ORGANISATION object still keeps it central and the referenced ROLE objects that hold the "abuse-mailbox:" attributes can still be managed by the different customers allowing them to control the actual email address in use.
B) Allow abuse handler to be added directly on the Inet(6)num/Aut-num entries in the DB.
This is what I would prefer right now. It is low cost to implement, it is easy to parse (use abuse-c: if available, else go to the organisation abuse-c).
I am not quite having any other ideas on how to proceed that would fit within the current RIPE DB rules...route objects pop to mind, but would also have their quirks.
I would prefer to have option B) right now. *If* we need more granularity it would probably need to be a full fledged (meaning: more complicated) solution. I imagine a new object-type that can be a CIDR less-or-equal your allocation/assignment that references a abuse contact (which would bring in all sort of questions regarding authorization etc.) or an inet(6)num: with special type ABUSE-CONTACT (or something else).
I think that this is a special case that probably not many people have use for. Right now having abuse-c at inet(6)nums would ease the pain for quite a few people.
I agree entirely with you that to add "abuse-c:" directly into the resource objects would make life simple and it is easy to add the data at any point in the networks. The reason we didn't do this is that although it initially seems like the simplest solution it hides many cumulative problems further down the line. There is currently no tool for tracking or managing dispersed abuse contact data. This is why I introduced NWI 1. We know from past experience when abuse contact details were allowed in 4 different object types as well as being added to "remarks:" attributes it became impossible to manage. The data was spread all over the database with multiple references to, often, stale or conflicting data. Centralisation and using inheritance were fundamental to the design. David's idea is very similar to one of my proposals in a RIPE Labs article I wrote many years ago on this issue: https://labs.ripe.net/Members/denis/suggestions-for-improving-abuse-handling Using the "mnt-routes:" construct and allowing multiple "abuse-c:" attributes allows the abuse contact details to be easily set up for any specific resource with any degree of granularity, allowing any customer to manage the ROLE object holding the email address and still keep all the data centralised for an organisation. cheers denis
Best Regards
Sebastian