[db-wg] abuse-c: important points on it's usage

HI All

I make no apologies for the length of this email, but I would ask anyone 
concerned with abuse handling, RIPE Database data management and RIPE 
Database maintenance to read it. I am not trying to be a perfectionist 
or technical purist, but the changes being forced through now do matter.

cheers
denis


When "abuse-c:" was first proposed, Tobias (co-chair of Anti Abuse WG) 
and I spent a lot of time discussing how to achieve the intended goal. 
We came up with the current implementation, which after community 
discussion was approved. But you never think of everything in the first 
instance. I believe there is one piece missing that allows the whole 
system to be broken (see later). I also believe the changes being made 
(without proper discussion) by the RIPE NCC's 'improvements' to 
Webupdates will break the abuse-c system over time.

As a separate issue, but related to this, I think the RIPE NCC should 
give advance notice to the community of changes to interfaces like 
Webupdates and allow some discussion on significant changes like 
ORGANISATION object creation and authorisation and not just 'slip them 
in', then try to justify them when someone notices. These are major 
changes to the way the RIPE Database works. They are not just changing 
the look and feel of Webupdates as an interface tool.

So lets start with some history.

The goal of "abuse-c:"
When the data model was designed there was no thought given to abuse 
contacts. The internet was much smaller and more personal. The data 
model was built on the principle of human readability and not 
programatic parsing. So when the need for abuse reporting was first 
considered necessary it was good enough to add things like:
remarks: In case of abuse contact me at here.com

You could put this anywhere and someone would find it. Then it got a bit 
more formal and we introduced the "abuse-mailbox:" attribute. But this 
was allowed in five or six object types. None of these were the resource 
objects. So the information was scattered all over the database. This 
was still almost impossible to find programatically.

The goal of "abuse-c:" was:
-to have one way of documenting abuse contact details
-parsable programatically
-very simple for majority of resources
-flexible for any other resource situation

The "abuse-c:" design
Tobias and I considered many options to achieve these goals. What we 
focussed in on was that most small to medium LIRs may have many 
resources but only one person/role handling abuse complaints. All these 
resource objects in the database referenced their one ORGANISATION 
object. So by adding the "abuse-c:" attribute to the one ORGANISATION 
object, referencing a ROLE object containing the contact details, we 
handled a large number of simple cases in a very simple way. All the 
resources referencing this one ORGANISATION object and all the more 
specific resources would inherit this contact information from this one 
location. Easy to set up, easy to maintain.

But there are other situations. For example sub allocations. We also 
considered that accountability is an important element of this public 
registry database. There is a notion that when a resource is allocated 
or assigned by the RIPE NCC to an organisation, then that organisation 
is ultimately responsible for anything that happens regarding that 
resource. This is why ORGANISATION objects are mandatory for any 
organisation that wants to hold internet resources. So we considered 
that if part of the responsibility has been delegated to another 
organisation with a sub allocation, it is not unreasonable that another 
ORGANISATION object should be created to reflect this delegated 
responsibility. If this second organisation handles the abuse reporting 
for this sub allocation, then another "abuse-c:" attribute can be added 
to their ORGANISATION object to reflect this. If the LIR who is 
responsible for this allocation, including the sub allocation, wants to 
handle all abuse reports for the whole of their allocation then no 
"abuse-c:" should be added to the second ORGANISATION object. The sub 
allocation will then continue to inherit the abuse contact details of 
the LIR who holds the whole resource.

Inheritance vs Scattering
The data model for the RIPE Database was not designed with inheritance 
in mind. In many situations duplicated, redundant data is scattered all 
over the database. There are over 3 million INETNUM objects in the 
database. They all contain one or more "admin-c:" and "tech-c:" 
attributes. In reality all these references are to a few tens of 
thousands of individual roles. These contacts could be inherited from 
the ORGANISATION objects in the way "abuse-c:" has been set up. The 
"abuse-c:" was designed to be inherited and not to be duplicated where 
it is not needed.

The changes made recently to Webupdates by the RIPE NCC (without any 
discussion) breaks the inheritance of "abuse-c:". It forces the 
scattering of more redundant data throughout the database.

If you create an ORGANISATION object with Webupdates it forces the 
addition of an "abuse-c:" attribute whether it is needed or not. They 
argue that you can refer to an existing ROLE object making it the same 
abuse contact. Even if this was set up correctly it is redundant data. 
In reality people setting this up quickly will just take the easy option 
of giving any email address (mickey at mouse.com). They may not realise the 
impact of this. But this simple mistake overrides the LIRs genuine abuse 
contact details from any point in a network where this new ORGANISATION 
object is referenced.

Understanding your network and the RIPE Database
What it comes down to is that you should understand how your network is 
structured. You should at least know who needs to be contacted, for what 
reason, from which point in your network.

Unfortunately with the current data model you also need to have at least 
a basic understanding of how the data is structured within the RIPE 
Database. And to be honest if you don't understand the basic structure 
of the RIPE Database you should not be managing data in it, maintaining 
it or documenting it.

With knowledge of your network and the database you can decide where you 
need to put "abuse-c:" attributes. DO NOT add extra, redundant 
"abuse-c:" attributes.

What can possibly go wrong?
In defence of their unannounced changes to Webupdates, the RIPE NCC has 
argued that adding additional "abuse-c:" attributes is harmless and will 
NOT lead to bad data in the database. Forcing users to add additional, 
redundant data that breaks the principle of inheritance is in itself 
technically wrong.

But without being a technical purist what else can go wrong? Once these 
additional references have been added, the seeds have been sown for 
future mistakes. It all depends now on who maintains what and who is 
notified of what changes. The referenced ROLE object can be changed or 
the "abuse-mailbox:" value in the ROLE object can be changed. This could 
be accidental or with good intent, but just got it wrong or even 
maliciously. Without the proper checks this can easily go unnoticed. 
Over time some/many of these redundant references may/will get out of 
sync with what they should refer to. In a few years time someone will 
argue that all this contact data is messed up, abuse-c did not work and 
we will invent a new system...

The missing bit
The "abuse-c:" attribute does work and will work well if used properly. 
But there is one bit missing from the original design....proper 
notifications.

We need another attribute adding to the ORGANISATION object
abuse-notif:    [required]   [multiple]     []
This will allow the resource holder to keep an audit trail of any 
changes made to the abuse contact details for any parts of their 
resources. The 'required' (as defined in the database documentation) 
means it is syntactically optional, but business rules enforce it's 
presence in some situations. This should be added to any ORGANISATION 
object referenced by a resource object. Any addition, change or deletion 
of any part of the abuse contact details ("abuse-c: attribute, 
referenced ROLE object, "abuse-mailbox:" attribute) at any part of a 
network will be notified to the resource holder's email address 
specified in this attribute. Only the "abuse-notif:" referenced via the 
top level of a resource object will be notified. Any redundant 
references in more specific objects will be ignored (and should be 
removed, warned or disallowed).

This means the resource holder will always be notified if anything is 
changed at any point in the resources/networks they are responsible for.

I also think it would be useful if RIPEstat could give a visual 
representation of where abuse contacts are located within a network. 
This would allow a resource holder to review who is managing abuse for 
any part of their networks.