On Sat, Jan 14, 2017 at 07:45:18PM +0100, denis wrote: Hi Denis
On 14/01/2017 09:33, Piotr Strzyzewski wrote:
It is currently not reasonably possible to specify alternative abuse contacts for resources in the RIPE Database assigned to organisations other than the parent organisation. In many circumstances these organisations are customers of the parent organisation. The lower organisation wishes to handle the abuse separate from the parent organisation. Would you be so kind and elaborate more about "(...) not reasonably
On Thu, Jan 12, 2017 at 12:43:06PM +0000,ripedenis@yahoo.co.uk wrote: possible (...)". Do I understand correctly that putting proper ROLE object in abuse-c attribute of ORGANISATION object is beyond reasonable possibility?
For a resource holder with an ORGANISATION object set up by the RIPE NCC, the default "abuse-c:" in that ORGANISATION object, referencing a ROLE object, should already exist now for all resources.
Some people have expressed concern over the amount of work required to add abuse contacts for customers. It can be done by creating a new ROLE object and a new ORGANISATION object, referencing the ROLE and containing either the customer's organisation details or a copy of the resource holder's organisation details. Then reference this new ORGANISATION object in the customer's assignment object.
For a handful of customers that is not difficult, although some still believe it is over complicated. If you have tens or hundreds of customers wanting to handle abuse complaints themselves, then it moves into the 'unreasonable' zone if all this has to be handled manually. If it is considered unreasonable and it is optional, then people won't do it and we don't have the best information available in the RIPE Database.
So, as I understand, the problem is either necessity to "create a lot of redundant objects" (as described by Gert Doering) or just a scale and automation (as described by you). None of this is beyond reasonable possibility to me. Although I can agree that both Gert and you are right with more detailed description of the problem and I'm ok with the problem description made in the original email. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl