NWI-7 proposal for fixing "abuse-c:" problems

Tue Apr 18 16:03:29 CEST 2017

Colleagues
Below is a proposal for fixing the problems with "abuse-c:" as shown in the problem statement for NWI-7https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items

I look forward to comments.

cheers
denis
co-chair DB-WG
Proposal for improving "abuse-c:"

Background
When abuse contact information was first discussed it was agreed that provision should be made for multiple contact methods, email being just one method. This is why the ROLE object was used to hold the "abuse-mailbox:" attribute. It was decided to reference this abuse ROLE object by an "abuse-c:" attribute in the ORGANISATION object to provide a default option that covered all resources held by an organisation. All resources, including all more specific data, share this contact information in an inherited way. A second reason for setting this up using the ORGANISATION object was to keep a close link between the contact information and the organisation behind those contact details. Without this link, it's just an email address. In that case, unless someone understands the hierarchical nature of resources and the contractual relationships between the parties managing data in the RIPE Database, it's not clear who is behind that email address and responsible for handling abuse.

Problem
It's clear from the problem statement that some situations cannot be handled with the current arrangement. Mainly because it would require a reference to a second ORGANISATION object from a resource object. This is not possible with the syntax and business rules in the database.

There is also a question over the double indirection to get to the abuse contact information, ie resource object -> ORGANISATION object -> ROLE object. If it is accepted that an email on it's own is not sufficient information and the clear link to the organisation with responsibility for handling abuse is also required, then this double indirection is needed. With the right tools it's easy to manage this data. This point is not a technical or operational show stopper. It's more about who needs what information and how do they get it.

Proposal
I propose introducing a new attribute, "contact-org:" and changing some of the business and syntax rules for the ORGANISATION object. (See below for detailed database changes needed.)

For most users where the current default "abuse-c:" mechanism works, nothing will change.

For those users who need to specify an alternative abuse contact at some point in a network or for one or more of their allocated/assigned resources it would be a simple process. At the point where the alternative contact details are required add a "contact-org:" attribute referencing a new ORGANISATION object. This new ORGANISATION object will reference the resource holders main ORGANISATION object. If it is the resource holder that is handling the abuse, but from a different department, the new ORGANISATION object can inherit almost everything from their referenced main ORGANISATION object. All that would be needed is a different "abuse-c:" attribute. If it is a separate organisation/person who is handling the abuse, additional information can be entered into the new ORGANISATION object to identify who is behind the abuse contact email address.

Query order
-For the default situation it remains the same as now, search up the hierarchy to find the "org:" attribute, take the "abuse-c:" from there.
-While searching up the hierarchy, if a "contact-org:" is found that references an ORGANISATION object containing an "abuse-c:" attribute, use this.
-Where both "org:" and "contact-org:" exist in the same object, "contact-org:" takes precedence.

Automation
Tools and API calls can be provided to create the necessary extra objects and add attributes where required. To delete the additional abuse contact just remove the "contact-org:" attribute. If the extra objects are not referenced anywhere else it will leave an orphaned 'sub' ORGANISATION object referencing a ROLE object. These pair of objects can be automatically removed by the database garbage process after 90 days.

Cleanup
A one time cleanup would be needed to replace any "org:" attributes in more specific resource objects with "contact-org:". Also the referenced ORGANISATION objects would need an additional "org:" attribute referencing the resource holders ORGANISATION object.

Wider view
This mechanism would also work with both "admin-c:" and "tech-c:" attributes. It allows the flexibility to inherit all contact details from the one resource holders ORGANISATION object through to any degree of complexity with any of the contact types.

Detailed database changes
Make the attributes "address:" and "e-mail:" in the ORGANISATION object optional. Adjust the business rules so that an ORGANISATION object that does not contain an "org:" attribute referencing another ORGANISATION object containing these attributes will be required to have these attributes itself. This keeps things as they are now.

Make the "org:" attribute in the ORGANISATION object single instead of multiple. Not sure why it was multiple in the first place. (Quickly checked the split file and it looks like no one uses this attribute in an ORGANISATION object anyway.)

Allow an ORGANISATION object to inherit any missing attributes from a referenced ORGANISATION object.

Create a new attribute "contact-org:", optional and multiple, in the INET(6)NUM and AUT-NUM objects. This references an ORGANISATION object.

Examples

Current default situation:
The following two objects provide the abuse contact for all the resources held by 'Denis Organisation' including, say, 10.100.0.0/16

organisation:   ORG-DO1-RIPE
org-name:       Denis Organisation
org-type:       LIR
desc:           organisation details for Denis Organisation
address:        Amsterdam
phone:          0000000000
e-mail:         ripedenis2 at yahoo
abuse-c:        ado18-ripe
admin-c:        dw-ripe
tech-c:         dw-ripe
mnt-ref:        RIPE-NCC-HM-MNT
mnt-ref:        AARDVARK-MNT
mnt-by:         RIPE-NCC-HM-MNT
mnt-by:         AARDVARK-MNT
notify:         ripedenis2 at denis.org.uk
created:        2017-03-09T13:21:52Z
last-modified:  2017-05-20T10:49:27Z
source:         RIPE

role:           Abuse Denis Organisation
address:        NL
e-mail:         ripedenis2 at yahoo
abuse-mailbox:  abuse at denis.org.uk
nic-hdl:        ADO18-RIPE
mnt-by:         AARDVARK-MNT
created:        2017-05-02T14:19:09Z
last-modified:  2017-05-02T14:19:09Z
source:         RIPE

inetnum:        10.100.0.0 - 10.100.255.255
netname:        EU-10
country:        NL
org:            ORG-DO1-RIPE
admin-c:        DW-RIPE
tech-c:         DW-RIPE
status:         ALLOCATED PA
mnt-by:         RIPE-NCC-HM-MNT
mnt-lower:      AARDVARK.MNT
created:        2017-03-11T11:17:15Z
last-modified:  2017-09-23T13:18:26Z
source:         RIPE

Different "abuse-c:" within same organisation - allocation:
Suppose 'Denis Organisation' also holds the allocation 10.200.0.0/16 and they want a different department within the same organisation to manage the abuse for this second allocation.
They create a second ORGANISATION object (ORG-DOA3-RIPE) with the least amount of data, the rest being inherited from their referenced main ORGANISATION object (ORG-DO1-RIPE). In this new ORGANISATION object they reference the new "abuse-c:" ROLE (aado20-ripe) containing the alternative abuse email address.
In the allocation object (10.200.0.0 - 10.200.255.255) they add the new "contact-org:" referencing the new ORGANISATION object (ORG-DOA3-RIPE).
If the business situation changes and all abuse is now handled by the default handler, simply remove the "contact-org:" attribute. The additional objects, if unreferenced, will be deleted by the database garbage collector.

organisation:   ORG-DOA3-RIPE
org-name:       Denis Organisation Alternative
org-type:       OTHER
org:            ORG-DO1-RIPE
abuse-c:        aado20-ripe
mnt-ref:        AARDVARK-MNT
mnt-by:         AARDVARK-MNT
created:        2017-03-09T13:21:52Z
last-modified:  2017-05-20T10:49:27Z
source:         RIPE

role:           Alternative Abuse Denis Organisation
address:        NL
e-mail:         ripedenis2 at yahoo
abuse-mailbox:  alternative-abuse at denis.org.uk
nic-hdl:        AADO20-RIPE
mnt-by:         AARDVARK-MNT
created:        2017-05-02T14:19:09Z
last-modified:  2017-05-02T14:19:09Z
source:         RIPE

inetnum:        10.200.0.0 - 10.200.255.255
netname:        EU-10
country:        NL
org:            ORG-DO1-RIPE
contact-org:    ORG-DOA3-RIPE
admin-c:        DW-RIPE
tech-c:         DW-RIPE
status:         ALLOCATED PA
mnt-by:         RIPE-NCC-HM-MNT
mnt-lower:      AARDVARK.MNT
created:        2017-03-11T11:17:15Z
last-modified:  2017-09-23T13:18:26Z
source:         RIPE

Different "abuse-c:" within same organisation - PI:
Suppose 'Denis Organisation' also holds the 10.500.0.0/16 as an ASSIGNED PI resource and they want a different department within the same organisation to manage the abuse for this PI resource. The process is exactly the same as above. It is the same for any resource held by the organisation, allocation, PI, ASN.

organisation:   ORG-DOA3-RIPE
org-name:       Denis Organisation Alternative
org-type:       OTHER
org:            ORG-DO1-RIPE
abuse-c:        aado20-ripe
mnt-ref:        AARDVARK-MNT
mnt-by:         AARDVARK-MNT
created:        2017-03-09T13:21:52Z
last-modified:  2017-05-20T10:49:27Z
source:         RIPE

role:           Alternative Abuse Denis Organisation
address:        NL
e-mail:         ripedenis2 at yahoo
abuse-mailbox:  alternative-abuse at denis.org.uk
nic-hdl:        AADO20-RIPE
mnt-by:         AARDVARK-MNT
created:        2017-05-02T14:19:09Z
last-modified:  2017-05-02T14:19:09Z
source:         RIPE

inetnum:        10.500.0.0 - 10.500.255.255
netname:        EU-10
country:        NL
org:            ORG-DO1-RIPE
contact-org:    ORG-DOA3-RIPE
admin-c:        DW-RIPE
tech-c:         DW-RIPE
status:         ASSIGNED PI
mnt-by:         RIPE-NCC-END-MNT
mnt-by:         AARDVARK.MNT
created:        2017-03-11T11:17:15Z
last-modified:  2017-09-23T13:18:26Z
source:         RIPE

Customer handling their abuse reports:
If you assign to a customer who handles their own abuse reports create an ORGANISATION object (ORG-CXO12-RIPE) for the customer, referencing your main ORGANISATION object (ORG-DO1-RIPE). Fill in any details relevant to the customer. Any other details are inherited from your ORGANISATION object. Create the ROLE object (CXA321-RIPE) for the customer's abuse contact details. Add a "contact-org:" attribute to the assignment referencing the customer's ORGANISATION object (ORG-CXO12-RIPE).
If the business situation changes and all abuse is now handled by the resource holder, simply remove the "contact-org:" attribute. The additional objects, if unreferenced, will be deleted by the database garbage collector.

organisation:   ORG-CXO12-RIPE
org-name:       Customer XYZ Organisation
org-type:       OTHER
org:            ORG-DO1-RIPE
address:        xyz address
phone:          0101010101
abuse-c:        cxa321-ripe
mnt-ref:        AARDVARK-MNT
mnt-by:         AARDVARK-MNT
created:        2017-03-09T13:21:52Z
last-modified:  2017-05-20T10:49:27Z
source:         RIPE

role:           Customer XYZ Abuse
address:        NL
e-mail:         info at xyz.org.uk
abuse-mailbox:  abuse at xyz.org.uk
nic-hdl:        CXA321-RIPE
mnt-by:         AARDVARK-XYZ-MNT
created:        2017-05-02T14:19:09Z
last-modified:  2017-05-02T14:19:09Z
source:         RIPE

inetnum:        10.100.5.0 - 10.100.5.255
netname:        EU-10
country:        NL
contact-org:    ORG-DOA3-RIPE
admin-c:        DW-RIPE
tech-c:         DW-RIPE
status:         ASSIGNED PA
mnt-by:         AARDVARK.MNT
created:        2017-03-11T11:17:15Z
last-modified:  2017-09-23T13:18:26Z
source:         RIPE

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ripe.net/ripe/mail/archives/db-wg/attachments/20170418/dbfe350d/attachment.html>