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

Hello dbwg,

On 05/07/2014 01:52 PM, Denis Walker wrote:
> 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:

Thank you.

> On 07/05/2014 03:27, Aleksi Suhonen wrote:
>> 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?

Anyone who *wants* to? Isn't that what open source, open data and open 
interfaces are for?

> 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.

Oh dear, I'm feeling a huge ideological rift has developed here. Let me 
get this straight:

What you want is to hide away the whole RIPE database and provide a 
point and click interface which only dispenses those morsels of 
information you think people should have?

This may be fine for casual end users. However, I object at the idea of 
having it as the central design paradigm of the whole RIPE db.

> 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.

Um ... and the ISPs who use some integrated provisioning and IPAM 
software to automatically manage all their RIPE data should go and hire 
more secretaries to point and click at the wizard instead?

How do I get back to the 1990s where all the other people who think like 
me used to live?

>> 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.

This line of reasoning seems to lead to completely removing all inetnums 
and simply listing all address space in the organization object instead?

> 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.

What if, instead, you just make the contact attributes of most object 
types optional? If they are missing they get inherited from either the 
organization or the maintainer object. And then to clean up the 
database, you can remove all those contact attributes that are the same 
as what inheritance would yield.

As an unexpected added bonus, you will gain all the problems of multiple 
inheritance too! High five for modern concepts!

By the way, am I the only one that thinks 10 million RIPE objects is not 
a lot of data in 2014?

Yours,

-- 
	Aleksi Suhonen
     `What I need,' shouted Ford, by way of clarifying his
     previous remarks, `is a strong drink and a peer-group.'
        -- Douglas Adams, Life the Universe and Everything