[anti-abuse-wg] abuse-c attributes in resource objects

The "FAQs for abuse-c" says:

You can have an "abuse-c:" attribute on both your ORGANISATION object AND your RESOURCE object
(inetnum, inet6num and aut-num). The "abuse-c:" reference on applicable RESOURCE objects will
override the value in the "abuse-c:" of your ORGANISATION object.

[https://www.ripe.net/manage-ips-and-asns/resource-management/faqs-for-abuse-c]


However, in the RIPE documentation, the list of all possible attributes allowed in AUT-NUM
and INETNUM objects does *not* include "abuse-c":

[https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation/
rpsl-object-types/4-2-descriptions-of-primary-objects/4-2-1-description-of-the-aut-num-object]

[https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation/
rpsl-object-types/4-2-descriptions-of-primary-objects/4-2-4-description-of-the-inetnum-object]


There are currently some RESOURCE objects in the RIPE database having abuse-c attributes
(which should not be allowed according to the documentation). For example:

inetnum:        62.27.57.0 - 62.27.57.255
netname:        TIS-D406483-NET
descr:          Cheetah Digital Germany GmbH
country:        DE
admin-c:        NET12312-RIPE
tech-c:         NET12312-RIPE
abuse-c:        CDAC23-RIPE
status:         ASSIGNED PA
mnt-by:         AS12312-MNT


So we wonder what is correct?

We would prefer sticking to the documentation allowing abuse-c attributes only in ORGANISATION
objects but not in RESOURCE objects as this makes maintaining a local abuse contact database
(for CERTs sending thousands of abuse reports per day) much easier.
For example, for our local contact database, we import all ORGANISATION objects with "country: DE"
and use "org-name" for the contact's name. Then, we link all RESOURCE objects referencing this ORG
to the respective contact in our database. Also evaluating abuse-c attributes directly included
in RESOURCE objects would make building a local contact database much more complex.



     - Thomas

CERT-Bund Incident Response & Malware Analysis Team