[db-wg] More-specific abuse-c

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!
>>
>> * 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
>>
>
>