Dear colleagues, Please find below a list of the projects that we included in our development plan. We would appreciate if you could indicate importance and usefullness of specific projects so we can adjust their priorities. Several more detailed proposals will follow. Here I just included brief description of the projects not to enter premature implementation discussion. Regards, Andrei Robachevsky DB Group Manager RIPE NCC 1. Authorisation checks across multiple databases Migration to v3/RPSL made creating objects in the routing registry a much more complex process due to the introduction of the Routing Policy System Security (RFC 2725). The real problem was with so called "foreign" route objects that either announce non-RIPE address space or are originated from non-RIPE ASN. As there were no corresponding objects in the RIPE database such transactions failed. A workaround is in place now that requires duplication of objects in the RIPE RR and as a result - low security level. The proposed solution is to get this information from sources that contain authoritative information about network objects that are supposed to authorise the transaction. For example, when creating a route from APNIC's address space, but originated from a RIPE ASN, authorisation information will be requested from both RIPE and APNIC sources. 2. Real-time (interactive) updates Currently only e-mail updates are supported by the RIPE Database which complicates automation of the update process at the clients side. The facility that will allow connection oriented interactive, or real-time updates, will simplify development of the client tools and make synchronising of LIR's address management database an easier task. Once implemented this project will present a facility for other tools, such as web-based update interface, or a standalone syntax checker. 3. Automatic cleanup of unreferenced person objects You may find the initial proposals: http://www.ripe.net/ripe/mail-archives/db-wg/20010701-20020101/msg00079.html http://www.ripe.net/ripe/mail-archives/db-wg/20010701-20020101/msg00092.html The problem statement and the solution remains almost the same, with some modifications: - cleanup process is based on internal DB data, rather than object attributes or meta-attributes - "holders" of the objects to be deleted are notified n days before using standard DB notification mechanisms. 4. Further development of the database software - Improving error reporting - Improving server performance - Software portability and configuration 5. Improve database security These ideas were discussed at the RIPE-41, the detailed proposals will follow - Deprecate MAIL-FROM as a weak auth scheme that doesn't serve todays's security requirements. This will be done in several phases starting form not allowing updating mntner objects containing this scheme, and ending with not allowing updates to be authorised with MAIL-FROM. - Implement authentication scheme using MD5 as a more secure mechanism compared to crypt. Passphrases can be used instead of 8 character passwords and MD5 fingerprint will be presented in the auth value. - Implement inverse queries on auth, encryption, signature for PGP keys only (key-cert's).