* Denis Walker wrote:
[... it's old ...]
Just a quick list from memory of some problems surrounding the database. 'Hear from users'...Whenever I bring up any issues like this, I either hit a total wall of silence or I am hit with familiar negativity. NO one ever talks about the future of the RIPE Database in a positive way. Daniel said at the BOFF in Iceland, "It's time to stop tinkering around the edges of the RIPE Database". I thought that would be the trigger to start this positive discussion. At the BOFF there were lots of heads nodding in agreement. Any thought of a positive discussion was lost as quickly as people left the BOFF heading for the bar. A Task Force was set up, I thought, to document the business requirements for the RIPE Database and public registry. All they did was look backwards and write a document on the history of the database...many of us already knew that.
There are proposals out there, which can model he idea of Whois-DBs better. Simply spoken, the idea of Whois is to publish the responsibility/ownership of limited resources, which are hierarchically maintained. Problems arose, if your data is duplicated into a data store you do not operate yourself: - How to keep it updated? - How to track modifications you did not authorized? - How to unpublish or control access of sensitive data? - How to deal with discrepancies in local law of the data owner and the operator? The most natural approach is to distribute control and storage of the data. An Whois service like whois.iana.org simply respond with the contractual information IANA had for the resource: If queried, show the contractual party and a refer: line. If we adopt this model for RIPE DB, this would have some consequences: - Every LIR is obligated to operate its own Whois service. - RIPE might offer to continue their current DB for those, which are not yet able to run on their own. (Transition period) - RIPE NCC has to include contractual obligations to ensure a stable and useful operations of the LIR Whois service. - RIPE NCC has to actively monitor those services and take action if they are not in a compliant state. (call Atlas for help?) - Every LIR is obligated to handle the subordinate delegations in a similar way. Even for assignments, this might be useful. - On the tooling side, some major changes are necessary: bgpq and irrtoolset can't any longer rely on single source. They have to implement a recursive crawler and deal with a lot of problems like inaccessibility, rate limits, geofencing, ... - The routing community has to think about their best practices: + Drop automatic ACL generation in favour of rPKI? + Drop RPSL procession (already gone?) + Where to obtain the traffic steering communities for peers? PS: I'm personally interested in this model for ICANN in order to overcome the Thick-Whois approach with a large drive-through for LEA and paying mass-access-actors, violating at least the GDPR.