Hi, I'm just throwing this idea to the mailing list without giving it extensive thought. But I believe it should work. Instead of having the abuse-c in the org, why don't we have it in the maintainer object? have an abuse-mnt: new attribute in a resource object and abuse-c as role object in the mnt. wouldn't that fix all the problems of granularity *and* keep it somehow organized into one type of object only? regards, elvis PS: david, so nice to see you active in this WG lately On 11/4/16 2:38 PM, Sebastian Wiesinger wrote:
Hi David,
thank you for the in-depth answer!
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
* fransossen@yahoo.com <fransossen@yahoo.com> [2016-11-03 12:12]: 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.
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.
Best Regards
Sebastian