On Wed, Nov 04, 2015 at 09:02:42PM +0100, denis wrote:
It has served very well over the years but it does have limitations now. This is a database. You put stuff in and get stuff out. When you need a full day course to learn the basics of putting stuff in, it shouts there is a problem.
I don't think anyone who knows the ripedb can disagree with you there. The thing *is* a monster.
This again shouts it is time for a step back and rethink the way contact data is used, by whom and for what reason and who can be trusted for what.
Yup, I can get behind that. I need to see a certain dataset about resources I'm involved in managing, the NCC needs another and Tom, Dick & Harry (ie the wider community) another. I forsee an "interesting" discussion about that one, though ;p
You mentioned privacy and protection of personal data in the database. Lets add to that security of data. Why does anyone need to see your MNTNER object. Why does anyone need to know who maintains your data, who can create your customer data, who gets notified of changes, etc. Another of my ignored proposals was to completely separate the operational data from the data needed to maintain the operational data. In other words the MNTNER objects and related PERSON and ROLE objects and all details of notifications and references to "mnt-by:", "mnt-lower:", etc. All this maintenance data is your business and no one elses. If they are separated all the maintenance info can be private and only available to you from your user account.
I would be delighted if there were a db structured on a need-to-know model and I'll certainly be willing to help with a proposal to this effect.
Now to do this also depends on another of my ignored ideas to use inheritance in the database to massively reduce the amount of duplicated data and rely more on the organisation centric model (another ignored idea) with more fixed, inherited data contained in, or linked to, the ORGANISATION object. As with the "abuse-c:". Almost 4 million INETNUM objects with tens of thousands containing identical data except for prefix and description. That is just crazy. But the original design did not consider this amount of growth.
Well, policy has to bear some guilt for that. If you have to register every /29 where the only differing information is the actual prefix and (possibly) the descr: field... It's a bit saner for ipv6 if only to avoid blowing the ripedb out of the water with assignments out of one /32...
Seriously, with a review of the data model we can end up with: -a lot less personal data in the database -contact data more relevant to the purpose -relevant contacts only visible to the groups of people who need it -chain of trust in organisations who manage the data -verification done closer to the data source -more accurate and more trusted and better protected contact data
I've no issues with any of those proposals, with the caveat about the Devil and the details, of course. cheers, Sascha Luck
