[acm-tf] Abuse Contact Information - Policy Proposal

HI Alessandro

Perhaps I can play devils advocate here and put a couple of questions to
you. These are not technical issues so I won't express any opinion
either way. I will just throw the questions out for you and the other TF
members to consider. (Although they do touch on some technical issues as
well.)

On 17/10/11:43 8:29 PM, Alessandro Vesely wrote:
>> Any suggestions for a better wording?
> 
> How about
> 
>    The "abuse-c:" reference to an abuse handler should make use of
>    the hierarchical nature of the resource data, so that a given
>    abuse team retains its relationship with the relevant resources
>    until a different "abuse-c:" reference explicitly overrides it for
>    a given assignment.  Such transfers of abuse handling to less
>    specific assignments are not meant to be automated, yet they
>    minimize the workload on resource holders and facilitate good
>    database design.
> 
> ?

Brian mentioned the issue of responsibility. With the IRT object we
assumed responsibility in a network hierarchy as recorded in the RIPE
Database? So for any IP address an IRT object referenced by the most
specific encompassing object held the relevant contact details (if any
IRT object was found). Can you assume the same responsibility structure
for abuse handling? Will an LIR, by default, be responsible for all
abuse complaints for their (PA assignments and sub allocations)
customers who don't manage it themselves? That is the practical reality
of using this network hierarchy in this way, especially if you make it
mandatory that an "abuse-c:" is referenced at some point in all hierarchies.

You said above "a different abuse-c: reference explicitly overrides it
for a given assignment". This is the case now for IRT. For abuse
handling do you want this to 'override' or 'take precedence over' a less
specific reference? The Abuse Finder tool should be promoted as the
preferred way for anyone to find abuse contact details in the RIPE
Database. There is a web form for 'the public' to use for one off
enquires and we have an API for 'power users' to use for doing many
queries. The logic of the Abuse Finder can be made to do whatever you
want. So if you want the 'override' option in the hierarchical lookups
we can stop searching at the first encompassing object with an
"abuse-c:". If you want the 'take precedence over' option we can
continue up the hierarchy until we get to an allocation and select all
"abuse-c:" attributes found.

As the Abuse Finder is a tool that interprets raw whois queries we can
structure the output any way you want. So with a precedence option we
could clearly show which addresses should be used first for any
complaint. But also list alternatives to use if the primary option does
not respond.

There was some talk earlier about best practices. If you have (or write)
such a document this could be referenced in the Abuse Finder output.

I know the TF was set up to decide where to 'put' abuse contact details.
But in order to finalise where to put the data, some thought must also
be given into how the data will be found and what interpretation can be
applied to the data.

Maybe the answers to these questions are obvious. But at least you will
have thought about it and have a clear answer ready if these questions
are asked when you present your policy to the community.

> 
>> 1.) Which one would be the correct domain-name?
> 

You are suggesting adding a mandatory attribute, but are you sure all
resource holders will have valid data to put in this mandatory
attribute? Your assumption here is that all IP and AS resource holders
have a domain name. Is that true?

cheers
denis