Hi Giles Unfortunately it is not easy to accommodate every possible arrangement and keep it tightly controlled. Before "abuse-c:" was introduced the "abuse-mailbox:" attribute was allowed in 5 object types and it became unmanageable. (It still is in 5 object types as the clean-up has not yet been done.) On 29/01/2016 17:21, Gilles Massen wrote:
Hi Denis,
IIRC, when I looked into this your proposed workaround was not possible for a maintainer/legacy reason, but since we brought the LEGACY assignments properly under the RIPE roof, it should work know.
BUT, I have a real issue with the workaround. The argument for restricting the abuse-c to an organisation was to prevent duplicate data, especially the hypothetical appearance of unmaintained contacts. However, this is exactly what you are proposing with a duplicate ORG. So
Strictly speaking it is not exactly a 'duplicate' ORGANISATION object. Something is different at this point in your network (abuse handler). But we don't have any other way of noting a difference except by using the ORGANISATION object. I really wish people were willing to at least talk about a data model review. So much could be improved. cheers denis
instead of the hypothetical problems of keeping the fundamental logic of 'more specific', a tool only to be used by those who'd need it, the workaround makes them a certainty. 'Clumsy' does not quite describe it.
In our specific case, I'd stay the slightly worse abuse-c, rather than duplicating ORG objects. Unfortunately enough, the loss (as small as it might be) is not mine...
best regards, Gilles
On 28/01/16 21:10, ripedenis@yahoo.co.uk wrote:
Hi Gilles
Yes it is possible to do this. I know I keep saying this and I know no one wants to even talk about it but the current data model does impose some limitations. However, even with these limitations it is all about how you perceive certain objects functions. An organisation that holds resources must have an ORGANISATION object if they are not legacy resources and may have one if they are legacy resources. There is nothing stopping that organisation creating multiple ORGANISATION objects and using them to represent departments within the same organisation or representing some sub characteristic of the organisation. Whatever it represents can be made clear in "descr:" and "remarks:" attributes within the other ORGANISATION objects. These ORGANISATION objects can be referenced from any more specific INETNUM object and contain an "abuse-c:" attribute.
I know this is a bit clumsy, but it IS easy to do and can be clearly documented and can accommodate any arrangement of abuse handling you wish to represent.
cheers denis
------------------------------------------------------------------------ *From:* Gilles Massen <gilles.massen@restena.lu> *To:* anti-abuse-wg@ripe.net *Sent:* Thursday, 28 January 2016, 19:18 *Subject:* Re: [anti-abuse-wg] 2016-01 New Policy Proposal (Include Legacy Internet Resource Holders in the Abuse-c Policy)
Hello,
Since the rationale mentions the "better quality of abuse contact data", I'd like to point out that it is still not possible to have a different abuse-c for different inetnums, if they belong to the same ORG. The impossibility to have a "more specific" is the ONLY thing that prevents me to have accurate abuse contact data for our LEGACY addresses, not the absence of a specific policy.
regards, Gilles