All, The idea that this model is old is quite accurate. Much of these data models have a legacy that dates back the to the times where we were pushing emails around with authentication done using mail from. That was really broken. PGP and some of the earlier guardian initiatives tried to secure the problem but killed the user experience. These solutions lacked a fundamental ability to provide an elegant programatic interface, recall nasty perl scripts interpreting email. The maintainer system has survived this long because even as a blunt tool it was effective. As we talk about modernization efforts, I propose an Oauth solution as is the industry norm across most larger web properties today. This solves the SSO issue, while also offering the ability to federate authentication and separating from authorization. This is also applicable to API keys and enabling interfaces to access features programmatically. All of these would be great things. In regards to the data, All of this data was originally intended as a directory service for operational and research data. While the Internet was a much smaller (arguably different) network back then, this still holds mostly true today. I support the idea that this data should be used for network contact data including operational and abuse. It has also become increasingly important to contact the actual holder of a resource. I can also see the benefits of geo-loc capabilities and perhaps historical details. The academic research capabilities seem less important or may already enabled from making the rest of this data available. It is the marketing applications that everyone always frowns upon. This is where people try to implement security features and limit access to certain data. Other objections tend to be a lack of interest in publishing a customer list, which negates the usefulness of sub-delegations. Any updates we consider should focus on the impact of keeping the database accurate. This is probably a much larger discussion as a whole, appropriate for a future RIPE meeting. I would like to ask the community, what authorization model provides the trust so that people will continue to use, updates, and keep their data accurate? As for the current SSO solution, it is effective and seems to be fairly robust. I like the improved customer experience for resets and other maintenance items. I am not a huge fan of being required or forced down this path, or that the identity provider is required to be RIPE. The idea that we could authenticate from other places like a Github with this solution seems appropriate given the trends from the past ten years and the progress made in these areas. Maintainer recovery on older legacy blocks continues to provide challenges so I applaud any effort to enable self-service interfaces for users. Thanks, Billy
On Dec 2, 2015, at 6:48 AM, Shane Kerr <shane@time-travellers.org> wrote:
Denis,
At 2015-12-01 15:49:10 +0100 denis <ripedenis@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