This is the draft minutes for the DB-WG meeting at RIPE 21 in Rome. They are quite belated (and probably full of typos), but unfortunately nobody volunteered this time to act as a scribe... Comments, corrections, additions -as always- very welcome. Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Draft Minutes: RIPE 21, Database-WG Rome, 8.5.1995 Chair: Wilfried Woeber, Scribe: Wilfried Woeber ------------------------------------------------------ 0. Administrative stuff Unfortunately nobody volunteered to take the minutes. I had to guide the discussions and to take the notes at the same time. Thus these minutes are probably not as comprehensive as we are used to. Apologies. The agenda was accepted as proposed, without changes. 1. DB-SW review David Kessens, RIPE NCC, reported on the current state of the database software and the environment at the NCC for providing maintenance and doing development work. Activities since RIPE 20 (as Marten and Tony having left the NCC/PRIDE Project) centered on becoming familiar with the software, performing bug fixes and implementing minor extensions, like the "network update" feature whois -U and whois -tv (for template verbose). Other aspects worth mentioning: . reverse lookup technology . hierarchical authorization (initially for domains) . referrals are being researched and estimates for the necessary implementation efforts are obtained. David confirmed that the official distributioin kit available (anonymous FTP) at the NCC always contains the most recent fixes issued and additions. For more details please refer to the slides supporting David's presentation which are available from the RIPE NCC FTP Server in the presentations directory ftp://ftp.ripe.net/ripe/presentations/ripe-m21-david-DB-REPORT.ps.Z Merit is also working on the databse software and has produced some tools. These things are available from: ftp://ftp.ra.net/routing.arbiter/tools/RAToolSet 2. Security While there was no concern regarding the functionality and usefulness of the authorisation methods already implemented (mail-from:, crypt-pw:) there is a need for even stronger authentication of updates. PGP seems the way to go, although there is still quite a bunch of open questions and a need for logistic (e.g. key distribution) development. It is not clear at the moment whether this should be integrated (DB, RIPE NCC) or be provided by mechanisms outside the scope of RIPE. SURFnet reported it's intent to use the RIPE-DB for routing configuration as soon as PGP would be available to provide the data reliability necessary. Others expressed strong interest, as well. Merit (LJ) did part of the work already to provide PGP authorisation for the email addresses in updates. Comments from the group stressed that it is essential to *not* mix the concepts of authentication and of encryption. Encryption is a logistic and/or legal problem in some regions. The group is requested to persue this aspect on the relevant mailing lists. *Action on David Kessens and Wilfried Woeber: Investigate the deployment of PGP for the RIPE Database and to draft a proposal. 3. Review of beta test for RIPE-Handles The method for generating RIPE-Handles was discussed once again, there are still open issues when trying to fully automate handle assignement because this would require both a DB-commit function as well as require the modification of submitted objects on-the-fly. The group did not resolve this issues, thus the current procedure (finger) remains in place. It was noted that the scripts involved should be made available to all interested parties. 4. External interfaces There is an on-going discussion (in the light of more than one organisation using the RIPE DB-SW now) on how to keep the various databases in synch. One of the ideas is to accept updates for each and every database on all interfaces, to analyze the "source:" attribute and then to automatically forward the update to the database as indicated by "source:". While this is probably quite interesting, it might not always be what the users intend. The alternative is to reject updates when submitted for the "wrong" "source:". This is the safe way. To meet the need of regularly transferring updates from one database to (an)other(s), a method using FTP and providing "deltas" is investigated. 5. Input for and review of objects Due to the scheduling of the working groups, there was no input at the DB-WG meeting. A proposal to expand the internet-router object to describe Mbone routing was circulated after the meeting, as drafted by the Mbone WG. 6. AOB None. Thus the meeting was closed. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW. 2.6.95