[db-wg] anyone using the RIPE Databse MUST now have an SSO account?
- Previous message (by thread): [db-wg] anyone using the RIPE Databse MUST now have an SSO account?
- Next message (by thread): [db-wg] anyone using the RIPE Databse MUST now have an SSO account?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Shane Kerr
shane at time-travellers.org
Wed Dec 2 12:48:01 CET 2015
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
- Previous message (by thread): [db-wg] anyone using the RIPE Databse MUST now have an SSO account?
- Next message (by thread): [db-wg] anyone using the RIPE Databse MUST now have an SSO account?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]