[db-wg] More-specific abuse-c

Dear WG,

> On 03 Nov 2016, at 10:31, Sebastian Wiesinger <sebastian at karotte.org> wrote:
> 
> * denis <ripedenis at yahoo.co.uk> [2016-11-03 00:30]:
>> Hi William
>> 
>> If we are going to follow the NWI then lets define the problem and then look
>> at available options to fix it. There are other ways to fix it and each
>> option has pros and cons.
> 
> I just requested a NWI for this.

I would just like to echo that at RIPE NCC we agree that there is a problem to address here.

And although this thread already shows shared understanding of the problem space and some great suggestions, I still believe that defining the problem statement a bit more formally, and including related issues, will help to make the discussion on solutions more structured and will help to weigh pros and cons.

So, I hope that the WG doesn't mind if I take a shot at formulating one. Obviously it can and should be discussed further, refined or even replaced altogether as part of the 1st phase of the NWI process.


Problem statement:
==================

It is currently not possible to specify alternative abuse contacts for different resources held by the same organisation in the RIPE Database. This can be problematic.

For example for abuse contact management for big organisations which want multiple abuse contacts for different parts of the organisation. The org is using a lot of PI resources, some of them legacy. Currently they all use the same ORGANISATION object which is inextricably linked to the same abuse-c mailbox. [example taken from Sebastian's first email]

Another example applies to different allocations held by a single LIR. The reference to the LIR's ORGANISATION object is maintained as part of the registry managed by RIPE NCC, and therefore all allocations will have the same abuse-c mailbox. There may however be good operational reasons for having different contacts. [same issue, slightly different example also mentioned by David]

It should be noted however that it is considered useful that in cases where there is no need to have a different abuse-c mailbox, the abuse-c can be defined on an ORGANISATION object that is referenced from an INET(6)NUM object, and have it apply to more specific INET(6)NUM objects through inheritance. This avoids data duplication, and makes it easier to manage this information.

But on the other hand it should also be noted that for a lot of less experienced users of the RIPE database it has proven to be difficult to find the applicable abuse contact for a resource, following this hierarchy. For this reason the abuse contact is now mentioned as a comment in whois output, and is highlighted explicitly on the web query results.

As a somewhat related issue I would also mention the following:

Management of administrative and technical contacts in the RIPE Database is done differently, and the challenges of maintaining that data is somewhat different. While here it is possible, or even mandatory, to have explicit references to admin-c or tech-c contacts for each resource object that may differ from the objects, it is *not* possible here to inherit these contacts from a covering INET(6)NUM or ORGANISATION object. This results in an increase in maintenance burden for this data and therefore makes it more difficult to maintain accurate data.


> Do you have other (better) ways in
> mind already?

We have had some discussions about this as well, and I have some ideas as well. It's pretty close to "option b" that David mentioned, but with some tweaks that we believe will make it easy to apply a consistent approach for abuse-c, admin-c and tech-c management, lowering maintenance for organisations that have no need to use different contacts, whilst allowing more complex organisations to override where necessary. At the same time we can keep the impact and burden on clients of the RIPE Database minimal.

I would love to discuss in more detail, but before I I go further do I would like to ask the chairs if I should do so now, or wait until we have a defined problem statement.


Kind regards,

Tim Bruijnzeels

Assistant Manager Software Engineering
RIPE NCC Database Group





> 
> Regards
> 
> Sebastian
> 
> -- 
> GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)
> 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
>            -- Terry Pratchett, The Fifth Elephant