[anti-abuse-wg] Proposal: Publish effective users' abuse-c

Hi Alessandro

A query on APNIC's web query form for 136.185.0.0/16 only specifies a
single abuse email contact. The other email address in the rdap output
is the "email:" attribute value from the referenced IRT object. That
is not intended for abuse reports. When we implemented abuse-c in the
RIPE Database, one of the underlying principles was to have a single
process for documenting and finding abuse contact details. We
specifically removed "abuse-mailbox:" from the IRT object, which APNIC
still has. So you can't directly compare the two database outputs.

There are many ways we can tweak the technical details of how abuse-c
works in the RIPE Database. Rather than go round in circles discussing
all possible permutations, perhaps it would be better if you specified
the behaviour you would like to see. If others in the community agree,
then the RIPE NCC can make the necessary technical changes. As long as
we don't break that basic principle of having the one process for
documenting and finding abuse contacts, each of which is singularly
defined, anything else can be changed.

cheers
denis
co-chair DB-WG

On Mon, 14 Feb 2022 at 11:09, Alessandro Vesely <vesely at tana.it> wrote:
>
> Hi,
>
> On Thu 10/Feb/2022 22:40:18 +0100 denis walker wrote:
> >
> > Yes you can allow any customer with an assignment to have their own
> > abuse-c contact. But the database query will only return a single
> > abuse contact for any IP address. If the assignment object has an
> > abuse-c then a query on any IP address in the range of that assignment
> > will only return the customer's abuse contact details. If an
> > assignment does not have an abuse-c then such a query will return the
> > resource holder's abuse-contact details. A query will not return both
> > the customer's and the resource holder's details.
>
>
> Queries at ARIN or APNIC (and maybe more) often return multiple addresses.  For
> example:
> https://rdap.apnic.net/ip/136.185.8.145
> has two addresses, returned as two entries in the relevant vcardArray.
>
>
> > However, this can be changed if the community wants something
> > different. We can make abuse-c a multiple attribute so the resource
> > holder can add the customer's and their own abuse-c to an assignment.
> > Or we can change the default behaviour of the query so when an abuse-c
> > is found in an assignment it always returns the resource holder's
> > abuse-c as well. Or we can add a new query flag to return both abuse-c
> > details when available. Or we can modify the abuse-c attribute in some
> > way so the resource holder can choose what a query returns.  Any
> > behaviour is possible as long as you define what behaviour you want
> > and the community finds it useful.
>
>
> I don't know if the current settings allows to enter a comma-separated list as
> an abuse-c string value.  Most often, the abuse-c value is an email alias.  So,
> I don't see why people would enter several addresses if they can manage the
> aliases.
>
> IMHO, it makes more sense to store multiple addresses if they can be added by
> different people.
>
>
> jm2c
> Ale
> --
>
>
>
>
>
>
> --
>
> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/