Hi Elvis On 04/11/2016 17:20, Elvis Daniel Velea wrote:
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?
The MNTNER object is a box holding anonymous security tokens. Whilst I agree authorisation should be personalised, it is not a good idea to mix this with corporate contact details in this way.
have an abuse-mnt: new attribute in a resource object and abuse-c as role object in the mnt.
This would be like the "mnt-irt:" attribute that implies security but is really contact. It confuses people enormously.
wouldn't that fix all the problems of granularity *and* keep it somehow organized into one type of object only?
Also links to MNTNER objects are multiple. This would lead to abuse contact data being splattered all over the database with links to multiple, conflicting and confusing abuse contacts. It would take us back to the swamp we had before we introduced "abuse-c:". cheers denis
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