[db-wg] More-specific abuse-c

Hi Sebastian

If this is going to be an NWI the process should be to identify a 
problem statement and then move onto possible solutions. But as we have 
gone so far down the road with many ideas already on the table let me 
address a few of the issues.

On 04/11/2016 13:38, 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.

Firstly don't worry about how the database parses data. This is trivial 
compared to some of the parsing it already does.

One of the key objectives of this "abuse-c:" design was specifically to 
bring all abuse contact details into a centrally controlled place. I 
agree it has caused some problems. But having multiple "abuse-c:" 
attributes in the ORGANISATION object still keeps it central and the 
referenced ROLE objects that hold the "abuse-mailbox:" attributes can 
still be managed by the different customers allowing them to control the 
actual email address in use.

>
>
>> 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.

I agree entirely with you that to add "abuse-c:" directly into the 
resource objects would make life simple and it is easy to add the data 
at any point in the networks. The reason we didn't do this is that 
although it initially seems like the simplest solution it hides many 
cumulative problems further down the line.

There is currently no tool for tracking or managing dispersed abuse 
contact data. This is why I introduced NWI 1. We know from past 
experience when abuse contact details were allowed in 4 different object 
types as well as being added to "remarks:" attributes it became 
impossible to manage. The data was spread all over the database with 
multiple references to, often, stale or conflicting data.

Centralisation and using inheritance were fundamental to the design. 
David's idea is very similar to one of  my proposals in a RIPE Labs 
article I wrote many years ago on this issue:
https://labs.ripe.net/Members/denis/suggestions-for-improving-abuse-handling

Using the "mnt-routes:" construct and allowing multiple "abuse-c:" 
attributes allows the abuse contact details to be easily set up for any 
specific resource with any degree of granularity, allowing any customer 
to manage the ROLE object holding the email address and still keep all 
the data centralised for an organisation.

cheers
denis

>
> Best Regards
>
> Sebastian
>