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, ripede...@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.mas...@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
