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!
* [email protected] <[email protected]> [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.
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
