[db-wg] More-specific abuse-c

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!
>
> * fransossen at yahoo.com <fransossen at 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.
>
>
>> 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
>