[anti-abuse-wg] 2016-01 New Policy Proposal (Include Legacy Internet Resource Holders in the Abuse-c Policy)

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 at 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 at restena.lu>
>> *To:* anti-abuse-wg at 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
>>
>>
>>
>>
>>
>>
>>
>