[db-wg] Options for extending "abuse-c:"

Dear Aleksi

Thank you for your comments. I have replied in more detail in line below.

Sorry for another long email, but there really are a lot more discussion 
points about abuse-c implementation than you think...so I highlighted 
the important bit which was the last paragraph below and moved it to here:

****** The important bit *******
I may be going off at a tangent here, but I am trying to explain some of 
the background thinking as to why we implemented the abuse-c the way we 
did. We are trying to centralise the 'management' data in the database 
and link it to the organisation and allow it to be inherited by other 
data. In the long term this should reduce the amount of the management 
data in the database. We don't want to go the other way and increase the 
amount of duplicated management data. Right now the database has far 
more management data in it than operational data. With proper use of 
inheritance and better management tools, there could be a massive 
reduction of this management data.
*****************************

Regards
Denis Walker
Business Analyst
RIPE NCC Database Team

On 07/05/2014 03:27, Aleksi Suhonen wrote:
> Hello,
>
> On 05/06/2014 06:01 PM, Denis Walker wrote:
>> Two issues have been identified that are seen to be difficult to handle
>> with the current model - partitioned subnets within one organisation and
>> adding abuse contacts to more specifics for End Users. The RIPE NCC has
>> considered these two issues and found what we believe to be practical
>> solutions, available within the current model.
>
>> More information about these solutions and the implementation of
>> "abuse-c:" is available on RIPE Labs:
>> https://labs.ripe.net/Members/denis/suggestions-for-improving-abuse-handling 
>>
>
> I find this suggestion clumsy. It adds hard to parse extraneous 
> information to simple objects. The organization object for a very 
> large organization would become unmanageable and unintelligible quickly.

Who do you believe is going to parse this object for this information? 
The RIPE NCC already has an Abuse Finder tool which can be accessed 
directly or via RIPEstat. As I said in the last paragraph of my article, 
people should start to move away from the old fashioned idea of digging 
directly into the RIPE Database themselves to find data, parse it and 
interpret it. If you need information the RIPE NCC will provide web 
tools and API calls to supply that information. We will  do all the 
digging, parsing and interpretation for you.

We will also provide tools for maintainers of the data to provide you 
with a neat overview of who handles abuse throughout your whole network. 
We also proposed a wizard for adding and removing abuse contact details 
for your End Users. We can also add functionality to the overview page 
to add/remove further abuse details for your subnets.

In the end it should not matter to you where this data is stored in the 
database. You deal in information, we deal in data storage and 
retrieval. To be honest we don't even need to put this data into any 
object. We can just store it as meta data associated with your 
organisation. As long as we provide you with tools to view and manage 
the information and for the public to find what they need....leave the 
storage to us.

>
> I would much rather like to see a new inetnum and inet6num object 
> status "INFORMATIONAL" that only requires authorization of the 
> immediately larger enclosing inet(6)num object, and doesn't represent 
> an assignment or allocation at all. Such objects can then be used to 
> redirect technical, administrative and abuse contacts to the proper 
> places, as well as present their own remarks and descriptions.

I believe this is going in completely the wrong direction. This means 
creating more 'management' objects and replicating even more data all 
over the database. We already have 3.8 million INETNUM objects all with 
a mandatory admin-c and tech-c. That is 7.6M bits of replicated data! We 
only have 10k members. These members manage the majority of the end user 
resources as well as their own networks. What this database is really 
missing is inheritance. Most of this management information could be 
stored with your organisation, as the abuse-c is, and then inherited by 
most of the operational data.

Just did some quick stats...we have 7.4M objects in the database and 
1.96M unique nic-hdls used in the admin-c, tech-c and zone-c attributes. 
We know some large users have a business model to create a nic-hdl for 
every customer. They certainly account for a few hundred thousand of 
these nic-hdls. So probably we have about 1.5M nic-hdls replicated over 
7.4 million objects. That is a lot of data duplication.

>
> This solution would cover PI, PA and all other styles of address 
> blocks equally well. I know this has been suggested many times before, 
> but I still think it would be a much more elegant solution to this 
> problem.
>
> Yours,
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/db-wg/attachments/20140507/f73b5012/attachment.html>