[db-wg] anyone using the RIPE Databse MUST now have an SSO account?

Denis,

At 2015-12-01 15:49:10 +0100
denis <ripedenis at yahoo.co.uk> wrote:

> You said you would welcome my thoughts...so here they are...I know the 
> data model is a taboo subject. But I hope you and others will actually 
> read this email and think about what I said.

Is it? I didn't get the e-mail declaring data model off-limits, but
maybe it's in my spam filter. ;)
 
> Security of data and permissions in the RIPE Database is one of these 
> areas that is fundamentally broken and cannot be fixed with this data 
> model, no matter how many tweaks you make. Who else, but the RIRs, 
> publish to the world so much detail about how you manage and secure your 
> data? Do you see Google, Apple, Microsoft, Facebook, Twitter, Yahoo, 
> Anyone publishing details of their users accounts?

All of those are big, for-profit American companies. Their design
constraints are different from a small, membership-driven European
organization.

Look at it another way. When I go to GitHub I can see who has
contributed to a repository, including every change in every file. Yet
you would hopefully not argue that GitHub is "fundamentally broken". ;)
 
> There are basically two types of data in the RIPE Database:
> 
> Operational data - the stuff this public registry exists to record and 
> publish along with details of who to contact if you have any issue with 
> any operational data.

I'd further divide "operational data" into "number registry data" and
"routing registry data". Routing policy information is definitely
operational, but not managed by the RIPE NCC.
 
> Management data - the details of how you, as an individual or corporate 
> entity, manage your operational data in this database. This includes 
> details of your security credentials, who has permission to do what, who 
> gets notified when things happen, etc.

This is basically meta-data. I'd divide this also, into secret and
non-secret management data. Information about who made changes and when
is not strictly necessary operationally, but can be useful, so perhaps
should be non-secret. As an example, we have this today with the
"last-modified:" attribute.

I am careful not to use the word "public", because information can be
private but non-secret, or published under limited access and
non-secret. I tend to prefer everything be as open as possible, but
others may not share that view and there may be valid reasons to
restrict certain access.

> So the MNTNER object for example is clearly management data. Who, 
> outside of your organisation, needs to see anything in your MNTNER 
> object? Why do we tell the world that you have 3 passwords, 2 PGP and 4 
> SSO accounts managing your data? Why do we tell everyone who has 
> permission to create more specific customer operational data in the 
> database for your organisation ("mnt-lower:")? Why do we let the world 
> know that you have not set up any notifications so you will not notice 
> if this data is changed?

Fair enough. The whole "maintainer" concept was always kind of awful :(
 
> All I am proposing is that members/users/interested parties acknowledge 
> that the data model is old and could be improved and be willing to 
> seriously discuss the possibilities. If you are willing to throw off the 
> constraints of this old model many new and improved possibilities open up.

Also fair enough. As long as we keep the "second system syndrome" in
mind I think this makes sense.

Perhaps you can give an outline of your earlier (closed door) proposal?

Cheers,

--
Shane